Review request for 4917309 and 6864003

[Karen Kinnear]

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
>>>>>
>>>>>
>>>>>
>>>
>>