JDK-8190729 : Adjustment to anonymous metadata space chunk allocation algorithm
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-11-03
  • Updated: 2017-12-15
  • Resolved: 2017-11-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10 b36Fixed
Related Reports
Relates :  
JDK-8191924 - Adjust DelegatingClassLoader's metadata space sizing algorithm
Relates :  
JDK-8187338 - Per anonymous class class loader data is costly
Relates :  
JDK-8191931 - NMT test for anonymous/delegating metadata space sizing
Description
Anonymous metaspace has about 60% memory waste (See JDK-8187338 for details.)

It turns out that current chunk allocation sizing algorithm is not optimized for anonymous metaspace, especially, its metadata space.

The average occupancy size of metadata space is just a little over 1K. Current algorithm initializes metadata space with SpecializeChunk (1K), then immediately bumps up to SmallChunk (4K) once the initial chunk exhausted.

Based on usage distribution, there is about 50% metadata spaces only use 1K - 2K memory, out of 5K of allocated space, which is the major contribution to about 60% total waste of anonymous metaspace.

The enhancement purposes, for anonymous metadata space, to stay with SpecializedChunk, instead of jumping to SmallChunk, up to 4 limit.

My experiment shows that it reduces total anonymous metaspace waste from ~60% to ~30%.
Comments
This is listed as a P4 enhancement and there are very few weeks (4) until jdk10 feature freeze. Given that there is not yet a RFR out for this, we assume that it should be targetted to 11. Most RFEs at this point are assumed to not make jdk10 safely.
06-11-2017
Why is this targeted to 11? Is there a plan address JDK-8187338 in 11?
06-11-2017
Elasticsearch Patched: For anonymous classes= 1917 capacity= 4472.00KB used= 3101.35KB free= 1370.65KB waste= 11.16KB Metadata capacity= 2555.00KB used= 2054.57KB free= 500.43KB waste= 11.16KB Class data capacity= 1917.00KB used= 1046.78KB free= 870.22KB waste= 0.00KB Unpatched: For anonymous classes= 1917 capacity= 6274.00KB used= 3097.73KB free= 3176.27KB waste= 11.09KB Metadata capacity= 4357.00KB used= 2051.05KB free= 2305.95KB waste= 11.09KB Class data capacity= 1917.00KB used= 1046.69KB free= 870.31KB waste= 0.00KB Wildfly: Patched: For anonymous classes= 482 capacity= 1315.00KB used= 881.14KB free= 433.86KB waste= 6.17KB Metadata capacity= 833.00KB used= 619.41KB free= 213.59KB waste= 6.17KB Class data capacity= 482.00KB used= 261.73KB free= 220.27KB waste= 0.00KB Unpatched: For anonymous classes= 484 capacity= 2300.00KB used= 879.51KB free= 1420.49KB waste= 5.91KB Metadata capacity= 1816.00KB used= 616.62KB free= 1199.38KB waste= 5.91KB Class data capacity= 484.00KB used= 262.89KB free= 221.11KB waste= 0.00KB
06-11-2017