JDK-8035964 : The null class loader can "taint" VirtualSpaceNodes
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2014-02-27
  • Updated: 2020-08-17
  • Resolved: 2020-08-17
Related Reports
Relates :  
JDK-8251158 - Implementation of JEP 387: Elastic Metaspace
Relates :  
JDK-8035945 - Small Metaspace allocation requests can fail even though SmallChunks are available
Description
In metaspace, the null class loader can "taint" the ReservedSpace for VirtualSpaceNodes. If the null class loader gets a chunk from a VirtualSpaceNode, then we will never purge that VirtualSpaceNode, since VirtualSpaceList::purge checks that vsl->container_count() == 0. Due to this, we can not release the ReservedSpace.

Not releasing the ReservedSpace means that the memory for the ReservedSpace can never be "reused" for chunk sizes other than the ones that was put on the ChunkFreeList from ~SpaceManager.
Comments
Not much of an issue since JDK11 chunk coalescation; will be a non-issue after jep387 hits.
17-08-2020
I had to think a bit to understand this. A loader allocates a chunk from the VirtualSpaceNode; as long as the chunk is not returned, the VirtualSpaceNode cannot be unmapped (purged). Okay. Though this is nothing specific to the boot loader, the boot loader tends to live as long as the Vm does, so keeps every VirtualSpaceNode alive it allocates chunks from. Before JDK11, chunks could not be merged/splitted, chunks allocated from a VirtualSpaceNode were "frozen in shape" forever. So, purging a VirtualSpaceNode was the only way to get the memory into different shapes again. With JDK11 we introduced chunk coalescation. A (a bit cumbersome) way to merge/split chunks. That at least mitigates some of the pain of this issue. With JEP387 we have a way more fluid way to merge/split chunks. That means that unmapping VirtualSpaceNode - though still done - has become not as important anymore. Bottomline: less of an issue since jdk11, will be a non-issue after jep387 hits.
17-08-2020
Not a duplicate.
04-06-2015
Could you explain why this is should be closed as a duplicate of JDK-8081508?
04-06-2015
This is a duplicate of https://bugs.openjdk.java.net/browse/JDK-8081508
04-06-2015
Relates to JDK-8035945, which can also cause metaspace fragmentation.
28-02-2014
I = Can trigger premature GCs and potential out of metaspace memory errors -> High L = Not very a common problem for normal applications -> Low W = Use a larger metaspace size -> Low HLL = P4
28-02-2014