memorySegment.asByteBuffer().duplicate() causes multi-MB allocations

[Sebastian Stenzel]

I just used the memory profiler of VisualVM, which shows that in fact hundreds of thousand DirectByteBuffers get allocated during my test (only a handful of them still being live, though). The sampler can see just a fraction of these either due to their short life.

So probably I made a mistake interpreting the numbers in the JFR recording. Probably only some allocations are actually instrumented (the ones requiring GC?)


> On 26. Oct 2022, at 14:22, Sebastian Stenzel <sebastian.stenzel at gmail.com> wrote:
> 
> I noticed this as well, but didn't dare to ask. While hundreds of kiB per instance is suspicious, this problem is dwarfed by the MiB allocations.
> 
> I'll try using some other tools as well.
> 
>> On 26. Oct 2022, at 14:17, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>> 
>> 
>> On 26/10/2022 11:37, Sebastian Stenzel wrote:
>>> There is is an expected amount of allocations all the time, both "before" and "after", due to persistent invocations of the benchmarked method. However due to different scaling of the "before" chart it _appears_ like nothing after the first spike. When you zoom in on the time axis, so that the spike is out of view, you'll see similar patterns "before" and "after".
>> 
>> Yes, but it's the numbers that don't add up. In some instances there's only one call to `duplicate`, which seems to allocate ~350Kb. In another instance there's _two_ calls to `duplicate`, which, cumulatively, take less than 100Kb.
>> 
>> This doesn't make any sense, not only because it's not consistent, but also because 100Kb for a _single instance_ (which is just a wrapper around existing field) is huge! I'd expect a plain direct buffer view to take a couple of dozen of _bytes_ - not hundreds of kilos. So, even if there might well a real problem underneath, I'm not sure how much we can trust these numbers.
>> 
>> Maurizio
>> 
>