Review request for 4917309 and 6864003

[Mandy Chung]

David Holmes - Sun Microsystems wrote:
> Hi Mandy,
>
>  661 JVM_ENTRY(jclass, JVM_FindClassFromBootLoader(JNIEnv* env,
>  662                                               const char* name,
>  663                                               jboolean throwError))
>
> Can't we now drop the throwError parameter altogether?
>
Yes, I could.  I agree it doesn't need this throwError parameter.   I 
decide to leave it since it helps to avoid the synchronized pushes.  
JVM_FindClassFromBootLoader is already in a promoted build.   I can push 
the JDK fix and HotSpot fix at the same time.  Note that the JDK fix and 
HotSpot fix are pushed and integrated in two different gates and at 
different time.

If I modify the signature, I would have to push the HS fix first (say 
b68).  Wait until b68 is promoted, then I can push the JDK fix in b70.

If you strongly feel that I should drop the throwError parameter, I 
could make the change.

Thanks
Mandy
 
> Pity we can't make a similar fix to the extensions loader ...
>
> Cheers,
> David
>
> Mandy Chung said the following on 07/24/09 09:53:
>> This review request is for both the HotSpot runtime and the core libs 
>> teams.
>>
>> Fixed 4917309: (cl) Reduce internal usage of ClassNotFoundExceptions 
>> during class-loading
>> Fixed 6864003: Modify JVM_FindClassFromBootLoader to return null if 
>> class not found
>>
>> Summary:
>>  o Fix java.lang.ClassLoader to use the new VM entry point
>>    JVM_FindClassFromBootLoader for load a system class from
>>    the bootstrap classloader that will reduce the number
>>    of ClassNotFoundException objects thrown by the application
>>    class loader by 50%.  The remaining half of the 
>> ClassNotFoundException
>>    objects are thrown by the extension class loader which is the parent
>>    of the application class loader.
>>  o ClassLoader.loadClass and ClassLoader.findSystemClass will
>>    throw ClassNotFoundException as they are specified.
>>  o JVM_FindClassFromBootLoader is currently not used (going to
>>    used by the java launcher see 6864028). There is no issue
>>    of changing it to return null instead of throwing CNFE.
>>
>> Webrev:
>>   http://cr.openjdk.java.net/~mchung/4917309/hotspot-webrev/
>>   http://cr.openjdk.java.net/~mchung/4917309/jdk-webrev/
>>
>>
>> Thanks
>> Mandy
>>
>>
>>