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 05:38:07 PDT 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-runtime-dev mailing list