<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 31/07/2023 21:38, Pedro Lamarão
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAC8PkgHGwV2P7VWA0SPX8Q5P5frMohFM9qhCVbCab2SNV4d9_A@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">Em seg., 31 de jul. de 2023 às 10:57, Maurizio
Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>
escreveu:<br>
</div>
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">All this stuff is not
really important when we using memory segments, since we can
use explicit arenas to deallocate memory programmatically.<br>
</blockquote>
</div>
<div><br>
</div>
<div>
<div>
<div>I understand that the direct memory limit is all about
the fact that this memory is GC-freed.</div>
<div>If that is so, I feel it is appropriate for the global
arena.</div>
<div>Maybe it can be reinterpreted as that, the limit for
the global arena, and then by extension to all GC-freed
native memory.</div>
</div>
</div>
</div>
</blockquote>
<p>This is a possibility.</p>
<p>One extra detail is that stats on direct memory usage are exposed
via JMX. The Bits class has this "Pool":</p>
<p><a class="moz-txt-link-freetext" href="https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/Bits.java#L213">https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/nio/Bits.java#L213</a></p>
<p>I believe that's exposed here:</p>
<p><a class="moz-txt-link-freetext" href="https://download.java.net/java/early_access/jdk21/docs/api/java.management/java/lang/management/BufferPoolMXBean.html">https://download.java.net/java/early_access/jdk21/docs/api/java.management/java/lang/management/BufferPoolMXBean.html</a></p>
<p>So, another question is:</p>
<p>* Do we expect a separate kind of JMX object to keep track of
memory segments?<br>
* Or do we expect the same JMX object to report stats about all
kinds of off-heap memory usage, whether BB or MS ?</p>
<p>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.</p>
<p>In fact, from a management perspective, having a single counter
for _all_ off-heap memory usage is _likely_ better.</p>
<p>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.</p>
<p>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.</p>
<p>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.<br>
</p>
<p>Maurizio<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAC8PkgHGwV2P7VWA0SPX8Q5P5frMohFM9qhCVbCab2SNV4d9_A@mail.gmail.com">
<div dir="ltr">
<div>
<div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>Pedro Lamarão</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>