Review request for 4917309 and 6864003

[Keith McGuigan]

I would prefer that we avoid requiring synchronous pushes (so I guess I 
think we should leave that parameter in for now).

If anything, maybe file a low-priority RFE to remove that parameter later?

--
- Keith

Mandy Chung wrote:
> 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
>>>
>>>
>>>
>