-
Bug
-
Resolution: Fixed
-
P2
-
8, 8u20, 9
-
b23
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8063492 | 8u45 | Markus Grönlund | P2 | Resolved | Fixed | b01 |
JDK-8048875 | 8u40 | Markus Grönlund | P2 | Resolved | Fixed | b01 |
JDK-8050186 | 8u31 | Markus Grönlund | P2 | Resolved | Fixed | b01 |
JDK-8050043 | 8u25 | Markus Grönlund | P2 | Resolved | Fixed | b07 |
JDK-8048686 | 8u20 | Markus Grönlund | P2 | Closed | Fixed | b22 |
JDK-8070777 | emb-8u47 | Markus Grönlund | P2 | Resolved | Fixed | team |
JDK-8053285 | emb-8u26 | Markus Grönlund | P2 | Resolved | Fixed | b17 |
The "8038212: Method::is_valid_method() check has performance regression
impact for stackwalking" - changeset introduced a change in how the ClassLoaderDataGraph::_unloading list of ClassLoaderData's is purged.
This change to the purging of the CLD’s work the same as before for most GC's, but when using CMS GC, SystemDictionary::do_unloading() is called twice with no explicit purge call in between. On the second call (post-sweep), we can now get stale class loader oops delivered as part of the Klass closure callbacks from the _unloading list. Again, this is because there is no explicit purge call in between these two entries to SystemDictionary::do_unloading() - and being CMS and concurrent, it is very hard to accommodate a timely and proper purge call here.
The first do_unloading call comes after CMS concurrent marking, and the second comes from a Full GC triggered while sweeping the CMS heap.
This fix ensures the unloading purge mechanism to work correctly also for the CMS collector, in that only CLDs with non-reclaimed class loader oops will deliver klasses from the _unloading list. In addition, this will ensure a single "logical" pass is achieved when iterating the unloading list in-between purges (avoiding the processing of the same data twice).
This fix is precipitated by nightly testing failures with CMS after the introduction of 8038212: Method::is_valid_method() check has performance regression
impact for stackwalking" - for example "nsk/sysdict/vm/stress/jck12a//sysdictj12a008" which is crashing because of following up stale klass loader oop's from the ClassLoaderDataGraph::_unloading list.
Additional nightly test failures tracked in: https://bugs.openjdk.java.net/browse/JDK-8044677
- backported by
-
JDK-8048875 Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops
-
- Resolved
-
-
JDK-8050043 Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops
-
- Resolved
-
-
JDK-8050186 Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops
-
- Resolved
-
-
JDK-8053285 Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops
-
- Resolved
-
-
JDK-8063492 Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops
-
- Resolved
-
-
JDK-8070777 Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops
-
- Resolved
-
-
JDK-8048686 Ensure ClassLoaderDataGraph::classes_unloading_do only delivers klasses from CLDs with non-reclaimed class loader oops
-
- Closed
-