RFR (s): JDK-8011802 NPG: init_dependencies in class loader data graph can cause invalid CLD
Mikael Gerdin
mikael.gerdin at oracle.com
Mon Apr 22 12:38:07 UTC 2013
Hi,
here is my suggested fix for the ClassLoaderData initialization issue
that David brought up in the review thread for JDK-8010196.
The problem:
Upon initialization of a ClassLoaderData (from
ClassLoaderDataGraph::add) the newly created CLD is added to the
ClassLoderData linked list and to the hidden field in the
java/lang/ClassLoader object before we call init_dependencies to create
the Java object array.
Since the creation of the object array can throw a Java Exception (OOME)
we need to be able to clean up if that happens.
The fix:
Instead of trying to undo what we did when adding the CLD I suggest that
we first try to init_dependencies and if that succeeds we proceed to try
to add the CLD to the ClassLoader and the list.
If two threads are simultaneously trying to create a CLD for a loader we
will now allocate a few unnecessary object arrays since we allocate them
optimistically but since we don't hang on to them they should not cause
any memory overhead.
I also took the liberty to change the way we signal that a CLD is for an
anonymous class to use a boolean instead of passing a null value to the
CLD** and moved all the code to write the CLD* into the ClassLoader to
ClassLoaderDataGraph::add. The code motion is necessary since
init_dependencies may trigger a GC and the CLD** which was passed in was
in fact a raw pointer into the ClassLoader in the Java heap.
Unfortunately I can't use CHECK_NULL when calling init_dependencies
since I need to delete the cld before returning.
Webrev: http://cr.openjdk.java.net/~mgerdin/8011802/webrev.0/
bugs.sun.com: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8011802
jbs: https://jbs.oracle.com/bugs/browse/JDK-8011802
/Mikael
More information about the hotspot-gc-dev
mailing list