Review request for 4917309 and 6864003

[Paul Hohensee]

Then just ignore what I said. :)

Paul

Karen Kinnear wrote:
> JVM_FindClassFromBootLoader is new with JDK7. Kumar added it.
>
> thanks,
> Karen
>
> On Jul 24, 2009, at 11:07 AM, Paul Hohensee wrote:
>
>> Can't remove it unless it's fixed in jdk6 as well as 7.  Also, one of 
>> these days we'll
>> get around to shipping current hotspot in jdk5 and maybe 1.4.2.  How 
>> would these
>> be affected?
>>
>> paul
>>
>> Keith McGuigan wrote:
>>>
>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>