Object allocation tracing / profilers

Robert Stupp snazy at snazy.de
Thu Feb 6 22:36:36 UTC 2014


I'm trying to trace/count object allocations - especially regarding the ObjectIn/OutputStream stuff.

I know two API points: JVMTI and instrumentation. JVMTI fires an event for nearly everything except allocations from bytecode - instrumentation allows to transform bytecode (e.g. to issue a callback on object allocation).

But I am not very satisfied - maybe I oversee something...
What I need is the number of "real" allocations. I do not want to count allocations that Hotspot would normally eliminate - for example Hotspot seems to eliminate instances of ArrayList$Itr under some circumstances.

I played around with this instrumentation code: https://code.google.com/p/java-allocation-instrumenter/
But this one and any other profiler (JProfiler) I tried always gave me the theoretical number of instances of ArrayList$Itr. This reason seems to be as follows:
With instrumentation/transformation constructors get a piece of code "injected" which calls a "profile object allocation method". This method gets the new object instance, which is used to get the Class object and to inquire the shallow object size on the heap - and it gets the current thread's stack trace.

My suggestion is, that Hotspot cannot eliminate object allocations (for example of ArrayList$Itr) because the profiler bytecode needs that object instance and does other things, that are "strange" to Hotspot.

I hoped that I can get callbacks using JVMTI but due to the restrictions mentioned here (http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#VMObjectAlloc) there are no callbacks for allocations caused by bytecode.
VMObjectAlloc events occur during the start and end of the application - but not a single event is fired while the application is running (I've attached my JVMTI code).

Am I doing anything wrong? Is there a possibility to count only the "real" instances? If not, wouldn't it be nice to have such a functionality in JVMTI or a callback functionality for http://download.java.net/jdk8/docs/api/java/lang/instrument/Instrumentation.html?
My fear is that all profiler results that all developers see are inaccurate because the code injected by profilers influences Hotspot too much.


More information about the core-libs-dev mailing list