FFM API allocation shootout

[Maurizio Cimadamore]

On 31/07/2023 21:38, Pedro Lamarão wrote:
> Em seg., 31 de jul. de 2023 às 10:57, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> escreveu:
>
>     All this stuff is not really important when we using memory
>     segments, since we can use explicit arenas to deallocate memory
>     programmatically.
>
>
> I understand that the direct memory limit is all about the fact that 
> this memory is GC-freed.
> If that is so, I feel it is appropriate for the global arena.
> Maybe it can be reinterpreted as that, the limit for the global arena, 
> and then by extension to all GC-freed native memory.

This is a possibility.

One extra detail is that stats on direct memory usage are exposed via 
JMX. The Bits class has this "Pool":

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/Bits.java#L213

I believe that's exposed here:

https://download.java.net/java/early_access/jdk21/docs/api/java.management/java/lang/management/BufferPoolMXBean.html

So, another question is:

* Do we expect a separate kind of JMX object to keep track of memory 
segments?
* Or do we expect the same JMX object to report stats about all kinds of 
off-heap memory usage, whether BB or MS ?

I think having _some_ segments show up in one counter, and some other 
segments showing up in a different counter would be odd from a 
management perspective.

In fact, from a management perspective, having a single counter for 
_all_ off-heap memory usage is _likely_ better.

The flipside of that is that if we use a shared counter for all segments 
(and buffers) then you can end up in a situation where a new allocation 
w/ explicit arena cannot proceed because there's a lot of allocations 
(with automatic arena) hanging around. Meaning that even the code using 
explicit arenas would need some form of "GC kicking". Which is kind of 
what we're trying to avoid.

In other words, the requirements here seem to be pulling us in different 
directions: from a management perspective, having a bird's eye view over 
all off-heap memory being allocated is a good thing. From an 
implementation perspective, doing so (and having to adhere to same 
limits) probably means having to run the same recovery logic for both 
code paths (MS and BB) - given that one can interact with the other.

One thing I'd like to experiment with is to add fast paths for when a 
direct memory limit is not set. Perhaps in such cases we can do 
something better: in such a case we never have to compare against a 
limit, so using a bunch of long adders is likely good enough, even for 
reporting JMX stats.

Maurizio


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