RFR (s): JDK-8011802 NPG: init_dependencies in class loader data graph can cause invalid CLD

[Stefan Karlsson]

Looks good.

StefanK

On 2013-04-22 14:38, Mikael Gerdin wrote:
> 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