Re: Review request for 4917309 and 6864003
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
Re: Review request for 4917309 and 6864003
Alan Bateman wrote: Mandy, I see in ClassLoader#loadClass that you still allow findBootstrapClassOrNull to throw CNF. I assume this is needed until there is a promoted build with the updated JVM_FindClassFromBootLoader, after which you will go back to clean it up - do I have this right? I leave the call to findBootstrapClassOrNull inside try-catch clause (1) to work with the existing VM and (2) I think it's better to leave it this way as opposed to do something like this: if (parent == null) { c = findBootstrapClassOrNull(name); } else { try { c = parent.loadClass(name, false); } catch (ClassNotFoundException e) { // ClassNotFoundException thrown if class not found // from the non-null parent class loader } } So that's the final version and no need to clean up. Mandy
hg: jdk7/tl/langtools: 6863746: javap should not scan ct.sym by default
Changeset: 631425840408 Author:jjg Date: 2009-07-24 14:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/631425840408 6863746: javap should not scan ct.sym by default Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javap/JavapFileManager.java ! src/share/classes/com/sun/tools/javap/JavapTask.java ! src/share/classes/com/sun/tools/javap/Options.java + test/tools/javap/T6863746.java
Re: Faster HashMap implementation
Doug, On Wed, Jul 22, 2009 at 8:21 PM, Doug Lead...@cs.oswego.edu wrote: On further evaluating it (among other possible HashMap replacements), I'm not convinced that they are enough better to commit. Size:... 9216 36864 147456 589824 HashMap ...45 97208273 V2 ...40 78188257 Gain +12% +24% +11%+6% More than 10% average improvement on big maps, not worse on tiny maps, less memory usage - not a bad result imho Similarly for the mixed-side-array approach of Alex's Compact/Fast HashMap. My version is a chained map, not an open map, So concerns about locality and hit rates does not apply. And with defragmentation there is not so many cache misses on collisions. Alex
hg: jdk7/tl/jdk: 2 new changesets
Changeset: abb221aa23e4 Author:martin Date: 2009-07-24 18:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abb221aa23e4 6639443: Character.toCodePoint and Character.toSurrogates can be optimized Summary: rearranging code saves 5 bytes of bytecode Reviewed-by: sherman ! src/share/classes/java/lang/Character.java Changeset: e749fe2ed114 Author:martin Date: 2009-07-24 18:24 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e749fe2ed114 6639458: Improvements to Surrogate.java Summary: Optimize Surrogate.java Reviewed-by: sherman ! src/share/classes/sun/nio/cs/Surrogate.java