<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 1, 2023 at 5:55 PM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
I mean, I take it that, if it's a choice between performance and <br>
tracking, most developers who chimed in seem all to be converging <br>
towards disentangling Arenas from Bits::reserveMemory (so that we can <br>
get better allocation performance).<br>
<br>
But I'd like to ask a control question: let's assume that <br>
Bits::reserveMemory was free (or that we found some way to make it much <br>
less expensive), would opinion then shift towards having a single JDK <br>
parameter to control all off-heap memory allocation?<br></blockquote><div><br></div><div>Is it also free when the limit has been reached, though? A limit needs to be able to prevent allocations from going through, either by waiting or producing and error.</div><div>Systems may have multiple different pools of memory beyond what is built into the JVM, each with their separate limits.</div><div>Such limits are better applied in the application.</div><div>For instance, in Neo4j there are 3 main consumers of off-heap memory: the page cache, Lucene, and Netty, and each of these should ideally not be able to compromise the stability of the others.</div><div>Having a JVM-wide limit is counter to this, and I know that at least two of the mentioned components take action to mitigate this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Or is it still the case that, as Arena can be customized, custom arenas <br>
might decide to track memory how they wish, and we should not bias the <br>
API against this or that particular way of tracking memory usage ?<br></blockquote><div><br></div><div><div>I see some parallels to the Executors, who are also life-cycled repositories of limited resources.</div><div>It has become customary for libraries and applications to offer ways to configure or pass in the executors they need, as a way for people to control resource usage, while at the same time the default Executor (as much as newCachedThreadPool() can be considered a default) place no limits.</div></div><div>Customizing Arenas, through combinators or otherwise, could be a way to do the same for placing controls and limits on off-heap memory.</div><div><br></div><div>Tracking (as in, measuring usage), on the other hand, makes sense to have built-in.</div><div>When operating systems in large deployments, native memory usage is one of the metrics you always want to collect and monitor.</div><div>Having every library and framework report their off-heap memory usage in different ways can be useful for drilling into problems, but you also want the sum of usage to be track in a well-known place.</div><div>I don't have a strong opinion on this being one metric for ByteBuffer and MemorySegments combined, or if they are exposed as two separate well-known metrics; you just don't want it to be a dozen mostly-library-and-app-defined metrics.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Cheers<br>
Maurizio<br>
<br>
<br>
<br>
<br>
</blockquote></div></div>