PING: RFC for new JEP: Reduce metaspace waste by dynamically merging and splitting metaspace chunks.

[Thomas Stüfe]

Hi all,

May I have please some feedback for this enhancement proposal?

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


In one very short sentence it proposes a better allocation scheme for
Metaspace Chunks in order to reduce fragmentation and metaspace waste.

I also added a short presentation which describes the problem and how we
solved it in our VM port.

https://bugs.openjdk.java.net/secure/attachment/63894/Metaspace%20Coalescation%20in%20the%20SAP%20JVM.pdf

Thank you very much!

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/20161010/f832b422/attachment.htm>