Hi, 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. - Robert
