Review request for 4917309 and 6864003
Keith.McGuigan at Sun.COM
Fri Jul 24 13:23:07 UTC 2009
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?
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.
>> Pity we can't make a similar fix to the extensions loader ...
>> Mandy Chung said the following on 07/24/09 09:53:
>>> This review request is for both the HotSpot runtime and the core libs
>>> Fixed 4917309: (cl) Reduce internal usage of ClassNotFoundExceptions
>>> during class-loading
>>> Fixed 6864003: Modify JVM_FindClassFromBootLoader to return null if
>>> class not found
>>> 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
>>> 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.
More information about the core-libs-dev