-
Bug
-
Resolution: Fixed
-
P3
-
8
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8006473 | 8 | Jon Masamitsu | P3 | Resolved | Fixed | b74 |
Reflection classloader and anonymous classloaders typically only load a single class so should
have a small chunk size than other classlaoders.
The goal of this fix is to not throw out-of-memory exceptions on the test262parallel nashorn test.
While this addition of the specialized does reduce the memory usage for Metaspace chunks, it
has not eliminated the OOME.
Part of the change was to add the special chunk size for the initial chunk for reflection and anonymous
classloaders. There was a bug in setting the initial chunk which caused the allocation of a new chunk
instead of the reuse of the chunk. Fixed that fixed some of the OOME's.
For large allocations a humongous chunk is allocated. The humongous chunk was only being
used for that single large allocation. When a new Virtualspace was allocated for a humongous
chunk allocation, 1 page of the Virtualspace was committed. That was a bug in that the 1 page
looked like it was already being used. Fixed it so that no pages are initially allocated.
When gc_locker was active sometimes the GC for a metadata allocation was locked out. The
satify_failed_metaspace_allocation() was not correctly trying again if GC was locked out.
Fixed that by doing the same test done with of GC's.
have a small chunk size than other classlaoders.
The goal of this fix is to not throw out-of-memory exceptions on the test262parallel nashorn test.
While this addition of the specialized does reduce the memory usage for Metaspace chunks, it
has not eliminated the OOME.
Part of the change was to add the special chunk size for the initial chunk for reflection and anonymous
classloaders. There was a bug in setting the initial chunk which caused the allocation of a new chunk
instead of the reuse of the chunk. Fixed that fixed some of the OOME's.
For large allocations a humongous chunk is allocated. The humongous chunk was only being
used for that single large allocation. When a new Virtualspace was allocated for a humongous
chunk allocation, 1 page of the Virtualspace was committed. That was a bug in that the 1 page
looked like it was already being used. Fixed it so that no pages are initially allocated.
When gc_locker was active sometimes the GC for a metadata allocation was locked out. The
satify_failed_metaspace_allocation() was not correctly trying again if GC was locked out.
Fixed that by doing the same test done with of GC's.
- backported by
-
JDK-8006473 NPG: Add specialized Metachunk sizes for reflection and anonymous classloaders for test262parallel
- Resolved
- relates to
-
JDK-8011610 NPG: Class metaspace limits number of classes for UseCompressedKlassPointers
- Closed