RFR: JDK-8269092: Add OldObjectSampleEvent.allocationSize field

[Ludovic Henry]

On Tue, 22 Jun 2021 08:32:56 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

> The data is already available in ObjectSample.allocated and getting this data
> in another way is complicated (via Instrumentation for example). Having the
> size of the objects also allows to augment the memory leak analysis based on
> the object size impact on top of based on the object count impact.

Right now the only information about the OldObject in this sample we have are the age, time of the allocation, the number of elements in the array (if it's one), the total amount of heap used (overall, for the whole process, not just this object), and the class, address, and referrer of the object itself.

In the case of memory leak analysis, we then know which objects appear to be leaking. We also know that, based on the heuristics of the priority queue in the leak profiler, the sampled objects have the most impact on memory usage (since sampling is biased towards bigger shallow objects). However, we still don't know exactly how much memory is used. We can approximate it if it's an array, based on the size of the elements and the number of elements. However, it's always going to be approximative since the size of the object header might change in the future (project Lilliput), and because of various other constraints like alignement of elements, size of each element, etc.

I'm sure these constraints would not necessarily be impossible to overcome, but because we already have this exact information, I figured it to be much easier to put it straight in the event. This exact field is also present in `AllocationRequiringGC`, `ObjectAllocationInNewTLAB`, and `ObjectAllocationOutsideTLAB`, so there is precedent in terms of naming, typing, and meaning for related events.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4549