<div dir="ltr">CloseableCollection is a class of the library.  It won't show up in heap dumps because probably very few people are using it.  You would need to look at JIT optimized assembly to see if JIT is eliding the CloseableCollection and it's internal data structure (array?).<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 27, 2022 at 10:53 AM Mark Raynsford <<a href="mailto:org.openjdk@io7m.com">org.openjdk@io7m.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2022-12-27T09:42:53 -0800<br>
Nathan Reynolds <<a href="mailto:numeralnathan@gmail.com" target="_blank">numeralnathan@gmail.com</a>> wrote:<br>
<br>
> If the CloseableCollection doesn't escape (likely), then JIT will get rid<br>
> of the object allocation.  The internal Closeable[] (?) may still stick<br>
> around... unless JIT can determine it doesn't escape too.  Can JIT escape<br>
> analysis get rid of small arrays?  If so, the CloseableCollection's<br>
> footprint disappears.  The only thing remaining is the logic.  That's<br>
> exactly what an enhanced try-with-resources would do.<br>
<br>
I haven't been able to spot any instances of the closeable collection<br>
in heap samples, or the internal ArrayDeque instances. Doing<br>
soft-realtime work, you can be certain I'm looking at heap samples. :)<br>
<br>
It hasn't even been necessary so far to use anything other than the<br>
default array size. Those instances are either gone in a single method,<br>
or they live for a very long time (and we're talking about less than a<br>
couple of hundred bytes per collection, typically).<br>
<br>
-- <br>
Mark Raynsford | <a href="https://www.io7m.com" rel="noreferrer" target="_blank">https://www.io7m.com</a><br>
<br>
</blockquote></div>