-
Sub-task
-
Resolution: Fixed
-
P4
-
12.0.2, 13
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8226776 | 12.0.2 | Clifford Wayne | P4 | Resolved | Delivered |
In this release, Epsilon has been changed to accept GC requests and resize the metaspace to reduce the number of safepoints that are taken.
Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload (for example, a workload having lots of classes) needed to resize the metaspace, it relied on the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be generated, but it would not resize the metaspace. This would cause another safepoint to be generated soon afterwards without ever resizing the metaspace.
Before this release, the Epsilon GC was intended to provide minimal runtime overhead by not doing GC and by ignoring all incoming GC requests. However, when a metadata-heavy workload (for example, a workload having lots of classes) needed to resize the metaspace, it relied on the GC to resize the metadata at a GC safepoint. Shared GC code would enter the safepoint to call into GC for it. However, because Epsilon ignored the GC request, the safepoint would be generated, but it would not resize the metaspace. This would cause another safepoint to be generated soon afterwards without ever resizing the metaspace.
- backported by
-
JDK-8226776 Release Note: Epsilon GC Caused Excess Metaspace Resizing Safepoints
- Resolved