PING: Enhancement Proposal: Reduce metaspace waste by dynamically merging and splitting metaspace chunks.

[Thomas Stüfe]

(crossposting to runtime-dev in the hope of getting more interest)

Hi all,

Please take a look at this proposed JEP.

https://bugs.openjdk.java.net/browse/JDK-8166690

The JEP proposes an improved allocator for metaspace. That allocator
reduces metaspace wastage for certain corner cases by a lot.

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.

Thank you! and Kind Regards,

Thomas



On Tue, Sep 27, 2016 at 10:45 AM, Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> Dear all,
>
> please take a look at this Enhancement Proposal for the metaspace
> allocator. I hope these are the right groups for this discussion.
>
> https://bugs.openjdk.java.net/browse/JDK-8166690
>
> Background:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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-their-size"
> limitation and provides for better reuse of metaspace chunks. It also
> provides better defragmentation as well.
>
> 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.
>
> 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.
>
> Thank you, and Kind Regards,
>
> Thomas Stüfe
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20161024/10a34645/attachment.htm>