Open laeubi opened 10 months ago
size in matter of number of elements (OK), or size in matter of bytes (depends on JVM, may not change if a field is removed or added due to memory alignment)?
size in matter of bytes
e.g JProfile and also other tools can show such information without taking a heap dump so the JVM seem to expose such data somehow to special agents and I supose a debugger is such special thing.
(depends on JVM, may not change if a field is removed or added due to memory alignment)?
Usually my JVM does not change while I'm in a debugger session
Usually my JVM does not change while I'm in a debugger session
yea, but such numbers are typically guesses or at least not generally valid and may be misleading.
Usually my JVM does not change while I'm in a debugger session
yea, but such numbers are typically guesses or at least not generally valid and may be misleading.
I don't need exact numbers, but it is important to "see" if my object is about 1 MB 10 MB or 100MB and if I change something it is maybe half that size (estimate).
I also don't need to compare numbers across different JVMs or different computers.
I believe I've seen recently code in JDT tests that did estimation of object size. Sorry can't remember where it was.
@iloveeclipse @jukzi
please have a look at https://docs.oracle.com/en/java/javase/17/docs/api/java.instrument/java/lang/instrument/Instrumentation.html
This class provides services needed to instrument Java programming language code. Instrumentation is the addition of byte-codes to methods for the purpose of gathering data to be utilized by tools. Since the changes are purely additive, these tools do not modify application state or behavior. Examples of such benign tools include monitoring agents, profilers, coverage analyzers, and event loggers.
It has a method getObjectSize(...)
Returns an implementation-specific approximation of the amount of storage consumed by the specified object. The result may include some or all of the object's overhead, and thus is useful for comparison within an implementation but not between implementations. The estimate may change during a single invocation of the JVM.
What I'm currently missing when analyze memory problem is that I can see in a heapdump how much size an object has allocated, but later on in the debugger when analyze the problem one is a bit "blind".
It would be great if it would be possible to select a variable in the debug view and ask for the (direct and retained) size e.g. of a Map/List/....