Skip to main content

sizeof

16 replies [Last post]
epesh
Offline
Joined: 2003-06-19

I think we need to add sizeof operators to Java, to prepare for when we can get rid of that stupid garbage collection stuff. Some day we'll have malloc() and free() and realloc() and sbrk(), and this is a good first step.

It'd also help answer how much room a given reference took up in the heap.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
patrikbeno
Offline
Joined: 2004-10-11

Profiling API can be used for this but you have to use it carefully since this kind of application/runtime monitoring can consume a lot of resources.

kcpeppe
Offline
Joined: 2003-06-15

> Profiling API can be used for this but you have to
> use it carefully since this kind of
> application/runtime monitoring can consume a lot of
> resources.

True.. which is why you should consider using -verbose:gc. This setting CAN be left on in a production system as it has a reasonably low impact on performance. You do need to take care of trimming the log that is creates ;)

patrikbeno
Offline
Joined: 2004-10-11

Logging itself can also consume a lot of resources. Consider the difference between DEBUG and WARN levels of logging in an application that does a lot of DEBUG logging.

Further, if you want to use that information programatically, -verbose:gc is not the best approach :-)

kcpeppe
Offline
Joined: 2003-06-15

> Logging itself can also consume a lot of resources.
> Consider the difference between DEBUG and WARN
> levels of logging in an application that does a lot
> of DEBUG logging.
>
> Further, if you want to use that information
> programatically, -verbose:gc is not the best approach
> :-)

ok, now I know that you are trolling....

Have you actually measured the hit that -verbose:gc put on a system as compared to using the JVMPI, which is about the only other real option that you have. I have successfully left -verbose:gc on in several production systems.. It is not as low a hit as the one you take when using JRocket but.. it's still under 5% unless GC activity is quite high at which point the load that verbose:gc will put on your system is the least of your trouble.

And if you are monitoring for GC activity because you are concerned about it.. does it make sense to put a further load on the VM by actually reading and analyizing that data in that same VM?

patrikbeno
Offline
Joined: 2004-10-11

I guess my English is not that good since I am not exactly sure about the meaning "you are trolling...". Does not matter...

All I know is that if you want to programatically use information produced by -verbose:gc, you have to load it, parse it, analyze it, needless to say you just may not have the right information you want in it.

Speaking about self-managed systems, it often make sense to have optimized and reasonable self-profiling logic in the same JVM.
Also note that JVMDI & JVMPI are deprecated and have been replaced by new native API called JVMTI.

And finally, I have to say that there are lot of ways of optimizing and setting up profiling code to match your very exact need, you can even dynamicaly configure it and turn it on/off as needed, so I believe you can get below those 5% overhead.
I guess you can't do this with -verbose:gc

For me, -verbose:gc is a hack while JVMTI is the right and more flexible approach.
However, it depends on what you need.
While I wanted just to watch and wonder, -verbose:gc was enough for me.
If you need more, use JVMTI.

kcpeppe
Offline
Joined: 2003-06-15

> For me, -verbose:gc is a hack

ok, just how is the verbose:gc output produced?
and how is that considered to be a hack?

How does does one interface with the JVMTI to aquire gc statistics and what do you think that interface wraps and is it actually free to be able to turn it on and off at will?

patrikbeno
Offline
Joined: 2004-10-11

Oh, sorry, you misunderstand (and it's my fault, I should have made myself more clear)

I meant it is a hack [b]using[/b] -verbose:gc [b]for the purpose(s) we're discussing here[/b]. Not that -verbose:gc itself is a hack

opinali
Offline
Joined: 2003-06-17

There's no problem in providing operations like sizeof and offsetoff. But not as language syntax or static-time operation; this would allow introducing, in your bytecode, hardwired results that wouldn't be platform-neutral. An API that does it dynamically would be fine. Indeed, such API exists already in the class sun.misc.Unsafe. For example, offsetof() is implemented as "long objectFieldOffset(Field)" plus other variants (for static methods, arrays, etc.). You can't invoke this class from application code, it's restricted to the implementation of core APIs like java.nio and java.util.concurrent. Even if selected, non-unsafe methods like objectFieldOffset() became public APIs, their results would only make sense for low-level, unsafe operations, that (once again) can be used by some critical core APIs, but not by app code.

By the way, rest assured that we'll NEVER have free(), realloc() and sbrk(), thanks god ;-) But I guess there may be other worthy usages of sizeof/offsetof, for example configuring caches and pools and so on; or with JSR-001 (RealTime Java), where we can indeed do a lot of manual memory management (but still in the spirit of Java).

jarouch
Offline
Joined: 2004-03-04

One more thing - can we find out how much memory was allocated/freed by GC? We can use methods in Runtime class but if GC is processed between calls.. I know we can disable GC but it is not always possible. And new management API from 1.5 can tell us number of collections that have occurred and how much time it have spent, but not size of freed memory;(.

kcpeppe
Offline
Joined: 2003-06-15

try -verbose:gc :)

patrikbeno
Offline
Joined: 2004-10-11

I don't think we'll ever need it. Time is coming when everyone will have so much RAM that you can safely just turn off that "stupid garbage collection stuff". Let System.exit() and those funny operating systems deal with the garbage.

640 TB ought to be enough for anybody ;-)

jarouch
Offline
Joined: 2004-03-04

> I don't think we'll ever need it.

Do you mean sizeof or malloc, free.. ? GC is cool, but still I think we should have a way to examine size of objects, cause it is good for programmer to have vision how big his structures are, similarly as we know how fast are algorithms we use.

> Time is coming when everyone will have so much
> RAM that you can safely just turn off that
> "stupid garbage collection stuff"

joke?

vhi
Offline
Joined: 2004-10-11

>> joke?

I guess so. I think 'epesh' likes to entertain us with his indirect poke at our requests. I think I can see a pattern here.. But I wonder what it is..

patrikbeno
Offline
Joined: 2004-10-11

Joke, sure. Don't take seriously anything that epesh posts. And if you see my post in epesh's thread, don't take it seriously either, I am just playing epesh's game :-)

however, all my other posts should be taken very seriously ;-)

epesh
Offline
Joined: 2003-06-19

I take everything I say in this forum seriously. That said, I'm also, uh, fairly sarcastic, so exactly HOW I take them seriously probably remains in doubt. :)

Actually, sizeof for Java would be incredibly problematic - does it refer to the size of the referenced object or the entire reference tree of the object as well? The former would be useless. String would always be 20 bytes, for example. The latter, while useful, would be easily abused - especially in a highly interlaced object graph.

jarouch
Offline
Joined: 2004-03-04

Yes, it is, but now we have to see source codes to find it out. And it is just approximation, cause we dont know what is size of byte, char.. in JVM.