FFM API allocation shootout

[Pedro Lamarão]

Em ter., 1 de ago. de 2023 às 22:19, Brian S O'Neill <bronee at gmail.com>
escreveu:

> On 2023-08-01 05:53 PM, Maurizio Cimadamore wrote:
> >
> > But I'd like to ask a control question: let's assume that
> > Bits::reserveMemory was free (or that we found some way to make it much
> > less expensive), would opinion then shift towards having a single JDK
> > parameter to control all off-heap memory allocation?
> >
> > Or is it still the case that, as Arena can be customized, custom arenas
> > might decide to track memory how they wish, and we should not bias the
> > API against this or that particular way of tracking memory usage ?
> >
>
> My understanding is that the reserveMemory call is primarily intended to
> manage off-heap memory which should be cleaned up via garbage
> collection. It can force full collections to help free up memory, which
> is generally a bad thing. Memory which isn't automatically freed
> shouldn't be tracked in a fashion that makes it look like running a full
> GC would have any effect. The MaxDirectMemorySize parameter should only
> apply to memory which is automatically managed.
>

About limiting, I agree that this limit still makes for a unified notion of
GC collected native memory (direct byte buffers, the global arena etc.),
since we need the JVM`s help to impose useful limits, if we want any.
Memory explicitly deallocated by the programmer can be limited by the
programmer however she sees fit.

About tracking, I am unsure, as that supports not only limiting, but
monitoring. In my own practice, monitoring native memory usage is something
we do using system level tools, not JVM internal counters. I have never
encountered the need to measure specifically the "direct buffer memory" of
a running JVM. If I had to guess, I would guess that people monitoring this
specifically are concerned with the effects of encountering the limit --
something which users of deterministic or custom arenas would not need to
worry about.

-- 
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230802/17fb5d63/attachment.htm>