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

[Thomas Stüfe]

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/20160927/51773f8e/attachment.htm>