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

[Erik Helin]

Hi Thomas,

thanks for submitting the JEP and proposing this feature!

On 2016-10-10, Thomas Stüfe wrote:
> 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

Do we really need the flag -XX:+CoalesceMetaspace? Having two differnent
ways to handle the chunk free lists in Metaspace is unfortunate, it
might introduce hard to detect bugs and will also require much more
testing (runnings lots of tests with the flag both on and off).

Do you think your proposed solution has low enough overhead (in terms
of CPU and memory) to be on "by default"?

Thanks,
Erik

> 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
> >
> >
> >
> >