I haven't used that particular interface before, but I've not found that the other instrumentation is very good at counting small differences in bytes allocated. It seemed more chunked to me in the past.
Yeah, the API says "The returned value is an approximation because some Java virtual machine implementations may use object allocation mechanisms that result in a delay between the time an object is allocated and the time its size is recorded."
so it might or might not work :)
it seems to be rather precise from my limited experimentation
(on openjdk 8)
Well, if it works in practice, that's cool. I just can report that with similar APIs I've found it to not work as of I guess about 6 years ago.
The allocation counters is not chunked but it is in too expensive to call for each allocation. It is sampled in the the compiler if you enable profiling and then problem down by phase
so I played with it and I got "48" as the minimum value between two calls to that method without allocating anything
so I instrumented every allocation site in Dotty but even when the compiler is hot, only three call sites show up with "48" as the allocation size
might be because all the instrumentation makes the JIT give up, or because even when something is elided, the fields of the elided objects might still be allocated
have a look in trait AllocationTest junit helpers and calibration for the delta between call
the difference between successive calls is VM specific I recall
its used in IndexedSeqTest - ther used to be some allocations in Vector#drop etc used to create Iteratorsto compare