<div dir="ltr">(crossposting to runtime-dev in the hope of getting more interest)<div><br></div><div>Hi all,</div><div><br></div><div>Please take a look at this proposed JEP. </div><div><br></div><div><div><a href="https://bugs.openjdk.java.net/browse/JDK-8166690" target="_blank">https://bugs.openjdk.java.net/<wbr>browse/JDK-8166690</a><br></div></div><div><br></div><div>The JEP proposes an improved allocator for metaspace. That allocator reduces metaspace wastage for certain corner cases by a lot.</div><div><br></div><div>We at SAP have already an existing implementation for this proposal, but currently only in our internal code base, not in the OpenJDK. It works fine. I can provide a prototype based on openjdk 9 to look at and play with, but would like to know whether there is any interest before investing the work.</div><div><br></div><div>Thank you! and Kind Regards,</div><div><br></div><div>Thomas</div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 27, 2016 at 10:45 AM, Thomas Stüfe <span dir="ltr"><<a href="mailto:thomas.stuefe@gmail.com" target="_blank">thomas.stuefe@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Dear all,</div><div><br></div><div>please take a look at this Enhancement Proposal for the metaspace allocator. I hope these are the right groups for this discussion.</div><div><br></div><div><a href="https://bugs.openjdk.java.net/browse/JDK-8166690" target="_blank">https://bugs.openjdk.java.net/<wbr>browse/JDK-8166690</a><br></div><div><br></div><div>Background:</div><div><br></div><div>We at SAP see at times at customer installations OOMs in Metaspace (usually, with compressed class pointers enabled, in Compressed Class Space). The VM attempts to allocate metaspace and fails, hitting the CompressedClassSpaceSize limit. Note that we usually set the limit lower than the default, typically at 256M.</div><div><br></div><div>When analyzing, we observed that a large part of the metaspace is indeed free but "locked in" into metaspace chunks of the wrong size: often we would find a lot of free small chunks, but the allocation request was for medium chunks, and failed.</div><div><br></div><div>The reason was that if at some point in time a lot of class loaders were alive, each with only a few small classes loaded. This would lead to the metaspace being swamped with lots of small chunks. This is because each SpaceManager first allocates small chunks, only after a certain amount of allocation requests switches to larger chunks.</div><div><br></div><div>These small chunks are free and wait in the freelist, but cannot be reused for allocation requests which require larger chunks, even if they are physically adjacent in the virtual space.</div><div><br></div><div>We (at SAP) added a patch which allows on-the-fly metaspace chunk merging - to merge multiple adjacent smaller chunk to form a larger chunk. This, in combination with the reverse direction - splitting a large chunk to get smaller chunks - partly negates the "chunks-are-locked-in-into-<wbr>their-size" limitation and provides for better reuse of metaspace chunks. It also provides better defragmentation as well.</div><div><br></div><div>I discussed this fix off-list with Coleen Phillimore and Jon Masamitsu, and instead of just offering this as a fix, both recommended to open a JEP for this, because its scope would be beyond that of a simple fix.</div><div><br></div><div>So here is my first JEP :) I hope it follows the right form. Please, if you have time, take a look and tell us what you think. </div><div><br></div><div>Thank you, and Kind Regards,</div><div><br></div><div>Thomas Stüfe</div><div><br></div><div><br></div><div><br></div></div>
</blockquote></div><br></div></div>