Review request for 4917309 and 6864003 (original) (raw)

Paul Hohensee Paul.Hohensee at Sun.COM
Fri Jul 24 15:07:14 UTC 2009

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 JVMENTRY(jclass, JVMFindClassFromBootLoader(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. JVMFindClassFromBootLoader 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 JVMFindClassFromBootLoader to return null if class not found Summary: o Fix java.lang.ClassLoader to use the new VM entry point JVMFindClassFromBootLoader 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 JVMFindClassFromBootLoader 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

More information about the core-libs-dev mailing list