From vladimir.kozlov at oracle.com Wed Jun 1 12:03:34 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 01 Jun 2011 19:03:34 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20110601190339.A29D647AD5@hg.openjdk.java.net> Changeset: 9340a27154cb Author: kvn Date: 2011-05-25 21:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9340a27154cb 7048332: Cadd_cmpLTMask doesn't handle 64-bit tmp register properly Summary: Use ins_encode %{ %} form to encode cadd_cmpLTMask() instruction and remove unused code. Reviewed-by: never ! src/cpu/x86/vm/x86_64.ad + test/compiler/7048332/Test7048332.java Changeset: ea0da5474c23 Author: kvn Date: 2011-05-27 12:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ea0da5474c23 7047069: Array can dynamically change size when assigned to an object field Summary: Fix initialization of a newly-allocated array with arraycopy Reviewed-by: never ! src/share/vm/opto/library_call.cpp + test/compiler/7047069/Test7047069.java From tom.rodriguez at oracle.com Wed Jun 1 14:43:23 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 01 Jun 2011 21:43:23 +0000 Subject: hg: jdk7/hotspot/hotspot: 7047961: JSR 292 MethodHandleWalk swap args doesn't handle T_LONG and T_DOUBLE properly Message-ID: <20110601214327.EFF6C47ADC@hg.openjdk.java.net> Changeset: 88559690c95a Author: never Date: 2011-05-26 14:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/88559690c95a 7047961: JSR 292 MethodHandleWalk swap args doesn't handle T_LONG and T_DOUBLE properly Reviewed-by: kvn, jrose ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp From igor.veresov at oracle.com Wed Jun 1 17:16:41 2011 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Thu, 02 Jun 2011 00:16:41 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20110602001656.625C847AE2@hg.openjdk.java.net> Changeset: 442ef93966a9 Author: iveresov Date: 2011-05-26 13:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/442ef93966a9 7047491: C1: registers saved incorrectly when calling checkcast_arraycopy stub Summary: Save and restore the argument registers around the call to checkcast_arraycopy Reviewed-by: never, roland ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 3f7a95be91ef Author: iveresov Date: 2011-06-01 12:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3f7a95be91ef Merge Changeset: 7c907a50c1bb Author: iveresov Date: 2011-06-01 14:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7c907a50c1bb Merge From vladimir.kozlov at oracle.com Fri Jun 3 11:50:45 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 03 Jun 2011 18:50:45 +0000 Subject: hg: jdk7/hotspot/hotspot: 6956668: misbehavior of XOR operator (^) with int Message-ID: <20110603185049.3B82947B62@hg.openjdk.java.net> Changeset: f88fb2fa90cf Author: kvn Date: 2011-05-31 10:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f88fb2fa90cf 6956668: misbehavior of XOR operator (^) with int Summary: optimize cmp_ne(xor(X,1),0) to cmp_eq(X,0) only for boolean values X. Reviewed-by: never ! src/share/vm/opto/subnode.cpp + test/compiler/6956668/Test6956668.java From john.r.rose at oracle.com Fri Jun 3 16:56:10 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 03 Jun 2011 23:56:10 +0000 Subject: hg: hsx/hotspot-main/jdk: 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated Message-ID: <20110603235632.B8B3147B71@hg.openjdk.java.net> Changeset: 802994506203 Author: jrose Date: 2011-06-03 11:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/802994506203 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated Reviewed-by: kvn, never, ysr ! src/share/classes/java/lang/invoke/SwitchPoint.java ! test/java/lang/invoke/JavaDocExamplesTest.java From john.r.rose at oracle.com Fri Jun 3 18:07:33 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 04 Jun 2011 01:07:33 +0000 Subject: hg: jdk7/hotspot/jdk: 4 new changesets Message-ID: <20110604010847.3021347B76@hg.openjdk.java.net> Changeset: 8318d03e1766 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8318d03e1766 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError Summary: Wrap invokedynamic linkage errors in BootstrapMethodError, as needed. Reviewed-by: never ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 0b8b6eace473 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0b8b6eace473 7050328: (jsr-292) findConstructor throws ExceptionInInitializerError if run under SecurityManager Summary: Wrap system property and reflection accesses under doPrivileged. Ensure constant pool linkage bypasses the SM as specified. Reviewed-by: kvn, never ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java Changeset: 34481a4012c3 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/34481a4012c3 7049122: java/lang/invoke/RicochetTest.java with MAX_ARITY=255 in -Xcomp mode overflows code cache Summary: reduce the scope of the unit test (mark high water mark of testing with @ignore tags) Reviewed-by: never ! test/java/lang/invoke/RicochetTest.java Changeset: 802994506203 Author: jrose Date: 2011-06-03 11:20 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/802994506203 7051206: JSR 292 method name SwitchPoint.isValid is misleading to unwary users; should be hasBeenInvalidated Reviewed-by: kvn, never, ysr ! src/share/classes/java/lang/invoke/SwitchPoint.java ! test/java/lang/invoke/JavaDocExamplesTest.java From erik.trimble at oracle.com Fri Jun 3 19:34:16 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Sat, 04 Jun 2011 02:34:16 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20110604023425.0539747B7A@hg.openjdk.java.net> Changeset: ba550512d3b2 Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ba550512d3b2 7049415: Failure of resolution of sym.reference to the c.s.s. should be wrapped in BootstrapMethodError Summary: Delegate invokedynamic linkage errors to MethodHandleNatives.raiseException. Reviewed-by: never ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: c76d5f44a3fe Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c76d5f44a3fe 7049410: JSR 292 old method name MethodHandle.invokeGeneric should not be accepted by the JVM Summary: change the default setting of the flag AllowInvokeGeneric to false Reviewed-by: never ! src/share/vm/runtime/globals.hpp Changeset: deaa3ce90583 Author: coleenp Date: 2011-06-02 14:17 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/deaa3ce90583 7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63 Summary: Removed extra change from another bug fix that caused this regression Reviewed-by: phh, dcubed, kvn, kamg, never ! src/share/vm/oops/methodOop.cpp Changeset: e5ae807761b8 Author: trims Date: 2011-06-03 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e5ae807761b8 Added tag hs21-b14 for changeset 62f39d40ebf1 ! .hgtags From vladimir.kozlov at oracle.com Tue Jun 7 15:59:29 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 07 Jun 2011 22:59:29 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20110607225936.D11CB47C6C@hg.openjdk.java.net> Changeset: f56542cb325a Author: never Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f56542cb325a 7050554: JSR 292 - need optimization for selectAlternative Reviewed-by: kvn, jrose ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp Changeset: f7d55ea6ee56 Author: never Date: 2011-06-03 22:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f7d55ea6ee56 7045514: SPARC assembly code for JSR 292 ricochet frames Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp + src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/registerMap_sparc.hpp ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 293f68bda347 Author: kvn Date: 2011-06-04 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/293f68bda347 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity Summary: Mark all associated (same box and obj) lock and unlock nodes for elimination if some of them marked already. Reviewed-by: iveresov, never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp From erik.trimble at oracle.com Tue Jun 7 16:45:39 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 07 Jun 2011 23:45:39 +0000 Subject: hg: jdk7/hotspot: 3 new changesets Message-ID: <20110607234539.83A8C47C6E@hg.openjdk.java.net> Changeset: 93d2590fd849 Author: jeff Date: 2011-05-27 14:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/93d2590fd849 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 55e9ebf03218 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/55e9ebf03218 Merge Changeset: 2d38c2a79c14 Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/2d38c2a79c14 Added tag jdk7-b145 for changeset 55e9ebf03218 ! .hgtags From erik.trimble at oracle.com Tue Jun 7 16:45:49 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 07 Jun 2011 23:45:49 +0000 Subject: hg: jdk7/hotspot/corba: 5 new changesets Message-ID: <20110607234557.EFAD647C6F@hg.openjdk.java.net> Changeset: 93e77c49b3bb Author: miroslawzn Date: 2011-05-26 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/93e77c49b3bb 7046882: Regression : JDK 7b123 : Enum exchanged as parameters using CORBA call results in Exception Reviewed-by: raginip ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java Changeset: 643f267ca234 Author: jeff Date: 2011-05-27 14:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/643f267ca234 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 7839048ec99e Author: jeff Date: 2011-05-27 15:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/7839048ec99e Merge Changeset: 77ec0541aa2a Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/77ec0541aa2a Merge Changeset: 770227a4087e Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/770227a4087e Added tag jdk7-b145 for changeset 77ec0541aa2a ! .hgtags From erik.trimble at oracle.com Tue Jun 7 16:48:05 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 07 Jun 2011 23:48:05 +0000 Subject: hg: jdk7/hotspot/hotspot: 6 new changesets Message-ID: <20110607234817.C084247C70@hg.openjdk.java.net> Changeset: 1aa57c62d0e4 Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/1aa57c62d0e4 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 63d3fb179034 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/63d3fb179034 Merge Changeset: 82a81d5c5700 Author: trims Date: 2011-06-03 20:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/82a81d5c5700 Merge Changeset: 48ceeec759b6 Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/48ceeec759b6 Added tag jdk7-b145 for changeset 82a81d5c5700 ! .hgtags Changeset: 14d3cdeabc9f Author: trims Date: 2011-06-07 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/14d3cdeabc9f Added tag hs21-b15 for changeset 82a81d5c5700 ! .hgtags Changeset: 67c0f5f5deac Author: trims Date: 2011-06-07 16:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/67c0f5f5deac Merge From erik.trimble at oracle.com Tue Jun 7 16:49:16 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 07 Jun 2011 23:49:16 +0000 Subject: hg: jdk7/hotspot/jaxp: 5 new changesets Message-ID: <20110607234916.8981A47C72@hg.openjdk.java.net> Changeset: bdf77cbd9958 Author: ohair Date: 2011-05-19 08:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/bdf77cbd9958 7044493: Incorrectly formated GPL headers in JDK7 JAXP source drop Reviewed-by: joehw ! jaxp.properties Changeset: 775dd77e4730 Author: lana Date: 2011-05-20 21:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/775dd77e4730 Merge Changeset: a70a042c8600 Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/a70a042c8600 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 10ca7570f47f Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/10ca7570f47f Merge Changeset: bcd31fa1e3c6 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/bcd31fa1e3c6 Added tag jdk7-b145 for changeset 10ca7570f47f ! .hgtags From erik.trimble at oracle.com Tue Jun 7 16:49:26 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 07 Jun 2011 23:49:26 +0000 Subject: hg: jdk7/hotspot/jaxws: 4 new changesets Message-ID: <20110607234926.9BA2947C73@hg.openjdk.java.net> Changeset: c902e39c384e Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/c902e39c384e 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: bcca8afc019f Author: ohair Date: 2011-06-01 10:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/bcca8afc019f 7049699: Problem with xml/jax-ws Reviewed-by: ramap ! jaxws.properties Changeset: 42bfba80beb7 Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/42bfba80beb7 Merge Changeset: 6ec12c60ad13 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/6ec12c60ad13 Added tag jdk7-b145 for changeset 42bfba80beb7 ! .hgtags From erik.trimble at oracle.com Tue Jun 7 16:50:16 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 07 Jun 2011 23:50:16 +0000 Subject: hg: jdk7/hotspot/jdk: 36 new changesets Message-ID: <20110607235648.9F3B647C74@hg.openjdk.java.net> Changeset: bc97b962330e Author: mfang Date: 2011-05-26 20:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bc97b962330e 7045184: GTK L&F doesn't have hotkeys in jdk7 b141, while b139 has. Reviewed-by: yhuang, ogino ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties Changeset: 6943c4d9caa3 Author: mfang Date: 2011-05-31 13:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6943c4d9caa3 Merge Changeset: 7c5bc5a807ee Author: dholmes Date: 2011-05-27 19:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7c5bc5a807ee 7024120: Verify reduced JRE contents for java 7 Summary: stripped all symbols from libs and executables to reduce JRE size. Restored missing classes needed to pass JCK in headless mode Reviewed-by: bobv, ohair ! make/common/Defs-embedded.gmk ! make/common/Release-embedded.gmk Changeset: f4895b3fe1be Author: dholmes Date: 2011-05-31 17:28 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f4895b3fe1be Merge Changeset: eab27338b3d9 Author: schien Date: 2011-06-01 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eab27338b3d9 Merge Changeset: 8d91855a1f4e Author: prr Date: 2011-05-27 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8d91855a1f4e 7046587: Outlines in OTF/CFF fonts are misclassified as quadratic curves Reviewed-by: igor ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/NullFontScaler.java Changeset: 0b0b92707cf5 Author: bae Date: 2011-05-30 12:05 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0b0b92707cf5 7032904: XRender: Java2Demo : Infinite loop in Java_sun_java2d_loops_MaskBlit_MaskBlit on OEL 5.6 x64 Reviewed-by: prr ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 290daca0a693 Author: prr Date: 2011-05-30 22:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/290daca0a693 7049874: OpenJDK Build breakage fix: freetypescaler.c needs to match updated signature Reviewed-by: lana, igor ! src/share/native/sun/font/freetypeScaler.c Changeset: b351af09bfa3 Author: lana Date: 2011-06-02 13:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b351af09bfa3 Merge Changeset: d2081a1f417f Author: bagiras Date: 2011-05-27 11:45 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d2081a1f417f 7045174: Most of the tests in awt area fails with jdk 7b142 on windows with -Xcheck:jni Reviewed-by: art, denis ! src/windows/native/sun/windows/awt_Object.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 000a845b1e38 Author: denis Date: 2011-05-28 12:56 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/000a845b1e38 7046325: Broken links in java.awt.Toolkit's javadoc Reviewed-by: dav, yan ! src/share/classes/java/awt/Toolkit.java Changeset: eab94f59b6dc Author: dcherepanov Date: 2011-05-30 13:25 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/eab94f59b6dc 7045354: Korean IME's Hanja candidate window is not displayed on IMFDemo Reviewed-by: art, ant ! src/windows/native/sun/windows/awt_Component.cpp Changeset: f05164caa490 Author: serb Date: 2011-05-30 17:16 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f05164caa490 7045193: interactive JCK tests java_awt/interactive/FileDialogTests fail Reviewed-by: dcherepanov, dav, art, denis ! src/solaris/classes/sun/awt/X11/GtkFileDialogPeer.java Changeset: b955226868af Author: lana Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b955226868af Merge Changeset: 1fbaf2b688a6 Author: rupashka Date: 2011-05-24 11:37 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1fbaf2b688a6 7045593: Possible Regression : JTextfield cursor placement behavior algorithm has changed. Reviewed-by: peterz ! src/share/classes/javax/swing/text/Utilities.java + test/javax/swing/text/Utilities/bug7045593.java Changeset: 442237d3ec2c Author: rupashka Date: 2011-05-28 11:55 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/442237d3ec2c 7048204: NPE from NimbusLookAndFeel.addDefault Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java + test/javax/swing/plaf/nimbus/Test7048204.java Changeset: 386516fdf40b Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/386516fdf40b Merge Changeset: 0a80650409e1 Author: mullan Date: 2011-05-24 14:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0a80650409e1 7044443: Permissions resolved incorrectly for jar protocol (Patch from bugs.openjdk.java.net) Reviewed-by: alanb, chegar Contributed-by: dbhole at redhat.com ! src/share/classes/sun/security/provider/PolicyFile.java + test/java/security/Policy/GetPermissions/JarURL.java Changeset: ace2dfdecda1 Author: mullan Date: 2011-05-24 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ace2dfdecda1 Merge Changeset: 70942be348af Author: jeff Date: 2011-05-27 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/70942be348af 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: b49a0af85821 Author: vinnie Date: 2011-05-30 16:37 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b49a0af85821 7049173: Replace the software license for ECC native code Reviewed-by: alanb ! src/share/native/sun/security/ec/impl/ec.c ! src/share/native/sun/security/ec/impl/ec.h ! src/share/native/sun/security/ec/impl/ec2.h ! src/share/native/sun/security/ec/impl/ec2_163.c ! src/share/native/sun/security/ec/impl/ec2_193.c ! src/share/native/sun/security/ec/impl/ec2_233.c ! src/share/native/sun/security/ec/impl/ec2_aff.c ! src/share/native/sun/security/ec/impl/ec2_mont.c ! src/share/native/sun/security/ec/impl/ec_naf.c ! src/share/native/sun/security/ec/impl/ecc_impl.h ! src/share/native/sun/security/ec/impl/ecdecode.c ! src/share/native/sun/security/ec/impl/ecl-curve.h ! src/share/native/sun/security/ec/impl/ecl-exp.h ! src/share/native/sun/security/ec/impl/ecl-priv.h ! src/share/native/sun/security/ec/impl/ecl.c ! src/share/native/sun/security/ec/impl/ecl.h ! src/share/native/sun/security/ec/impl/ecl_curve.c ! src/share/native/sun/security/ec/impl/ecl_gf.c ! src/share/native/sun/security/ec/impl/ecl_mult.c ! src/share/native/sun/security/ec/impl/ecp.h ! src/share/native/sun/security/ec/impl/ecp_192.c ! src/share/native/sun/security/ec/impl/ecp_224.c ! src/share/native/sun/security/ec/impl/ecp_256.c ! src/share/native/sun/security/ec/impl/ecp_384.c ! src/share/native/sun/security/ec/impl/ecp_521.c ! src/share/native/sun/security/ec/impl/ecp_aff.c ! src/share/native/sun/security/ec/impl/ecp_jac.c ! src/share/native/sun/security/ec/impl/ecp_jm.c ! src/share/native/sun/security/ec/impl/ecp_mont.c ! src/share/native/sun/security/ec/impl/logtab.h ! src/share/native/sun/security/ec/impl/mp_gf2m-priv.h ! src/share/native/sun/security/ec/impl/mp_gf2m.c ! src/share/native/sun/security/ec/impl/mp_gf2m.h ! src/share/native/sun/security/ec/impl/mpi-config.h ! src/share/native/sun/security/ec/impl/mpi-priv.h ! src/share/native/sun/security/ec/impl/mpi.c ! src/share/native/sun/security/ec/impl/mpi.h ! src/share/native/sun/security/ec/impl/mplogic.c ! src/share/native/sun/security/ec/impl/mplogic.h ! src/share/native/sun/security/ec/impl/mpmontg.c ! src/share/native/sun/security/ec/impl/mpprime.h ! src/share/native/sun/security/ec/impl/oid.c ! src/share/native/sun/security/ec/impl/secitem.c ! src/share/native/sun/security/ec/impl/secoidt.h Changeset: 4ed7c877a463 Author: michaelm Date: 2011-05-30 23:36 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4ed7c877a463 7042550: Reintegrate 6569621 Reviewed-by: chegar, alanb ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketPermission.java + src/share/classes/sun/net/RegisteredDomain.java ! src/share/classes/sun/net/www/URLConnection.java ! src/share/classes/sun/net/www/http/HttpClient.java Changeset: c79a089ae13b Author: wetmore Date: 2011-05-31 12:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c79a089ae13b 7042097: JDK 7's Unlimited Cryptographic Policy bundle text files must be updated. Reviewed-by: valeriep ! make/javax/crypto/Makefile Changeset: a00f48c96345 Author: lancea Date: 2011-06-02 12:02 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a00f48c96345 7049107: Cannot call initCause() on BatchUpdateException Reviewed-by: darcy ! src/share/classes/java/sql/BatchUpdateException.java Changeset: 39de8937c1d8 Author: lana Date: 2011-06-02 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/39de8937c1d8 Merge Changeset: e8e6cdff5995 Author: trims Date: 2011-06-03 20:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e8e6cdff5995 Merge Changeset: 8f19b165347b Author: bae Date: 2011-06-04 23:08 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/8f19b165347b 7042594: 3 testis api/java_awt/Color/ICC_ProfileRGB/index.html fail against RI b138 OEL6x64. Reviewed-by: prr ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! test/sun/java2d/cmm/ProfileOp/ReadWriteProfileTest.java + test/sun/java2d/cmm/ProfileOp/SetDataTest.java Changeset: bbb4cef2208b Author: lana Date: 2011-06-04 17:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/bbb4cef2208b Merge Changeset: 03a828e368ca Author: rupashka Date: 2011-06-04 01:13 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/03a828e368ca 6977587: GTK L&F: jnlp: java.io.IOException thrown when choosing more than 1 file in the dialog Reviewed-by: alexp ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java Changeset: 6c9c55ae313b Author: lana Date: 2011-06-03 22:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6c9c55ae313b Merge Changeset: e81d259442ed Author: lana Date: 2011-06-04 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e81d259442ed Merge Changeset: 53d759eb580c Author: alanb Date: 2011-06-04 11:18 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/53d759eb580c 7050358: (fs spec) Path.toUri doesn't allow custom providers to use opaque URIs Reviewed-by: sherman ! src/share/classes/java/nio/file/Path.java Changeset: 49aef5a5416e Author: mullan Date: 2011-06-04 06:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/49aef5a5416e 7050329: test/java/security/Policy/GetPermissions/JarURL.java fails on Windows Reviewed-by: alanb ! test/java/security/Policy/GetPermissions/JarURL.java + test/java/security/Policy/GetPermissions/JarURL.policy Changeset: 1f39ca0b9598 Author: mullan Date: 2011-06-04 06:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1f39ca0b9598 Merge Changeset: 1e04b38b3824 Author: lana Date: 2011-06-04 17:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/1e04b38b3824 Merge Changeset: 7a341c412ea9 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7a341c412ea9 Added tag jdk7-b145 for changeset 1e04b38b3824 ! .hgtags From erik.trimble at oracle.com Tue Jun 7 16:58:54 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 07 Jun 2011 23:58:54 +0000 Subject: hg: jdk7/hotspot/langtools: 5 new changesets Message-ID: <20110607235910.9BD3147C75@hg.openjdk.java.net> Changeset: 6bb526ccf5ff Author: mcimadamore Date: 2011-05-23 11:55 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6bb526ccf5ff 7046348: Regression: javac complains of missing classfile for a seemingly unrelated interface Summary: Types.implementation forces unnecessary symbol completion on superinterfaces of a given type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/scope/7046348/EagerInterfaceCompletionTest.java Changeset: 6211df69f7e0 Author: jeff Date: 2011-05-27 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6211df69f7e0 7045697: JDK7 THIRD PARTY README update Reviewed-by: lana ! THIRD_PARTY_README Changeset: 6762754eb7c0 Author: jjg Date: 2011-06-01 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/6762754eb7c0 7042623: Regression: javac silently crash when attributing non-existent annotation Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/T7042623.java + test/tools/javac/T7042623.out Changeset: c455e2ae5c93 Author: lana Date: 2011-06-02 13:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c455e2ae5c93 Merge Changeset: 9ff91d0e7154 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9ff91d0e7154 Added tag jdk7-b145 for changeset c455e2ae5c93 ! .hgtags From john.coomes at oracle.com Tue Jun 7 18:03:27 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Wed, 08 Jun 2011 01:03:27 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20110608010338.3192647C7F@hg.openjdk.java.net> Changeset: 537a4053b0f9 Author: ysr Date: 2011-05-23 16:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/537a4053b0f9 7042740: CMS: assert(n> q) failed: Looping at: ... blockOffsetTable.cpp:557 Summary: Do a one-step look-ahead, when sweeping free or garbage blocks, to avoid overstepping sweep limit, which may become a non-block-boundary because of a heap expansion delta coalescing with a previously co-terminal free block. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/blockOffsetTable.cpp Changeset: f153114134c8 Author: jcoomes Date: 2011-06-07 13:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f153114134c8 Merge From dmitriy.samersoff at oracle.com Wed Jun 8 18:52:58 2011 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Thu, 09 Jun 2011 01:52:58 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20110609015309.DC55947D4A@hg.openjdk.java.net> Changeset: d3b9f2be46ab Author: coleenp Date: 2011-05-21 15:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d3b9f2be46ab 7033141: assert(has_cp_cache(i)) failed: oob Summary: Unrewrite bytecodes for OOM error allocating the constant pool cache. Reviewed-by: dcubed, acorn, never ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 9dd6c4ba364f Author: coleenp Date: 2011-06-02 14:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9dd6c4ba364f 7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63 Summary: Removed extra change from another bug fix that caused this regression Reviewed-by: phh, dcubed, kvn, kamg, never ! src/share/vm/oops/methodOop.cpp Changeset: 96c891ebe56a Author: coleenp Date: 2011-06-02 21:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/96c891ebe56a Merge ! src/share/vm/prims/methodHandleWalk.cpp Changeset: ae1d716e395c Author: dsamersoff Date: 2011-06-09 01:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ae1d716e395c Merge From svalentine at concentris-systems.com Fri Jun 10 22:58:31 2011 From: svalentine at concentris-systems.com (Scott Valentine) Date: Fri, 10 Jun 2011 19:58:31 -1000 Subject: SMP JNI issue, UseMembar workaround resolves it Message-ID: <53e4024f2292fb00f77874be668c86b7.squirrel@www.concentris-systems.com> We ran into an issue where our application would consistently crash with a segmentation violation after roughly 15 minutes to 90 minutes of runtime. It's not exactly a bug, but I thought it would be helpful to post the information here for other folks, and to hopefully support the great work of OpenJDK developers down the road. The quick details are that we consistently die without much error detail (just a simple segmentation violation printout) when our code enters JNI, does some stuff, and then calls back into the VM. The JNI_ENTRY fails when calling transition_from_native. The client application is running on an Asus Aspire-One netbook (Atom N270, dual core @800MHz) with OpenJDK-1.6.0-20-1.9.7. A gdb stack trace and jstack dump is attached for details on what is happening. More details on the system structure are included below for those interested, but basically it is a moderately threaded, intensively JNI application running under the Equinox OSGi runtime. It was a little tough to debug, as the clients are remote and I have to go through multiple ssh back-doors. We initially suspected our JNI middleware, but after getting the necessary debugging symbols, tools, and builds in place, we found that it was always crashing on the write_memory_serialize_page call when attempting JNI_ENTRY after spending some time in the native code. It never even got to the point of reference values like the VM env, jobject, etc. Anyhow, the source for the transition_from_native call led us to try the -X:+UseMembar option which seems to have resolved the issue. Anyhow, I hope the trace info is helpful, and please let me know if I can provide more info. I can't spare a ton of cycles, but I would be happy to contribute as time permits. Here are the application details: As mentioned previously, the application is running in the Equinox OSGi framework, and it relies heavily on two JNI libraries: the RXTX library (2.1-7r2), and a middleware called opensplice DDS (5.4.1). Opensplice is a shared memory model runtime that runs as three seperate processes, and has a JNI interface into the framework. The application has two serial devices (two RXTX threads), and we have a thread for each (two more threads) that does blocking reads on those ports. These threads put data into a BlockingQueue, which has another thread that takes data from the queue and processes it (two more threads). These threads process the data, make JNI calls into the DDS middleware (this is where the failures have, at least so far, always occurred), and put some information into another Blocking Queue. There are two other application threads (total of eight now). The first periodically writes to one of the serial port. The other thread handles the second blocking Queue and also makes JNI calls into the DDS middleware. Overall, there are three threads calling into that middleware independantly. I think there are something like 20 threads total, but three are the JVM threads, and 7 or so are related to Equinox and our launcher that don't really do anything unless the system is starting or stopping or doing something in the OSGi world. Thanks, and again, I hope this info can be helpfult to others. Scott Valentine Concentris Systems LLC Manoa Innovation Center, Suite #238 2800 Woodlawn Drive Honolulu, HI 96822 http://www.Concentris-Systems.com (808) 988-6100 -------------- next part -------------- A non-text attachment was scrubbed... Name: jstack_trace.log Type: application/octet-stream Size: 11247 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110610/38e69950/attachment-0003.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: jdb.log Type: application/octet-stream Size: 3876 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110610/38e69950/attachment-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: gdb.log Type: application/octet-stream Size: 5044 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110610/38e69950/attachment-0005.obj From David.Holmes at oracle.com Sat Jun 11 00:04:16 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 11 Jun 2011 17:04:16 +1000 Subject: SMP JNI issue, UseMembar workaround resolves it In-Reply-To: <53e4024f2292fb00f77874be668c86b7.squirrel@www.concentris-systems.com> References: <53e4024f2292fb00f77874be668c86b7.squirrel@www.concentris-systems.com> Message-ID: <4DF31370.4080507@oracle.com> Hi Scott, I'll try and take a deeper look at this but note that if a safepoint is pending the thread is supposed to "crash" in write_memory_serialize_page. The SEGV so generated should be handled by the VM and take the thread to the safepoint. It seems the signal is not being handled correctly. UseMembar will workaround this by not using the serialization page. If you observed this SEGV under gdb then it may be a red-herring as gdb is stopping the VM from handling the SEGV when it is actually an expected signal. When the real crash occurs what exactly gets reported? David Holmes Scott Valentine said the following on 06/11/11 15:58: > We ran into an issue where our application would consistently crash with a > segmentation violation after roughly 15 minutes to 90 minutes of runtime. > It's not exactly a bug, but I thought it would be helpful to post the > information here for other folks, and to hopefully support the great work > of OpenJDK developers down the road. > > The quick details are that we consistently die without much error detail > (just a simple segmentation violation printout) when our code enters JNI, > does some stuff, and then calls back into the VM. The JNI_ENTRY fails when > calling transition_from_native. > > The client application is running on an Asus Aspire-One netbook (Atom > N270, dual core @800MHz) with OpenJDK-1.6.0-20-1.9.7. A gdb stack trace > and jstack dump is attached for details on what is happening. More details > on the system structure are included below for those interested, but > basically it is a moderately threaded, intensively JNI application running > under the Equinox OSGi runtime. > > It was a little tough to debug, as the clients are remote and I have to go > through multiple ssh back-doors. We initially suspected our JNI > middleware, but after getting the necessary debugging symbols, tools, and > builds in place, we found that it was always crashing on the > write_memory_serialize_page call when attempting JNI_ENTRY after spending > some time in the native code. It never even got to the point of reference > values like the VM env, jobject, etc. Anyhow, the source for the > transition_from_native call led us to try the -X:+UseMembar option which > seems to have resolved the issue. > > Anyhow, I hope the trace info is helpful, and please let me know if I can > provide more info. I can't spare a ton of cycles, but I would be happy to > contribute as time permits. > > Here are the application details: > > As mentioned previously, the application is running in the Equinox OSGi > framework, and it relies heavily on two JNI libraries: the RXTX library > (2.1-7r2), and a middleware called opensplice DDS (5.4.1). Opensplice is a > shared memory model runtime that runs as three seperate processes, and has > a JNI interface into the framework. The application has two serial devices > (two RXTX threads), and we have a thread for each (two more threads) that > does blocking reads on those ports. These threads put data into a > BlockingQueue, which has another thread that takes data from the queue and > processes it (two more threads). These threads process the data, make JNI > calls into the DDS middleware (this is where the failures have, at least > so far, always occurred), and put some information into another Blocking > Queue. There are two other application threads (total of eight now). The > first periodically writes to one of the serial port. The other thread > handles the second blocking Queue and also makes JNI calls into the DDS > middleware. Overall, there are three threads calling into that middleware > independantly. > > I think there are something like 20 threads total, but three are the JVM > threads, and 7 or so are related to Equinox and our launcher that don't > really do anything unless the system is starting or stopping or doing > something in the OSGi world. > > Thanks, and again, I hope this info can be helpfult to others. > > Scott Valentine > > Concentris Systems LLC > Manoa Innovation Center, Suite #238 > 2800 Woodlawn Drive > Honolulu, HI 96822 > > http://www.Concentris-Systems.com > > (808) 988-6100 From David.Holmes at oracle.com Sat Jun 11 05:07:35 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 11 Jun 2011 22:07:35 +1000 Subject: SMP JNI issue, UseMembar workaround resolves it In-Reply-To: <4DF31370.4080507@oracle.com> References: <53e4024f2292fb00f77874be668c86b7.squirrel@www.concentris-systems.com> <4DF31370.4080507@oracle.com> Message-ID: <4DF35A87.50903@oracle.com> Correction ... David Holmes said the following on 06/11/11 17:04: > I'll try and take a deeper look at this but note that if a safepoint is > pending the thread is supposed to "crash" in > write_memory_serialize_page. The SEGV so generated should be handled by > the VM and take the thread to the safepoint. The SEGV handler doesn't take the thread to the safepoint it just delays the thread until the serialization page is unprotected. The subsequent state transition logic will take the thread to the safepoint if needed. They thing is to see exactly what is reported when the real crash occurs. If we get a simple OS-level abort message then the VM signal handler did not get invoked which may indicate that native code has changed the installed signal handlers. David > It seems the signal is not > being handled correctly. UseMembar will workaround this by not using the > serialization page. > > If you observed this SEGV under gdb then it may be a red-herring as gdb > is stopping the VM from handling the SEGV when it is actually an > expected signal. > > When the real crash occurs what exactly gets reported? > > David Holmes > > Scott Valentine said the following on 06/11/11 15:58: >> We ran into an issue where our application would consistently crash >> with a >> segmentation violation after roughly 15 minutes to 90 minutes of runtime. >> It's not exactly a bug, but I thought it would be helpful to post the >> information here for other folks, and to hopefully support the great work >> of OpenJDK developers down the road. >> >> The quick details are that we consistently die without much error detail >> (just a simple segmentation violation printout) when our code enters JNI, >> does some stuff, and then calls back into the VM. The JNI_ENTRY fails >> when >> calling transition_from_native. >> >> The client application is running on an Asus Aspire-One netbook (Atom >> N270, dual core @800MHz) with OpenJDK-1.6.0-20-1.9.7. A gdb stack trace >> and jstack dump is attached for details on what is happening. More >> details >> on the system structure are included below for those interested, but >> basically it is a moderately threaded, intensively JNI application >> running >> under the Equinox OSGi runtime. >> >> It was a little tough to debug, as the clients are remote and I have >> to go >> through multiple ssh back-doors. We initially suspected our JNI >> middleware, but after getting the necessary debugging symbols, tools, and >> builds in place, we found that it was always crashing on the >> write_memory_serialize_page call when attempting JNI_ENTRY after spending >> some time in the native code. It never even got to the point of reference >> values like the VM env, jobject, etc. Anyhow, the source for the >> transition_from_native call led us to try the -X:+UseMembar option which >> seems to have resolved the issue. >> >> Anyhow, I hope the trace info is helpful, and please let me know if I can >> provide more info. I can't spare a ton of cycles, but I would be happy to >> contribute as time permits. >> >> Here are the application details: >> >> As mentioned previously, the application is running in the Equinox OSGi >> framework, and it relies heavily on two JNI libraries: the RXTX library >> (2.1-7r2), and a middleware called opensplice DDS (5.4.1). Opensplice >> is a >> shared memory model runtime that runs as three seperate processes, and >> has >> a JNI interface into the framework. The application has two serial >> devices >> (two RXTX threads), and we have a thread for each (two more threads) that >> does blocking reads on those ports. These threads put data into a >> BlockingQueue, which has another thread that takes data from the queue >> and >> processes it (two more threads). These threads process the data, make JNI >> calls into the DDS middleware (this is where the failures have, at least >> so far, always occurred), and put some information into another Blocking >> Queue. There are two other application threads (total of eight now). The >> first periodically writes to one of the serial port. The other thread >> handles the second blocking Queue and also makes JNI calls into the DDS >> middleware. Overall, there are three threads calling into that middleware >> independantly. >> >> I think there are something like 20 threads total, but three are the JVM >> threads, and 7 or so are related to Equinox and our launcher that don't >> really do anything unless the system is starting or stopping or doing >> something in the OSGi world. >> >> Thanks, and again, I hope this info can be helpfult to others. >> >> Scott Valentine >> >> Concentris Systems LLC >> Manoa Innovation Center, Suite #238 >> 2800 Woodlawn Drive >> Honolulu, HI 96822 >> >> http://www.Concentris-Systems.com >> >> (808) 988-6100 From svalentine at concentris-systems.com Sat Jun 11 14:00:59 2011 From: svalentine at concentris-systems.com (Scott Valentine) Date: Sat, 11 Jun 2011 11:00:59 -1000 Subject: SMP JNI issue, UseMembar workaround resolves it In-Reply-To: <4DF35A87.50903@oracle.com> References: <53e4024f2292fb00f77874be668c86b7.squirrel@www.concentris-systems.com> <4DF31370.4080507@oracle.com> <4DF35A87.50903@oracle.com> Message-ID: I understand... it is actually crashing durring runtime, not in a debug session. I am just looking at the core dump. But yeah, it just prints out "segmentation violation" and that's it. Not HS_err file or whatever, no message from the vm. I will have a look at what the native code is doing in terms of installing signal handlers and let you know what I find out. > Correction ... > > David Holmes said the following on 06/11/11 17:04: >> I'll try and take a deeper look at this but note that if a safepoint is >> pending the thread is supposed to "crash" in >> write_memory_serialize_page. The SEGV so generated should be handled by >> the VM and take the thread to the safepoint. > > The SEGV handler doesn't take the thread to the safepoint it just delays > the thread until the serialization page is unprotected. The subsequent > state transition logic will take the thread to the safepoint if needed. > > They thing is to see exactly what is reported when the real crash > occurs. If we get a simple OS-level abort message then the VM signal > handler did not get invoked which may indicate that native code has > changed the installed signal handlers. > > David > > >> It seems the signal is not >> being handled correctly. UseMembar will workaround this by not using the >> serialization page. >> >> If you observed this SEGV under gdb then it may be a red-herring as gdb >> is stopping the VM from handling the SEGV when it is actually an >> expected signal. >> >> When the real crash occurs what exactly gets reported? >> >> David Holmes >> >> Scott Valentine said the following on 06/11/11 15:58: >>> We ran into an issue where our application would consistently crash >>> with a >>> segmentation violation after roughly 15 minutes to 90 minutes of >>> runtime. >>> It's not exactly a bug, but I thought it would be helpful to post the >>> information here for other folks, and to hopefully support the great >>> work >>> of OpenJDK developers down the road. >>> >>> The quick details are that we consistently die without much error >>> detail >>> (just a simple segmentation violation printout) when our code enters >>> JNI, >>> does some stuff, and then calls back into the VM. The JNI_ENTRY fails >>> when >>> calling transition_from_native. >>> >>> The client application is running on an Asus Aspire-One netbook (Atom >>> N270, dual core @800MHz) with OpenJDK-1.6.0-20-1.9.7. A gdb stack trace >>> and jstack dump is attached for details on what is happening. More >>> details >>> on the system structure are included below for those interested, but >>> basically it is a moderately threaded, intensively JNI application >>> running >>> under the Equinox OSGi runtime. >>> >>> It was a little tough to debug, as the clients are remote and I have >>> to go >>> through multiple ssh back-doors. We initially suspected our JNI >>> middleware, but after getting the necessary debugging symbols, tools, >>> and >>> builds in place, we found that it was always crashing on the >>> write_memory_serialize_page call when attempting JNI_ENTRY after >>> spending >>> some time in the native code. It never even got to the point of >>> reference >>> values like the VM env, jobject, etc. Anyhow, the source for the >>> transition_from_native call led us to try the -X:+UseMembar option >>> which >>> seems to have resolved the issue. >>> >>> Anyhow, I hope the trace info is helpful, and please let me know if I >>> can >>> provide more info. I can't spare a ton of cycles, but I would be happy >>> to >>> contribute as time permits. >>> >>> Here are the application details: >>> >>> As mentioned previously, the application is running in the Equinox OSGi >>> framework, and it relies heavily on two JNI libraries: the RXTX library >>> (2.1-7r2), and a middleware called opensplice DDS (5.4.1). Opensplice >>> is a >>> shared memory model runtime that runs as three seperate processes, and >>> has >>> a JNI interface into the framework. The application has two serial >>> devices >>> (two RXTX threads), and we have a thread for each (two more threads) >>> that >>> does blocking reads on those ports. These threads put data into a >>> BlockingQueue, which has another thread that takes data from the queue >>> and >>> processes it (two more threads). These threads process the data, make >>> JNI >>> calls into the DDS middleware (this is where the failures have, at >>> least >>> so far, always occurred), and put some information into another >>> Blocking >>> Queue. There are two other application threads (total of eight now). >>> The >>> first periodically writes to one of the serial port. The other thread >>> handles the second blocking Queue and also makes JNI calls into the DDS >>> middleware. Overall, there are three threads calling into that >>> middleware >>> independantly. >>> >>> I think there are something like 20 threads total, but three are the >>> JVM >>> threads, and 7 or so are related to Equinox and our launcher that don't >>> really do anything unless the system is starting or stopping or doing >>> something in the OSGi world. >>> >>> Thanks, and again, I hope this info can be helpfult to others. >>> >>> Scott Valentine >>> >>> Concentris Systems LLC >>> Manoa Innovation Center, Suite #238 >>> 2800 Woodlawn Drive >>> Honolulu, HI 96822 >>> >>> http://www.Concentris-Systems.com >>> >>> (808) 988-6100 > Scott Valentine Concentris Systems LLC Manoa Innovation Center, Suite #238 2800 Woodlawn Drive Honolulu, HI 96822 http://www.Concentris-Systems.com (808) 988-6100 From svalentine at concentris-systems.com Sun Jun 12 18:07:07 2011 From: svalentine at concentris-systems.com (Scott Valentine) Date: Sun, 12 Jun 2011 15:07:07 -1000 Subject: SMP JNI issue, UseMembar workaround resolves it In-Reply-To: References: <53e4024f2292fb00f77874be668c86b7.squirrel@www.concentris-systems.com> <4DF31370.4080507@oracle.com> <4DF35A87.50903@oracle.com> Message-ID: > I understand... it is actually crashing durring runtime, not in a debug > session. I am just looking at the core dump. But yeah, it just prints out > "segmentation violation" and that's it. Not HS_err file or whatever, no > message from the vm. > > I will have a look at what the native code is doing in terms of installing > signal handlers and let you know what I find out. > >> Correction ... >> >> David Holmes said the following on 06/11/11 17:04: >>> I'll try and take a deeper look at this but note that if a safepoint is >>> pending the thread is supposed to "crash" in >>> write_memory_serialize_page. The SEGV so generated should be handled by >>> the VM and take the thread to the safepoint. >> >> The SEGV handler doesn't take the thread to the safepoint it just delays >> the thread until the serialization page is unprotected. The subsequent >> state transition logic will take the thread to the safepoint if needed. >> >> They thing is to see exactly what is reported when the real crash >> occurs. If we get a simple OS-level abort message then the VM signal >> handler did not get invoked which may indicate that native code has >> changed the installed signal handlers. >> >> David >> After gathering further background based on the information you provided, I found that the JNI code "attempts" to install signal handlers for cleanup purposes, but punts the operation if it finds that libjsig is not LD_PRELOADed (actually, it logs a warning in the info log - duh - but nothing in the error log, so I missed it). In any case, I tried this approach, which eliminated the warning message, but that runtime crashed after about an hour without the -XX+UseMembar option. Essentially the behavior is the same. I have had two clients running for about 72 hours without issue using the memory barrier, so we are happy to at least have a workaround for now. If you have further suggestions for diagnosing the root cause of the error, we can spend some minor effort looking into the issue further, but as we are running stable at this point, we consider the problem resolved internally. I appreciate the quick response, and again, let me know if there is further useful information I can provide -Scott V. >> >>> It seems the signal is not >>> being handled correctly. UseMembar will workaround this by not using >>> the >>> serialization page. >>> >>> If you observed this SEGV under gdb then it may be a red-herring as gdb >>> is stopping the VM from handling the SEGV when it is actually an >>> expected signal. >>> >>> When the real crash occurs what exactly gets reported? >>> >>> David Holmes >>> >>> Scott Valentine said the following on 06/11/11 15:58: >>>> We ran into an issue where our application would consistently crash >>>> with a >>>> segmentation violation after roughly 15 minutes to 90 minutes of >>>> runtime. >>>> It's not exactly a bug, but I thought it would be helpful to post the >>>> information here for other folks, and to hopefully support the great >>>> work >>>> of OpenJDK developers down the road. >>>> >>>> The quick details are that we consistently die without much error >>>> detail >>>> (just a simple segmentation violation printout) when our code enters >>>> JNI, >>>> does some stuff, and then calls back into the VM. The JNI_ENTRY fails >>>> when >>>> calling transition_from_native. >>>> >>>> The client application is running on an Asus Aspire-One netbook (Atom >>>> N270, dual core @800MHz) with OpenJDK-1.6.0-20-1.9.7. A gdb stack >>>> trace >>>> and jstack dump is attached for details on what is happening. More >>>> details >>>> on the system structure are included below for those interested, but >>>> basically it is a moderately threaded, intensively JNI application >>>> running >>>> under the Equinox OSGi runtime. >>>> >>>> It was a little tough to debug, as the clients are remote and I have >>>> to go >>>> through multiple ssh back-doors. We initially suspected our JNI >>>> middleware, but after getting the necessary debugging symbols, tools, >>>> and >>>> builds in place, we found that it was always crashing on the >>>> write_memory_serialize_page call when attempting JNI_ENTRY after >>>> spending >>>> some time in the native code. It never even got to the point of >>>> reference >>>> values like the VM env, jobject, etc. Anyhow, the source for the >>>> transition_from_native call led us to try the -X:+UseMembar option >>>> which >>>> seems to have resolved the issue. >>>> >>>> Anyhow, I hope the trace info is helpful, and please let me know if I >>>> can >>>> provide more info. I can't spare a ton of cycles, but I would be happy >>>> to >>>> contribute as time permits. >>>> >>>> Here are the application details: >>>> >>>> As mentioned previously, the application is running in the Equinox >>>> OSGi >>>> framework, and it relies heavily on two JNI libraries: the RXTX >>>> library >>>> (2.1-7r2), and a middleware called opensplice DDS (5.4.1). Opensplice >>>> is a >>>> shared memory model runtime that runs as three seperate processes, and >>>> has >>>> a JNI interface into the framework. The application has two serial >>>> devices >>>> (two RXTX threads), and we have a thread for each (two more threads) >>>> that >>>> does blocking reads on those ports. These threads put data into a >>>> BlockingQueue, which has another thread that takes data from the queue >>>> and >>>> processes it (two more threads). These threads process the data, make >>>> JNI >>>> calls into the DDS middleware (this is where the failures have, at >>>> least >>>> so far, always occurred), and put some information into another >>>> Blocking >>>> Queue. There are two other application threads (total of eight now). >>>> The >>>> first periodically writes to one of the serial port. The other thread >>>> handles the second blocking Queue and also makes JNI calls into the >>>> DDS >>>> middleware. Overall, there are three threads calling into that >>>> middleware >>>> independantly. >>>> >>>> I think there are something like 20 threads total, but three are the >>>> JVM >>>> threads, and 7 or so are related to Equinox and our launcher that >>>> don't >>>> really do anything unless the system is starting or stopping or doing >>>> something in the OSGi world. >>>> >>>> Thanks, and again, I hope this info can be helpfult to others. >>>> >>>> Scott Valentine >>>> >>>> Concentris Systems LLC >>>> Manoa Innovation Center, Suite #238 >>>> 2800 Woodlawn Drive >>>> Honolulu, HI 96822 >>>> >>>> http://www.Concentris-Systems.com >>>> >>>> (808) 988-6100 >> > > > Scott Valentine > > Concentris Systems LLC > Manoa Innovation Center, Suite #238 > 2800 Woodlawn Drive > Honolulu, HI 96822 > > http://www.Concentris-Systems.com > > (808) 988-6100 > > > > Scott Valentine Concentris Systems LLC Manoa Innovation Center, Suite #238 2800 Woodlawn Drive Honolulu, HI 96822 http://www.Concentris-Systems.com (808) 988-6100 From David.Holmes at oracle.com Sun Jun 12 19:13:56 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 13 Jun 2011 12:13:56 +1000 Subject: SMP JNI issue, UseMembar workaround resolves it In-Reply-To: References: <53e4024f2292fb00f77874be668c86b7.squirrel@www.concentris-systems.com> <4DF31370.4080507@oracle.com> <4DF35A87.50903@oracle.com> Message-ID: <4DF57264.9050507@oracle.com> Hi Scott, Scott Valentine said the following on 06/13/11 11:07: >> I understand... it is actually crashing durring runtime, not in a debug >> session. I am just looking at the core dump. But yeah, it just prints out >> "segmentation violation" and that's it. Not HS_err file or whatever, no >> message from the vm. >> >> I will have a look at what the native code is doing in terms of installing >> signal handlers and let you know what I find out. >> >>> Correction ... >>> >>> David Holmes said the following on 06/11/11 17:04: >>>> I'll try and take a deeper look at this but note that if a safepoint is >>>> pending the thread is supposed to "crash" in >>>> write_memory_serialize_page. The SEGV so generated should be handled by >>>> the VM and take the thread to the safepoint. >>> The SEGV handler doesn't take the thread to the safepoint it just delays >>> the thread until the serialization page is unprotected. The subsequent >>> state transition logic will take the thread to the safepoint if needed. >>> >>> They thing is to see exactly what is reported when the real crash >>> occurs. If we get a simple OS-level abort message then the VM signal >>> handler did not get invoked which may indicate that native code has >>> changed the installed signal handlers. > > After gathering further background based on the information you provided, > I found that the JNI code "attempts" to install signal handlers for > cleanup purposes, but punts the operation if it finds that libjsig is not > LD_PRELOADed (actually, it logs a warning in the info log - duh - but > nothing in the error log, so I missed it). In any case, I tried this > approach, which eliminated the warning message, but that runtime crashed > after about an hour without the -XX+UseMembar option. Essentially the > behavior is the same. I have had two clients running for about 72 hours > without issue using the memory barrier, so we are happy to at least have a > workaround for now. We'd need to examine that code in detail to see if it is the cause of the problem but it seems most likely that is the case. > If you have further suggestions for diagnosing the root cause of the > error, we can spend some minor effort looking into the issue further, but > as we are running stable at this point, we consider the problem resolved > internally. My concern is that if the signal handler has been supplanted for this situation then it may also have been supplanted for others, in which case safepoints may not work correctly or null reference checking may not work properly. David > I appreciate the quick response, and again, let me know if there is > further useful information I can provide > > -Scott V. > > >>>> It seems the signal is not >>>> being handled correctly. UseMembar will workaround this by not using >>>> the >>>> serialization page. >>>> >>>> If you observed this SEGV under gdb then it may be a red-herring as gdb >>>> is stopping the VM from handling the SEGV when it is actually an >>>> expected signal. >>>> >>>> When the real crash occurs what exactly gets reported? >>>> >>>> David Holmes >>>> >>>> Scott Valentine said the following on 06/11/11 15:58: >>>>> We ran into an issue where our application would consistently crash >>>>> with a >>>>> segmentation violation after roughly 15 minutes to 90 minutes of >>>>> runtime. >>>>> It's not exactly a bug, but I thought it would be helpful to post the >>>>> information here for other folks, and to hopefully support the great >>>>> work >>>>> of OpenJDK developers down the road. >>>>> >>>>> The quick details are that we consistently die without much error >>>>> detail >>>>> (just a simple segmentation violation printout) when our code enters >>>>> JNI, >>>>> does some stuff, and then calls back into the VM. The JNI_ENTRY fails >>>>> when >>>>> calling transition_from_native. >>>>> >>>>> The client application is running on an Asus Aspire-One netbook (Atom >>>>> N270, dual core @800MHz) with OpenJDK-1.6.0-20-1.9.7. A gdb stack >>>>> trace >>>>> and jstack dump is attached for details on what is happening. More >>>>> details >>>>> on the system structure are included below for those interested, but >>>>> basically it is a moderately threaded, intensively JNI application >>>>> running >>>>> under the Equinox OSGi runtime. >>>>> >>>>> It was a little tough to debug, as the clients are remote and I have >>>>> to go >>>>> through multiple ssh back-doors. We initially suspected our JNI >>>>> middleware, but after getting the necessary debugging symbols, tools, >>>>> and >>>>> builds in place, we found that it was always crashing on the >>>>> write_memory_serialize_page call when attempting JNI_ENTRY after >>>>> spending >>>>> some time in the native code. It never even got to the point of >>>>> reference >>>>> values like the VM env, jobject, etc. Anyhow, the source for the >>>>> transition_from_native call led us to try the -X:+UseMembar option >>>>> which >>>>> seems to have resolved the issue. >>>>> >>>>> Anyhow, I hope the trace info is helpful, and please let me know if I >>>>> can >>>>> provide more info. I can't spare a ton of cycles, but I would be happy >>>>> to >>>>> contribute as time permits. >>>>> >>>>> Here are the application details: >>>>> >>>>> As mentioned previously, the application is running in the Equinox >>>>> OSGi >>>>> framework, and it relies heavily on two JNI libraries: the RXTX >>>>> library >>>>> (2.1-7r2), and a middleware called opensplice DDS (5.4.1). Opensplice >>>>> is a >>>>> shared memory model runtime that runs as three seperate processes, and >>>>> has >>>>> a JNI interface into the framework. The application has two serial >>>>> devices >>>>> (two RXTX threads), and we have a thread for each (two more threads) >>>>> that >>>>> does blocking reads on those ports. These threads put data into a >>>>> BlockingQueue, which has another thread that takes data from the queue >>>>> and >>>>> processes it (two more threads). These threads process the data, make >>>>> JNI >>>>> calls into the DDS middleware (this is where the failures have, at >>>>> least >>>>> so far, always occurred), and put some information into another >>>>> Blocking >>>>> Queue. There are two other application threads (total of eight now). >>>>> The >>>>> first periodically writes to one of the serial port. The other thread >>>>> handles the second blocking Queue and also makes JNI calls into the >>>>> DDS >>>>> middleware. Overall, there are three threads calling into that >>>>> middleware >>>>> independantly. >>>>> >>>>> I think there are something like 20 threads total, but three are the >>>>> JVM >>>>> threads, and 7 or so are related to Equinox and our launcher that >>>>> don't >>>>> really do anything unless the system is starting or stopping or doing >>>>> something in the OSGi world. >>>>> >>>>> Thanks, and again, I hope this info can be helpfult to others. >>>>> >>>>> Scott Valentine >>>>> >>>>> Concentris Systems LLC >>>>> Manoa Innovation Center, Suite #238 >>>>> 2800 Woodlawn Drive >>>>> Honolulu, HI 96822 >>>>> >>>>> http://www.Concentris-Systems.com >>>>> >>>>> (808) 988-6100 >> >> Scott Valentine >> >> Concentris Systems LLC >> Manoa Innovation Center, Suite #238 >> 2800 Woodlawn Drive >> Honolulu, HI 96822 >> >> http://www.Concentris-Systems.com >> >> (808) 988-6100 >> >> >> >> > > > Scott Valentine > > Concentris Systems LLC > Manoa Innovation Center, Suite #238 > 2800 Woodlawn Drive > Honolulu, HI 96822 > > http://www.Concentris-Systems.com > > (808) 988-6100 > > > From john.r.rose at oracle.com Tue Jun 14 19:22:29 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 15 Jun 2011 02:22:29 +0000 Subject: hg: jdk7/hotspot/hotspot: 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp Message-ID: <20110615022234.53D2A47031@hg.openjdk.java.net> Changeset: 07c2e7ffd1fc Author: jrose Date: 2011-06-08 17:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/07c2e7ffd1fc 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp Reviewed-by: never, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/code/pcDesc.cpp From tom.rodriguez at oracle.com Wed Jun 15 19:59:40 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 16 Jun 2011 02:59:40 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8 new changesets Message-ID: <20110616025958.1077E47073@hg.openjdk.java.net> Changeset: f918d6096e23 Author: never Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f918d6096e23 7050554: JSR 292 - need optimization for selectAlternative Reviewed-by: kvn, jrose ! src/share/vm/ci/ciCallProfile.hpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciMethodHandle.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp Changeset: cba7b5c2d53f Author: never Date: 2011-06-03 22:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cba7b5c2d53f 7045514: SPARC assembly code for JSR 292 ricochet frames Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp + src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/sparc/vm/registerMap_sparc.hpp ! src/cpu/sparc/vm/runtime_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 642c68c75db9 Author: kvn Date: 2011-06-04 10:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/642c68c75db9 7050280: assert(u->as_Unlock()->is_eliminated()) failed: sanity Summary: Mark all associated (same box and obj) lock and unlock nodes for elimination if some of them marked already. Reviewed-by: iveresov, never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/macro.hpp Changeset: 5cf771a79037 Author: jrose Date: 2011-06-08 17:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5cf771a79037 7047697: MethodHandle.invokeExact call for wrong method causes VM failure if run with -Xcomp Reviewed-by: never, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/code/pcDesc.cpp Changeset: c8f2186acf6d Author: twisti Date: 2011-06-14 12:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c8f2186acf6d 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops Reviewed-by: iveresov, never ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: f8c9417e3571 Author: never Date: 2011-06-14 14:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f8c9417e3571 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters Reviewed-by: twisti, kvn, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp Changeset: e2ce15aa3daf Author: never Date: 2011-06-14 15:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e2ce15aa3daf Merge Changeset: cfcf2ba8f3eb Author: never Date: 2011-06-15 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cfcf2ba8f3eb Merge ! src/share/vm/prims/methodHandleWalk.cpp From erik.trimble at oracle.com Thu Jun 16 23:47:20 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 17 Jun 2011 06:47:20 +0000 Subject: hg: jdk7/hotspot/hotspot: 20 new changesets Message-ID: <20110617064755.BD39F470C0@hg.openjdk.java.net> Changeset: 12537a93a848 Author: asaha Date: 2011-04-08 21:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/12537a93a848 Merge Changeset: 540930dc854d Author: kamg Date: 2011-04-12 16:42 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/540930dc854d 7020373: JSR rewriting can overflow memory address size variables Summary: Abort if incoming classfile's parameters would cause overflows Reviewed-by: coleenp, dcubed, never ! src/share/vm/oops/generateOopMap.cpp + test/runtime/7020373/Test7020373.sh + test/runtime/7020373/testcase.jar Changeset: f0914807c671 Author: asaha Date: 2011-04-20 07:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f0914807c671 Merge Changeset: bad27cd3f646 Author: asaha Date: 2011-04-21 08:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/bad27cd3f646 Merge Changeset: 5e00ed79c8bb Author: asaha Date: 2011-04-21 16:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5e00ed79c8bb Merge Changeset: c97b08c7d72a Author: asaha Date: 2011-04-21 22:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/c97b08c7d72a Merge Changeset: 5def270bc147 Author: zgu Date: 2011-04-15 09:34 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5def270bc147 7016797: Hotspot: securely/restrictive load dlls and new API for loading system dlls Summary: Created Windows Dll wrapped to handle jdk6 and jdk7 platform requirements, also provided more restictive Dll search orders for Windows system Dlls. Reviewed-by: acorn, dcubed, ohair, alanb ! make/windows/makefiles/compile.make ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/jvm_windows.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp Changeset: 089aee76df10 Author: asaha Date: 2011-05-04 16:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/089aee76df10 Merge ! src/os/windows/vm/os_windows.cpp Changeset: ba2db55ddf8b Author: asaha Date: 2011-05-05 22:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ba2db55ddf8b Merge - make/linux/makefiles/cscope.make - make/solaris/makefiles/cscope.make Changeset: 66c17ec20ee2 Author: asaha Date: 2011-05-06 14:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/66c17ec20ee2 Merge Changeset: 7c948af3e651 Author: asaha Date: 2011-05-24 11:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7c948af3e651 Merge ! src/os/windows/vm/os_windows.cpp Changeset: ec7055a259a6 Author: asaha Date: 2011-05-26 17:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/ec7055a259a6 Merge Changeset: 8d5208b557b3 Author: asaha Date: 2011-05-26 21:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/8d5208b557b3 Merge Changeset: 7bf54248da9f Author: asaha Date: 2011-06-06 10:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/7bf54248da9f Merge Changeset: a983caeb2b3e Author: asaha Date: 2011-06-03 07:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a983caeb2b3e Merge Changeset: 0e9653efc6ea Author: asaha Date: 2011-06-06 10:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/0e9653efc6ea Merge Changeset: a884a8b0ec6d Author: asaha Date: 2011-06-15 14:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a884a8b0ec6d 7055247: Ignore test of # 7020373 Reviewed-by: dcubed ! test/runtime/7020373/Test7020373.sh Changeset: 9d7c66d9a203 Author: lana Date: 2011-06-15 16:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9d7c66d9a203 Merge Changeset: 15e7628f9e92 Author: trims Date: 2011-06-16 19:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/15e7628f9e92 Merge Changeset: fc043ce2136c Author: trims Date: 2011-06-16 19:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/fc043ce2136c 7055788: Bump the HS21 build number to 16 Summary: Update the HS21 build number to 16 Reviewed-by: jcoomes ! make/hotspot_version From tom.rodriguez at oracle.com Fri Jun 17 14:00:21 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 17 Jun 2011 21:00:21 +0000 Subject: hg: jdk7/hotspot/jdk: 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray Message-ID: <20110617210059.C275A470DE@hg.openjdk.java.net> Changeset: cf0632d2db2c Author: jrose Date: 2011-06-14 22:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cf0632d2db2c 7052202: JSR 292: Crash in sun.invoke.util.ValueConversions.fillArray Summary: Fix corner cases involving MethodHandles.permuteArguments with long or double argument lists. Reviewed-by: twisti, never ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/SwitchPoint.java + test/java/lang/invoke/PermuteArgsTest.java From tom.rodriguez at oracle.com Fri Jun 17 15:41:30 2011 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 17 Jun 2011 22:41:30 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20110617224137.48F11470E4@hg.openjdk.java.net> Changeset: a9b8b43b115f Author: never Date: 2011-06-14 14:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a9b8b43b115f 7052219: JSR 292: Crash in ~BufferBlob::MethodHandles adapters Reviewed-by: twisti, kvn, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubCodeGenerator.hpp Changeset: 3275a6560cf7 Author: twisti Date: 2011-06-14 12:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3275a6560cf7 7053520: JSR292: crash in invokedynamic with C1 using tiered and compressed oops Reviewed-by: iveresov, never ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 38fa55e5e792 Author: never Date: 2011-06-16 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/38fa55e5e792 7055355: JSR 292: crash while throwing WrongMethodTypeException Reviewed-by: jrose, twisti, bdelsart ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp From erik.trimble at oracle.com Tue Jun 21 02:46:18 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 21 Jun 2011 09:46:18 +0000 Subject: hg: jdk7/hotspot: Added tag jdk7-b146 for changeset 2d38c2a79c14 Message-ID: <20110621094619.5121F471BD@hg.openjdk.java.net> Changeset: 3e0b96f8f6a0 Author: schien Date: 2011-06-20 16:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/3e0b96f8f6a0 Added tag jdk7-b146 for changeset 2d38c2a79c14 ! .hgtags From erik.trimble at oracle.com Tue Jun 21 02:46:30 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 21 Jun 2011 09:46:30 +0000 Subject: hg: jdk7/hotspot/corba: Added tag jdk7-b146 for changeset 770227a4087e Message-ID: <20110621094641.01148471BE@hg.openjdk.java.net> Changeset: 36f0efbc66ef Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/36f0efbc66ef Added tag jdk7-b146 for changeset 770227a4087e ! .hgtags From erik.trimble at oracle.com Tue Jun 21 02:47:25 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 21 Jun 2011 09:47:25 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20110621094738.AF37D471BF@hg.openjdk.java.net> Changeset: 72701f797a7c Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/72701f797a7c Added tag jdk7-b146 for changeset 38fa55e5e792 ! .hgtags Changeset: 49d1ee0f1f0c Author: trims Date: 2011-06-21 02:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/49d1ee0f1f0c Added tag hs21-b16 for changeset 38fa55e5e792 ! .hgtags From erik.trimble at oracle.com Tue Jun 21 02:48:36 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 21 Jun 2011 09:48:36 +0000 Subject: hg: jdk7/hotspot/jaxp: Added tag jdk7-b146 for changeset bcd31fa1e3c6 Message-ID: <20110621094836.AA96E471C0@hg.openjdk.java.net> Changeset: 9a4d09f33f01 Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/9a4d09f33f01 Added tag jdk7-b146 for changeset bcd31fa1e3c6 ! .hgtags From erik.trimble at oracle.com Tue Jun 21 02:48:49 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 21 Jun 2011 09:48:49 +0000 Subject: hg: jdk7/hotspot/jaxws: 11 new changesets Message-ID: <20110621094850.0914B471C1@hg.openjdk.java.net> Changeset: 581dab3f0773 Author: asaha Date: 2011-04-21 16:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/581dab3f0773 Merge Changeset: 26610bb80151 Author: asaha Date: 2011-05-04 12:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/26610bb80151 Merge Changeset: c6ff860428c7 Author: asaha Date: 2011-05-05 22:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/c6ff860428c7 Merge Changeset: f4e1caef46d0 Author: asaha Date: 2011-05-24 11:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/f4e1caef46d0 Merge Changeset: 9896cee00786 Author: asaha Date: 2011-05-26 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/9896cee00786 Merge Changeset: d1febdcb0351 Author: asaha Date: 2011-05-26 21:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/d1febdcb0351 Merge Changeset: 239c80c331da Author: asaha Date: 2011-06-06 10:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/239c80c331da Merge Changeset: 09412171ca4b Author: asaha Date: 2011-06-03 07:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/09412171ca4b Merge Changeset: 9d8fd0982fb8 Author: asaha Date: 2011-06-06 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/9d8fd0982fb8 Merge Changeset: 05469dd4c366 Author: lana Date: 2011-06-15 16:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/05469dd4c366 Merge Changeset: faa394edbfe3 Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/faa394edbfe3 Added tag jdk7-b146 for changeset 05469dd4c366 ! .hgtags From erik.trimble at oracle.com Tue Jun 21 02:52:30 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 21 Jun 2011 09:52:30 +0000 Subject: hg: jdk7/hotspot/jdk: 43 new changesets Message-ID: <20110621100158.414A1471C2@hg.openjdk.java.net> Changeset: ae731399e525 Author: dav Date: 2011-06-07 22:58 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ae731399e525 7048568: Crash in Java_sun_awt_Win32GraphicsEnvironment_isVistaOS Reviewed-by: dcherepanov, art, amenkov ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp Changeset: f08fcae94813 Author: lana Date: 2011-06-10 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f08fcae94813 Merge Changeset: 6e961c328276 Author: michaelm Date: 2011-06-08 10:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6e961c328276 7050028: ISE "zip file closed" from JarURLConnection.getInputStream on JDK 7 when !useCaches Reviewed-by: chegar, alanb ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/B7050028.java Changeset: b6ced5ad7a62 Author: dwanvik Date: 2011-06-10 17:44 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b6ced5ad7a62 7046557: Changes to the Java DB README files in JDK7 Summary: Update /README.html with correct mention of Java DB, add JDK specific README files to /db and /demo/db. Reviewed-by: ohair ! make/common/Release.gmk Changeset: 646ab254ff80 Author: lana Date: 2011-06-10 11:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/646ab254ff80 Merge Changeset: aca0dc2b921c Author: weijun Date: 2011-02-09 11:50 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/aca0dc2b921c 6618658: Deserialization allows creation of mutable SignedObject Reviewed-by: hawtin, mullan ! src/share/classes/java/security/SignedObject.java + test/java/security/SignedObject/Correctness.java Changeset: df445f522425 Author: bae Date: 2011-02-17 12:21 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/df445f522425 7013519: [parfait] Integer overflows in 2D code Reviewed-by: prr, valeriep ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/font/layout/SunLayoutEngine.cpp Changeset: ccb2fcfb6d6b Author: chegar Date: 2011-02-18 13:31 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/ccb2fcfb6d6b 7013969: NetworkInterface.toString can reveal bindings Reviewed-by: alanb, michaelm, hawtin ! src/share/classes/java/net/NetworkInterface.java Changeset: 026adaac71f1 Author: dcherepanov Date: 2011-02-25 15:54 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/026adaac71f1 7012520: Heap overflow vulnerability in FileDialog.show() Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_FileDialog.cpp Changeset: d489f00d6c65 Author: flar Date: 2011-03-02 05:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/d489f00d6c65 7016495: Crash in Java 2D transforming an image with scale close to zero Reviewed-by: prr, bae ! src/share/classes/sun/java2d/pipe/DrawImage.java ! src/share/native/sun/java2d/loops/TransformHelper.c + test/java/awt/image/BufferedImage/TinyScale.java Changeset: fe27fe44ac51 Author: ksrini Date: 2011-03-03 14:16 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/fe27fe44ac51 7016985: (launcher) implement safe secure dll loading Reviewed-by: mchung ! src/windows/bin/java_md.c Changeset: 0efa64f13302 Author: chegar Date: 2011-04-05 14:49 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0efa64f13302 7033865: JDK: Add private API for secure/restrictive loading of system dlls Reviewed-by: alanb ! src/share/native/common/jdk_util.h + src/solaris/native/common/jdk_util_md.h ! src/windows/native/common/jdk_util_md.c + src/windows/native/common/jdk_util_md.h Changeset: 67992a58bfba Author: ksrini Date: 2011-04-05 16:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/67992a58bfba 7032593: DLL_LOADING: Upgrade solution to 7016985 to reflect JDK7 solution Reviewed-by: mchung, asaha ! src/windows/bin/java_md.c Changeset: 7181441faf72 Author: dcherepanov Date: 2011-04-08 16:44 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7181441faf72 7003962: AWT: securely load DLLs and launch executables using fully qualified path Reviewed-by: art, bae, alanb ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h ! src/windows/native/sun/windows/DllUtil.cpp ! src/windows/native/sun/windows/DllUtil.h ! src/windows/native/sun/windows/ShellFolder2.cpp ! src/windows/native/sun/windows/ThemeReader.cpp ! src/windows/native/sun/windows/awt_Mlib.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/stdhdrs.h Changeset: 05a3923f516f Author: dcherepanov Date: 2011-04-08 17:58 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/05a3923f516f 7035077: Minor addition to the changes for 7003962 Reviewed-by: chegar ! src/windows/native/sun/windows/DllUtil.cpp Changeset: afcc1530e68b Author: asaha Date: 2011-04-08 10:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/afcc1530e68b Merge - make/java/dyn/Makefile - src/share/classes/java/dyn/CallSite.java - src/share/classes/java/dyn/ClassValue.java - src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java - src/share/classes/java/dyn/InvokeDynamicBootstrapError.java - src/share/classes/java/dyn/Linkage.java - src/share/classes/java/dyn/MethodHandle.java - src/share/classes/java/dyn/MethodHandles.java - src/share/classes/java/dyn/MethodType.java - src/share/classes/java/dyn/MethodTypeForm.java - src/share/classes/java/dyn/MutableCallSite.java - src/share/classes/java/dyn/SwitchPoint.java - src/share/classes/java/dyn/VolatileCallSite.java - src/share/classes/java/dyn/WrongMethodTypeException.java - src/share/classes/java/dyn/package-info.java - src/share/classes/sun/dyn/Access.java - src/share/classes/sun/dyn/AdapterMethodHandle.java - src/share/classes/sun/dyn/BoundMethodHandle.java - src/share/classes/sun/dyn/CallSiteImpl.java - src/share/classes/sun/dyn/DirectMethodHandle.java - src/share/classes/sun/dyn/FilterGeneric.java - src/share/classes/sun/dyn/FilterOneArgument.java - src/share/classes/sun/dyn/FromGeneric.java - src/share/classes/sun/dyn/InvokeGeneric.java - src/share/classes/sun/dyn/Invokers.java - src/share/classes/sun/dyn/MemberName.java - src/share/classes/sun/dyn/MethodHandleImpl.java - src/share/classes/sun/dyn/MethodHandleNatives.java - src/share/classes/sun/dyn/MethodTypeImpl.java - src/share/classes/sun/dyn/SpreadGeneric.java - src/share/classes/sun/dyn/ToGeneric.java - src/share/classes/sun/dyn/WrapperInstance.java - src/share/classes/sun/dyn/anon/AnonymousClassLoader.java - src/share/classes/sun/dyn/anon/ConstantPoolParser.java - src/share/classes/sun/dyn/anon/ConstantPoolPatch.java - src/share/classes/sun/dyn/anon/ConstantPoolVisitor.java - src/share/classes/sun/dyn/anon/InvalidConstantPoolFormatException.java - src/share/classes/sun/dyn/empty/Empty.java - src/share/classes/sun/dyn/package-info.java - src/share/classes/sun/dyn/util/BytecodeDescriptor.java - src/share/classes/sun/dyn/util/BytecodeName.java - src/share/classes/sun/dyn/util/ValueConversions.java - src/share/classes/sun/dyn/util/VerifyAccess.java - src/share/classes/sun/dyn/util/VerifyType.java - src/share/classes/sun/dyn/util/Wrapper.java - src/share/classes/sun/dyn/util/package-info.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c - test/java/dyn/ClassValueTest.java - test/java/dyn/InvokeDynamicPrintArgs.java - test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamplesTest.java - test/java/dyn/MethodHandlesTest.java - test/java/dyn/MethodTypeTest.java - test/java/dyn/indify/Indify.java Changeset: 557bd9b5d92f Author: asaha Date: 2011-04-08 10:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/557bd9b5d92f Merge Changeset: e142148d8b54 Author: asaha Date: 2011-04-12 14:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e142148d8b54 Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java Changeset: 76e0e562b617 Author: dcherepanov Date: 2011-04-15 17:06 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/76e0e562b617 7036952: build warning after the changes for 7003962 Reviewed-by: art, bae ! src/windows/native/sun/java2d/opengl/OGLFuncs_md.h Changeset: f8eddc85cc02 Author: zgu Date: 2011-04-15 09:53 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f8eddc85cc02 7003964: SERV: securely load DLLs and launch executables using fully qualified path Summary: Linked in Windows libraries that are available on jdk7 supported platforms, and used GetModuleHandle instead of LoadLibrary for already loaded Dlls. Reviewed-by: dcubed, alanb ! make/com/sun/tools/attach/Makefile ! src/windows/classes/sun/tools/attach/WindowsAttachProvider.java ! src/windows/native/sun/tools/attach/WindowsAttachProvider.c ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c ! src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c ! src/windows/npt/npt_md.h Changeset: 0865aa0ad9b2 Author: zgu Date: 2011-04-19 10:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/0865aa0ad9b2 Merge Changeset: 6f8a4d334fb2 Author: asaha Date: 2011-04-20 09:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6f8a4d334fb2 Merge ! make/com/sun/tools/attach/Makefile ! src/share/classes/java/net/NetworkInterface.java ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/windows/bin/java_md.c ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: f3645b5d6e62 Author: asaha Date: 2011-04-20 21:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f3645b5d6e62 Merge Changeset: b626f78c57e1 Author: asaha Date: 2011-04-21 08:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b626f78c57e1 Merge Changeset: cec45f3353be Author: asaha Date: 2011-04-21 08:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cec45f3353be Merge Changeset: 6133c9ee3a01 Author: asaha Date: 2011-04-21 08:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/6133c9ee3a01 Merge Changeset: dd06e8d3da91 Author: asaha Date: 2011-04-21 15:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dd06e8d3da91 Merge Changeset: b2295905901a Author: asaha Date: 2011-04-21 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/b2295905901a Merge - src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java Changeset: 3fedf261fb4f Author: valeriep Date: 2011-04-26 15:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/3fedf261fb4f 7003952: SEC: securely load DLLs and launch executables using fully qualified path Summary: Enforce full path when specifying library locations. Reviewed-by: wetmore, ohair ! make/sun/security/pkcs11/Makefile ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/native/sun/security/pkcs11/j2secmod.c + test/sun/security/pkcs11/Provider/Absolute.cfg + test/sun/security/pkcs11/Provider/Absolute.java Changeset: 94ea3b8288f1 Author: alexp Date: 2011-05-04 11:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/94ea3b8288f1 7020198: ImageIcon creates Component with null acc Reviewed-by: rupashka, hawtin ! src/share/classes/javax/swing/ImageIcon.java Changeset: e6fdfb249e31 Author: asaha Date: 2011-05-04 16:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/e6fdfb249e31 Merge - src/share/native/sun/font/layout/Features.h ! src/windows/native/sun/windows/awt_FileDialog.cpp - test/javax/swing/text/GlyphView/6539700/bug6539700.java Changeset: 49244980d692 Author: asaha Date: 2011-05-05 22:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/49244980d692 Merge - src/share/classes/sun/security/util/SignatureFileManifest.java Changeset: 647b031200f0 Author: asaha Date: 2011-05-06 14:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/647b031200f0 Merge Changeset: 92b5197e9ff5 Author: asaha Date: 2011-05-26 21:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/92b5197e9ff5 Merge ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/windows/awt_TrayIcon.cpp Changeset: cca9ea306c6e Author: asaha Date: 2011-05-26 21:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cca9ea306c6e Merge Changeset: dab3e66ebda7 Author: lana Date: 2011-06-06 19:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/dab3e66ebda7 Merge Changeset: 9f17be5136d1 Author: wetmore Date: 2011-06-09 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9f17be5136d1 7052537: java/security/Security/NotInstalledProviders.java is causing -samevm tests to fail. Reviewed-by: valeriep, asaha, alanb ! test/java/security/Security/NoInstalledProviders.java Changeset: 4961be00d3b5 Author: lana Date: 2011-06-15 16:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/4961be00d3b5 Merge Changeset: a65fa0f6717e Author: trims Date: 2011-06-17 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/a65fa0f6717e Merge Changeset: c46f97579fe6 Author: alanb Date: 2011-06-17 16:47 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c46f97579fe6 7055508: (aio) EXCEPTION_ACCESS_VIOLATION in AsynchronousSocketChannel.connect on Windows 7 Reviewed-by: chegar ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c Changeset: c102e1221afa Author: lana Date: 2011-06-17 10:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/c102e1221afa Merge Changeset: 539e576793a8 Author: lana Date: 2011-06-18 10:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/539e576793a8 Merge Changeset: 7b4f4230fecf Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/7b4f4230fecf Added tag jdk7-b146 for changeset 539e576793a8 ! .hgtags From erik.trimble at oracle.com Tue Jun 21 03:05:35 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 21 Jun 2011 10:05:35 +0000 Subject: hg: jdk7/hotspot/langtools: 16 new changesets Message-ID: <20110621100618.A0127471C4@hg.openjdk.java.net> Changeset: 347349c981f2 Author: jjh Date: 2011-06-09 09:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/347349c981f2 7052782: Two langtools regression tests fail due to fix for 7034977 which removed the invokeGeneric method Summary: Change the tests to call invoke instead of invokeGeneric Reviewed-by: jrose, mcimadamore ! test/tools/javac/meth/InvokeMH.java ! test/tools/javac/meth/XlintWarn.java Changeset: b8a2c9c87018 Author: lana Date: 2011-06-10 11:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/b8a2c9c87018 Merge Changeset: 588d366d96df Author: asaha Date: 2011-04-21 16:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/588d366d96df Merge Changeset: 219b522d09e4 Author: asaha Date: 2011-05-04 12:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/219b522d09e4 Merge Changeset: 145d832616d3 Author: asaha Date: 2011-05-05 22:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/145d832616d3 Merge Changeset: 8b6e015ae7d0 Author: asaha Date: 2011-05-24 11:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8b6e015ae7d0 Merge - test/tools/javac/generics/diamond/7030150/Neg01.java - test/tools/javac/generics/diamond/7030150/Neg01.out - test/tools/javac/generics/diamond/7030150/Neg02.java - test/tools/javac/generics/diamond/7030150/Neg02.out - test/tools/javac/generics/diamond/7030150/Neg03.java - test/tools/javac/generics/diamond/7030150/Neg03.out - test/tools/javac/generics/diamond/7030150/Pos01.java - test/tools/javac/generics/diamond/7030150/Pos02.java Changeset: 35cc19ae29b5 Author: asaha Date: 2011-05-26 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/35cc19ae29b5 Merge Changeset: 8b65930602c3 Author: asaha Date: 2011-05-26 21:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8b65930602c3 Merge Changeset: 0adb806caf9d Author: asaha Date: 2011-06-06 10:22 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/0adb806caf9d Merge Changeset: bb1fdcebde01 Author: asaha Date: 2011-06-03 07:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/bb1fdcebde01 Merge Changeset: 8ed03b0e3c9c Author: asaha Date: 2011-06-06 11:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/8ed03b0e3c9c Merge Changeset: f494ca4bca0d Author: lana Date: 2011-06-15 16:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/f494ca4bca0d Merge Changeset: 7eba9df190ae Author: bpatel Date: 2011-06-17 20:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/7eba9df190ae 7052425: Change the look and feel of the javadoc generate HTML pages using stylesheet Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/background.gif - src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/inherit.gif ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/tab.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/titlebar_end.gif ! test/com/sun/javadoc/AccessH1/AccessH1.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java Changeset: c3a3440fe6e8 Author: bpatel Date: 2011-06-17 20:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/c3a3440fe6e8 Merge Changeset: 9425dd4f53d5 Author: schien Date: 2011-06-18 09:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/9425dd4f53d5 Merge Changeset: 436fb6aeda5a Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/436fb6aeda5a Added tag jdk7-b146 for changeset 9425dd4f53d5 ! .hgtags From vladimir.kozlov at oracle.com Wed Jun 22 10:38:36 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jun 2011 10:38:36 -0700 Subject: Bug in FieldsAllocationStyle=2 logic In-Reply-To: References: Message-ID: <4E02289C.3060106@oracle.com> Thank you for such detail analysis and suggested fix. I filed bug and I will fix it in 7u2. 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM Thanks, Vladimir PS: if possible, please, report problems to hotspot-dev at openjdk.java.net alias so all Hotspot developers can see it. I did original changes but I am in Compiler (JIT) group. Krystal Mok wrote: > Hi all, > > I think I've found a bug in ClassFileParser::parseClassFile() that deals > with FieldsAllocationStyle=2, which was introduced about a year > ago: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/b9d85fcdf743 > > int map_size = super_klass->nonstatic_oop_map_size(); > OopMapBlock* first_map = super_klass->start_of_nonstatic_oop_maps(); > OopMapBlock* last_map = first_map + map_size - 1; > > This code accidentally works on LP64 systems because it takes 1 word per > OopMapBlock, so nonstatic_oop_map_size() and nonstatic_oop_map_count() > would actually return the same value. > > But on 32-bit systems, an OopMapBlock takes 2 words, which > makes nonstatic_oop_map_size() == nonstatic_oop_map_count() * 2, and > breaks the code above. > > The code should really be: > > int map_count = super_klass->nonstatic_oop_map_count(); > OopMapBlock* first_map = super_klass->start_of_nonstatic_oop_maps(); > OopMapBlock* last_map = first_map + map_count - 1; > > I found this because FieldsAllocationStyle=2 doesn't work for me on > 32-bit Windows (JDK6u25 and 6u26), but works on 64-bit Ubuntu JDK6u25. > Here's a min repro of my test: https://gist.github.com/1037866 > > Could anybody please verify this? > Just checked the current tip of hsx/hotspot-rt, and it still has this > behavior: > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/file/1744e37e032b/src/share/vm/classfile/classFileParser.cpp > line 3290 > > Regards, > Kris Mok From dmdabbs at gmail.com Wed Jun 22 11:29:30 2011 From: dmdabbs at gmail.com (David Dabbs) Date: Wed, 22 Jun 2011 13:29:30 -0500 Subject: Bug in FieldsAllocationStyle=2 logic In-Reply-To: <4E02289C.3060106@oracle.com> References: <4E02289C.3060106@oracle.com> Message-ID: <021501cc310a$55546510$fffd2f30$@com> > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev- > bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Wednesday, June 22, 2011 12:39 PM > To: Krystal Mok > Cc: hotspot-dev > Subject: Re: Bug in FieldsAllocationStyle=2 logic > > Thank you for such detail analysis and suggested fix. > I filed bug and I will fix it in 7u2. > > 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM > > Thanks, > Vladimir > > PS: if possible, please, report problems to hotspot- > dev at openjdk.java.net alias > so all Hotspot developers can see it. I did original changes but I am > in > Compiler (JIT) group. > > Krystal Mok wrote: > > Hi all, > > > > I think I've found a bug in ClassFileParser::parseClassFile() that > deals > > with FieldsAllocationStyle=2, which was introduced about a year > > ago: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/b9d85fcdf743 > > > > int map_size = super_klass->nonstatic_oop_map_size(); > > OopMapBlock* first_map = super_klass->start_of_nonstatic_oop_maps(); > > OopMapBlock* last_map = first_map + map_size - 1; > > > > This code accidentally works on LP64 systems because it takes 1 word > per > > OopMapBlock, so nonstatic_oop_map_size() and > nonstatic_oop_map_count() > > would actually return the same value. > > > > But on 32-bit systems, an OopMapBlock takes 2 words, which > > makes nonstatic_oop_map_size() == nonstatic_oop_map_count() * 2, and > > breaks the code above. > > > > The code should really be: > > > > int map_count = super_klass->nonstatic_oop_map_count(); > > OopMapBlock* first_map = super_klass->start_of_nonstatic_oop_maps(); > > OopMapBlock* last_map = first_map + map_count - 1; > > > > I found this because FieldsAllocationStyle=2 doesn't work for me on > > 32-bit Windows (JDK6u25 and 6u26), but works on 64-bit Ubuntu > JDK6u25. > > Here's a min repro of my test: https://gist.github.com/1037866 > > > > Could anybody please verify this? > > Just checked the current tip of hsx/hotspot-rt, and it still has this > > behavior: > > http://hg.openjdk.java.net/hsx/hotspot- > rt/hotspot/file/1744e37e032b/src/share/vm/classfile/classFileParser.cpp > > line 3290 > > > > Regards, > > Kris Mok What would be the use case/work load for choosing this option? Thanks, David From rednaxelafx at gmail.com Wed Jun 22 12:05:57 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 23 Jun 2011 03:05:57 +0800 Subject: Bug in FieldsAllocationStyle=2 logic In-Reply-To: <4E02289C.3060106@oracle.com> References: <4E02289C.3060106@oracle.com> Message-ID: Thank you very much for the quick response ^_^ PS: if possible, please, report problems to hotspot-dev at openjdk.java.net alias > so all Hotspot developers can see it. I did original changes but I am in > Compiler (JIT) group. Got it. I thought this issue belonged to the runtime group, that's why I sent it there the first place. Regards, Kris Mok On Thu, Jun 23, 2011 at 1:38 AM, Vladimir Kozlov wrote: > Thank you for such detail analysis and suggested fix. > I filed bug and I will fix it in 7u2. > > 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM > > Thanks, > Vladimir > > PS: if possible, please, report problems to hotspot-dev at openjdk.java.netalias so all Hotspot developers can see it. I did original changes but I am > in Compiler (JIT) group. > > > Krystal Mok wrote: > >> Hi all, >> >> I think I've found a bug in ClassFileParser::**parseClassFile() that >> deals with FieldsAllocationStyle=2, which was introduced about a year ago: >> http://hg.openjdk.java.net/**jdk6/jdk6/hotspot/rev/**b9d85fcdf743 >> >> int map_size = super_klass->nonstatic_oop_**map_size(); >> OopMapBlock* first_map = super_klass->start_of_**nonstatic_oop_maps(); >> OopMapBlock* last_map = first_map + map_size - 1; >> >> This code accidentally works on LP64 systems because it takes 1 word per >> OopMapBlock, so nonstatic_oop_map_size() and nonstatic_oop_map_count() would >> actually return the same value. >> >> But on 32-bit systems, an OopMapBlock takes 2 words, which makes >> nonstatic_oop_map_size() == nonstatic_oop_map_count() * 2, and breaks the >> code above. >> >> The code should really be: >> >> int map_count = super_klass->nonstatic_oop_**map_count(); >> OopMapBlock* first_map = super_klass->start_of_**nonstatic_oop_maps(); >> OopMapBlock* last_map = first_map + map_count - 1; >> >> I found this because FieldsAllocationStyle=2 doesn't work for me on 32-bit >> Windows (JDK6u25 and 6u26), but works on 64-bit Ubuntu JDK6u25. Here's a min >> repro of my test: https://gist.github.com/**1037866 >> >> Could anybody please verify this? >> Just checked the current tip of hsx/hotspot-rt, and it still has this >> behavior: >> http://hg.openjdk.java.net/**hsx/hotspot-rt/hotspot/file/** >> 1744e37e032b/src/share/vm/**classfile/classFileParser.cpp >> line 3290 >> >> Regards, >> Kris Mok >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110623/35d61d39/attachment.html From rednaxelafx at gmail.com Wed Jun 22 12:07:47 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 23 Jun 2011 03:07:47 +0800 Subject: Bug in FieldsAllocationStyle=2 logic In-Reply-To: <021501cc310a$55546510$fffd2f30$@com> References: <4E02289C.3060106@oracle.com> <021501cc310a$55546510$fffd2f30$@com> Message-ID: Hi David, I'll let Vladimir, the original author, give the definitive answer. :-) Anyway, here's my guess: Packing oop fields together makes iterating oops in an object faster. For example, the marking phase of GC would benefit from this. Supposed we had a few classes as follows: class Base { Object o1; int i; } class Derived extends Base { Object o2; float f; } An instance of Derived would contain a Base subobject within itself. It's straightforward to keep the Base's field layout in the subobject in an Derived instance; in other words, Base::o1 and Base::i would be at the same offset in a Base instance and in a Derived instance. So, to pack oops in Base and Derived together while keeping Base's layout intact in Derived, a reasonable solution is to alternate between FieldsAllocationStyle=1 and FieldsAllocationStyle=0 in an inheritance chain. That's exactly what FieldsAllocationStyle is doing. But if we push hard to pack all oop fields in an object together, we'd probably end up using a bidirectional object layout, like the one used in SableVM (http://www.sablevm.org/features.html). It'd be really fun to see this implemented in HotSpot VM sometime in the future. This paper is worth reading if you're interested in object layouts: A Comprehensive Evaluation of Object Scanning Techniques, http://users.cecs.anu.edu.au/~steveb/downloads/pdf/scan-ismm-2011.pdf Regards, Kris Mok On Thu, Jun 23, 2011 at 2:29 AM, David Dabbs wrote: > > > > -----Original Message----- > > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev- > > bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > > Sent: Wednesday, June 22, 2011 12:39 PM > > To: Krystal Mok > > Cc: hotspot-dev > > Subject: Re: Bug in FieldsAllocationStyle=2 logic > > > > Thank you for such detail analysis and suggested fix. > > I filed bug and I will fix it in 7u2. > > > > 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM > > > > Thanks, > > Vladimir > > > > PS: if possible, please, report problems to hotspot- > > dev at openjdk.java.net alias > > so all Hotspot developers can see it. I did original changes but I am > > in > > Compiler (JIT) group. > > > > Krystal Mok wrote: > > > Hi all, > > > > > > I think I've found a bug in ClassFileParser::parseClassFile() that > > deals > > > with FieldsAllocationStyle=2, which was introduced about a year > > > ago: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/b9d85fcdf743 > > > > > > int map_size = super_klass->nonstatic_oop_map_size(); > > > OopMapBlock* first_map = super_klass->start_of_nonstatic_oop_maps(); > > > OopMapBlock* last_map = first_map + map_size - 1; > > > > > > This code accidentally works on LP64 systems because it takes 1 word > > per > > > OopMapBlock, so nonstatic_oop_map_size() and > > nonstatic_oop_map_count() > > > would actually return the same value. > > > > > > But on 32-bit systems, an OopMapBlock takes 2 words, which > > > makes nonstatic_oop_map_size() == nonstatic_oop_map_count() * 2, and > > > breaks the code above. > > > > > > The code should really be: > > > > > > int map_count = super_klass->nonstatic_oop_map_count(); > > > OopMapBlock* first_map = super_klass->start_of_nonstatic_oop_maps(); > > > OopMapBlock* last_map = first_map + map_count - 1; > > > > > > I found this because FieldsAllocationStyle=2 doesn't work for me on > > > 32-bit Windows (JDK6u25 and 6u26), but works on 64-bit Ubuntu > > JDK6u25. > > > Here's a min repro of my test: https://gist.github.com/1037866 > > > > > > Could anybody please verify this? > > > Just checked the current tip of hsx/hotspot-rt, and it still has this > > > behavior: > > > http://hg.openjdk.java.net/hsx/hotspot- > > rt/hotspot/file/1744e37e032b/src/share/vm/classfile/classFileParser.cpp > > > line 3290 > > > > > > Regards, > > > Kris Mok > > > What would be the use case/work load for choosing this option? > > > Thanks, > > David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110623/267708f3/attachment.html From vladimir.kozlov at oracle.com Wed Jun 22 13:56:25 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Jun 2011 13:56:25 -0700 Subject: Bug in FieldsAllocationStyle=2 logic In-Reply-To: References: <4E02289C.3060106@oracle.com> <021501cc310a$55546510$fffd2f30$@com> Message-ID: <4E0256F9.1000204@oracle.com> I have nothing to add to Kris's nice explanation. I just want to say that you should check if it really can help your application. It may help GC but it may also harm execution performance since different layout of fields may increase data cache misses. Vladimir Krystal Mok wrote: > Hi David, > > I'll let Vladimir, the original author, give the definitive answer. :-) > > Anyway, here's my guess: > Packing oop fields together makes iterating oops in an object faster. > For example, the marking phase of GC would benefit from this. > > Supposed we had a few classes as follows: > > class Base { > Object o1; > int i; > } > > class Derived extends Base { > Object o2; > float f; > } > > An instance of Derived would contain a Base subobject within itself. > It's straightforward to keep the Base's field layout in the subobject in > an Derived instance; in other words, Base::o1 and Base::i would be at > the same offset in a Base instance and in a Derived instance. > > So, to pack oops in Base and Derived together while keeping Base's > layout intact in Derived, a reasonable solution is to alternate between > FieldsAllocationStyle=1 and FieldsAllocationStyle=0 in an inheritance > chain. That's exactly what FieldsAllocationStyle is doing. > > But if we push hard to pack all oop fields in an object together, we'd > probably end up using a bidirectional object layout, like the one used > in SableVM (http://www.sablevm.org/features.html). It'd be really fun to > see this implemented in HotSpot VM sometime in the future. > > This paper is worth reading if you're interested in object layouts: > A Comprehensive Evaluation of Object Scanning > Techniques, http://users.cecs.anu.edu.au/~steveb/downloads/pdf/scan-ismm-2011.pdf > > Regards, > Kris Mok > > On Thu, Jun 23, 2011 at 2:29 AM, David Dabbs > wrote: > > > > > -----Original Message----- > > From: hotspot-dev-bounces at openjdk.java.net > [mailto:hotspot-dev- > > > bounces at openjdk.java.net ] On > Behalf Of Vladimir Kozlov > > Sent: Wednesday, June 22, 2011 12:39 PM > > To: Krystal Mok > > Cc: hotspot-dev > > Subject: Re: Bug in FieldsAllocationStyle=2 logic > > > > Thank you for such detail analysis and suggested fix. > > I filed bug and I will fix it in 7u2. > > > > 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM > > > > Thanks, > > Vladimir > > > > PS: if possible, please, report problems to hotspot- > > dev at openjdk.java.net alias > > so all Hotspot developers can see it. I did original changes but I am > > in > > Compiler (JIT) group. > > > > Krystal Mok wrote: > > > Hi all, > > > > > > I think I've found a bug in ClassFileParser::parseClassFile() that > > deals > > > with FieldsAllocationStyle=2, which was introduced about a year > > > ago: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/b9d85fcdf743 > > > > > > int map_size = super_klass->nonstatic_oop_map_size(); > > > OopMapBlock* first_map = > super_klass->start_of_nonstatic_oop_maps(); > > > OopMapBlock* last_map = first_map + map_size - 1; > > > > > > This code accidentally works on LP64 systems because it takes 1 > word > > per > > > OopMapBlock, so nonstatic_oop_map_size() and > > nonstatic_oop_map_count() > > > would actually return the same value. > > > > > > But on 32-bit systems, an OopMapBlock takes 2 words, which > > > makes nonstatic_oop_map_size() == nonstatic_oop_map_count() * > 2, and > > > breaks the code above. > > > > > > The code should really be: > > > > > > int map_count = super_klass->nonstatic_oop_map_count(); > > > OopMapBlock* first_map = > super_klass->start_of_nonstatic_oop_maps(); > > > OopMapBlock* last_map = first_map + map_count - 1; > > > > > > I found this because FieldsAllocationStyle=2 doesn't work for me on > > > 32-bit Windows (JDK6u25 and 6u26), but works on 64-bit Ubuntu > > JDK6u25. > > > Here's a min repro of my test: https://gist.github.com/1037866 > > > > > > Could anybody please verify this? > > > Just checked the current tip of hsx/hotspot-rt, and it still > has this > > > behavior: > > > http://hg.openjdk.java.net/hsx/hotspot- > > > rt/hotspot/file/1744e37e032b/src/share/vm/classfile/classFileParser.cpp > > > line 3290 > > > > > > Regards, > > > Kris Mok > > > What would be the use case/work load for choosing this option? > > > Thanks, > > David > > > From dmdabbs at gmail.com Wed Jun 22 14:23:54 2011 From: dmdabbs at gmail.com (David Dabbs) Date: Wed, 22 Jun 2011 16:23:54 -0500 Subject: Bug in FieldsAllocationStyle=2 logic In-Reply-To: <4E0256F9.1000204@oracle.com> References: <4E02289C.3060106@oracle.com> <021501cc310a$55546510$fffd2f30$@com> <4E0256F9.1000204@oracle.com> Message-ID: <025a01cc3122$b2490240$16db06c0$@com> > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, June 22, 2011 3:56 PM > To: Krystal Mok > Cc: David Dabbs; hotspot-dev > Subject: Re: Bug in FieldsAllocationStyle=2 logic > > I have nothing to add to Kris's nice explanation. > I just want to say that you should check if it really can help your > application. > It may help GC but it may also harm execution performance since > different layout > of fields may increase data cache misses. > > Vladimir > I knew there would be some 'fine print.' Would one need a tool like Intel VTune to measure cache miss impact before/after tweaking the option? David > Krystal Mok wrote: > > Hi David, > > > > I'll let Vladimir, the original author, give the definitive answer. > :-) > > > > Anyway, here's my guess: > > Packing oop fields together makes iterating oops in an object faster. > > For example, the marking phase of GC would benefit from this. > > > > Supposed we had a few classes as follows: > > > > class Base { > > Object o1; > > int i; > > } > > > > class Derived extends Base { > > Object o2; > > float f; > > } > > > > An instance of Derived would contain a Base subobject within itself. > > It's straightforward to keep the Base's field layout in the subobject > in > > an Derived instance; in other words, Base::o1 and Base::i would be at > > the same offset in a Base instance and in a Derived instance. > > > > So, to pack oops in Base and Derived together while keeping Base's > > layout intact in Derived, a reasonable solution is to alternate > between > > FieldsAllocationStyle=1 and FieldsAllocationStyle=0 in an inheritance > > chain. That's exactly what FieldsAllocationStyle is doing. > > > > But if we push hard to pack all oop fields in an object together, > we'd > > probably end up using a bidirectional object layout, like the one > used > > in SableVM (http://www.sablevm.org/features.html). It'd be really fun > to > > see this implemented in HotSpot VM sometime in the future. > > > > This paper is worth reading if you're interested in object layouts: > > A Comprehensive Evaluation of Object Scanning > > Techniques, http://users.cecs.anu.edu.au/~steveb/downloads/pdf/scan- > ismm-2011.pdf > > > > Regards, > > Kris Mok > > > > On Thu, Jun 23, 2011 at 2:29 AM, David Dabbs > > wrote: > > > > > > > > > -----Original Message----- > > > From: hotspot-dev-bounces at openjdk.java.net > > [mailto:hotspot- > dev- > > > > > bounces at openjdk.java.net ] On > > Behalf Of Vladimir Kozlov > > > Sent: Wednesday, June 22, 2011 12:39 PM > > > To: Krystal Mok > > > Cc: hotspot-dev > > > Subject: Re: Bug in FieldsAllocationStyle=2 logic > > > > > > Thank you for such detail analysis and suggested fix. > > > I filed bug and I will fix it in 7u2. > > > > > > 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM > > > > > > Thanks, > > > Vladimir > > > > > > PS: if possible, please, report problems to hotspot- > > > dev at openjdk.java.net alias > > > so all Hotspot developers can see it. I did original changes > but I am > > > in > > > Compiler (JIT) group. > > > > > > Krystal Mok wrote: > > > > Hi all, > > > > > > > > I think I've found a bug in > ClassFileParser::parseClassFile() that > > > deals > > > > with FieldsAllocationStyle=2, which was introduced about a > year > > > > ago: > http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/b9d85fcdf743 > > > > > > > > int map_size = super_klass->nonstatic_oop_map_size(); > > > > OopMapBlock* first_map = > > super_klass->start_of_nonstatic_oop_maps(); > > > > OopMapBlock* last_map = first_map + map_size - 1; > > > > > > > > This code accidentally works on LP64 systems because it > takes 1 > > word > > > per > > > > OopMapBlock, so nonstatic_oop_map_size() and > > > nonstatic_oop_map_count() > > > > would actually return the same value. > > > > > > > > But on 32-bit systems, an OopMapBlock takes 2 words, which > > > > makes nonstatic_oop_map_size() == nonstatic_oop_map_count() > * > > 2, and > > > > breaks the code above. > > > > > > > > The code should really be: > > > > > > > > int map_count = super_klass->nonstatic_oop_map_count(); > > > > OopMapBlock* first_map = > > super_klass->start_of_nonstatic_oop_maps(); > > > > OopMapBlock* last_map = first_map + map_count - 1; > > > > > > > > I found this because FieldsAllocationStyle=2 doesn't work > for me on > > > > 32-bit Windows (JDK6u25 and 6u26), but works on 64-bit > Ubuntu > > > JDK6u25. > > > > Here's a min repro of my test: > https://gist.github.com/1037866 > > > > > > > > Could anybody please verify this? > > > > Just checked the current tip of hsx/hotspot-rt, and it still > > has this > > > > behavior: > > > > http://hg.openjdk.java.net/hsx/hotspot- > > > > > > rt/hotspot/file/1744e37e032b/src/share/vm/classfile/classFileParser.cpp > > > > line 3290 > > > > > > > > Regards, > > > > Kris Mok > > > > > > What would be the use case/work load for choosing this option? > > > > > > Thanks, > > > > David > > > > > > From paul.hohensee at oracle.com Wed Jun 22 14:36:20 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Wed, 22 Jun 2011 17:36:20 -0400 Subject: Bug in FieldsAllocationStyle=2 logic In-Reply-To: <025a01cc3122$b2490240$16db06c0$@com> References: <4E02289C.3060106@oracle.com> <021501cc310a$55546510$fffd2f30$@com> <4E0256F9.1000204@oracle.com> <025a01cc3122$b2490240$16db06c0$@com> Message-ID: <4E026054.5040307@oracle.com> You can use tools like VTune, the Oracle (ex-Sun) Studio Collector/Analyzer and the AMD CodeAnalyst to find miss locations (and then map the asm code back to Java source if you like, which can be a pain), but you can also just run whatever benchmark you've got with different field allocation styles as many times as it takes to get a statistically significant result. Paul On 6/22/11 5:23 PM, David Dabbs wrote: >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, June 22, 2011 3:56 PM >> To: Krystal Mok >> Cc: David Dabbs; hotspot-dev >> Subject: Re: Bug in FieldsAllocationStyle=2 logic >> >> I have nothing to add to Kris's nice explanation. >> I just want to say that you should check if it really can help your >> application. >> It may help GC but it may also harm execution performance since >> different layout >> of fields may increase data cache misses. >> >> Vladimir >> > I knew there would be some 'fine print.' > Would one need a tool like Intel VTune to measure cache miss impact > before/after tweaking the option? > > David > > >> Krystal Mok wrote: >>> Hi David, >>> >>> I'll let Vladimir, the original author, give the definitive answer. >> :-) >>> Anyway, here's my guess: >>> Packing oop fields together makes iterating oops in an object faster. >>> For example, the marking phase of GC would benefit from this. >>> >>> Supposed we had a few classes as follows: >>> >>> class Base { >>> Object o1; >>> int i; >>> } >>> >>> class Derived extends Base { >>> Object o2; >>> float f; >>> } >>> >>> An instance of Derived would contain a Base subobject within itself. >>> It's straightforward to keep the Base's field layout in the subobject >> in >>> an Derived instance; in other words, Base::o1 and Base::i would be at >>> the same offset in a Base instance and in a Derived instance. >>> >>> So, to pack oops in Base and Derived together while keeping Base's >>> layout intact in Derived, a reasonable solution is to alternate >> between >>> FieldsAllocationStyle=1 and FieldsAllocationStyle=0 in an inheritance >>> chain. That's exactly what FieldsAllocationStyle is doing. >>> >>> But if we push hard to pack all oop fields in an object together, >> we'd >>> probably end up using a bidirectional object layout, like the one >> used >>> in SableVM (http://www.sablevm.org/features.html). It'd be really fun >> to >>> see this implemented in HotSpot VM sometime in the future. >>> >>> This paper is worth reading if you're interested in object layouts: >>> A Comprehensive Evaluation of Object Scanning >>> Techniques, http://users.cecs.anu.edu.au/~steveb/downloads/pdf/scan- >> ismm-2011.pdf >>> Regards, >>> Kris Mok >>> >>> On Thu, Jun 23, 2011 at 2:29 AM, David Dabbs>> > wrote: >>> >>> >>> >>> > -----Original Message----- >>> > From: hotspot-dev-bounces at openjdk.java.net >>> [mailto:hotspot- >> dev- >>> >>> > bounces at openjdk.java.net] On >>> Behalf Of Vladimir Kozlov >>> > Sent: Wednesday, June 22, 2011 12:39 PM >>> > To: Krystal Mok >>> > Cc: hotspot-dev >>> > Subject: Re: Bug in FieldsAllocationStyle=2 logic >>> > >>> > Thank you for such detail analysis and suggested fix. >>> > I filed bug and I will fix it in 7u2. >>> > >>> > 7058036: FieldsAllocationStyle=2 does not work in 32-bit VM >>> > >>> > Thanks, >>> > Vladimir >>> > >>> > PS: if possible, please, report problems to hotspot- >>> > dev at openjdk.java.net alias >>> > so all Hotspot developers can see it. I did original changes >> but I am >>> > in >>> > Compiler (JIT) group. >>> > >>> > Krystal Mok wrote: >>> > > Hi all, >>> > > >>> > > I think I've found a bug in >> ClassFileParser::parseClassFile() that >>> > deals >>> > > with FieldsAllocationStyle=2, which was introduced about a >> year >>> > > ago: >> http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/b9d85fcdf743 >>> > > >>> > > int map_size = super_klass->nonstatic_oop_map_size(); >>> > > OopMapBlock* first_map = >>> super_klass->start_of_nonstatic_oop_maps(); >>> > > OopMapBlock* last_map = first_map + map_size - 1; >>> > > >>> > > This code accidentally works on LP64 systems because it >> takes 1 >>> word >>> > per >>> > > OopMapBlock, so nonstatic_oop_map_size() and >>> > nonstatic_oop_map_count() >>> > > would actually return the same value. >>> > > >>> > > But on 32-bit systems, an OopMapBlock takes 2 words, which >>> > > makes nonstatic_oop_map_size() == nonstatic_oop_map_count() >> * >>> 2, and >>> > > breaks the code above. >>> > > >>> > > The code should really be: >>> > > >>> > > int map_count = super_klass->nonstatic_oop_map_count(); >>> > > OopMapBlock* first_map = >>> super_klass->start_of_nonstatic_oop_maps(); >>> > > OopMapBlock* last_map = first_map + map_count - 1; >>> > > >>> > > I found this because FieldsAllocationStyle=2 doesn't work >> for me on >>> > > 32-bit Windows (JDK6u25 and 6u26), but works on 64-bit >> Ubuntu >>> > JDK6u25. >>> > > Here's a min repro of my test: >> https://gist.github.com/1037866 >>> > > >>> > > Could anybody please verify this? >>> > > Just checked the current tip of hsx/hotspot-rt, and it still >>> has this >>> > > behavior: >>> > > http://hg.openjdk.java.net/hsx/hotspot- >>> > >>> >> rt/hotspot/file/1744e37e032b/src/share/vm/classfile/classFileParser.cpp >>> > > line 3290 >>> > > >>> > > Regards, >>> > > Kris Mok >>> >>> >>> What would be the use case/work load for choosing this option? >>> >>> >>> Thanks, >>> >>> David >>> >>> >>> From dmdabbs at gmail.com Wed Jun 22 15:06:33 2011 From: dmdabbs at gmail.com (David Dabbs) Date: Wed, 22 Jun 2011 17:06:33 -0500 Subject: Bug in FieldsAllocationStyle=2 logic In-Reply-To: <4E026054.5040307@oracle.com> References: <4E02289C.3060106@oracle.com> <021501cc310a$55546510$fffd2f30$@com> <4E0256F9.1000204@oracle.com> <025a01cc3122$b2490240$16db06c0$@com> <4E026054.5040307@oracle.com> Message-ID: <025f01cc3128$a7af7b10$f70e7130$@com> > -----Original Message----- > From: Paul Hohensee [mailto:paul.hohensee at oracle.com] > Sent: Wednesday, June 22, 2011 4:36 PM > To: David Dabbs > Cc: 'Vladimir Kozlov'; 'Krystal Mok'; 'hotspot-dev' > Subject: Re: Bug in FieldsAllocationStyle=2 logic > > You can use tools like VTune, the Oracle (ex-Sun) Studio > Collector/Analyzer > and the AMD CodeAnalyst to find miss locations (and then map the asm > code back to Java source if you like, which can be a pain), but you can > also > just run whatever benchmark you've got with different field allocation > styles > as many times as it takes to get a statistically significant result. > > Paul > Thank you Paul. I wish we had some standard SPEC-like bench to run. It's a production app that handles hundreds of millions of messages daily in different formats from numerous sources. So we don't really have a good way to simulate that workload. Point taken, though. We could make our best synthetic load test and try it with different FieldAllocationStyles. Best, David > On 6/22/11 5:23 PM, David Dabbs wrote: > >> -----Original Message----- > >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > >> Sent: Wednesday, June 22, 2011 3:56 PM > >> To: Krystal Mok > >> Cc: David Dabbs; hotspot-dev > >> Subject: Re: Bug in FieldsAllocationStyle=2 logic > >> > >> I have nothing to add to Kris's nice explanation. > >> I just want to say that you should check if it really can help your > >> application. > >> It may help GC but it may also harm execution performance since > >> different layout > >> of fields may increase data cache misses. > >> > >> Vladimir > >> > > I knew there would be some 'fine print.' > > Would one need a tool like Intel VTune to measure cache miss impact > > before/after tweaking the option? > > > > David > > > > > >> Krystal Mok wrote: > >>> Hi David, > >>> > >>> I'll let Vladimir, the original author, give the definitive answer. > >> :-) > >>> Anyway, here's my guess: > >>> Packing oop fields together makes iterating oops in an object > faster. > >>> For example, the marking phase of GC would benefit from this. > >>> > >>> Supposed we had a few classes as follows: > >>> > >>> class Base { > >>> Object o1; > >>> int i; > >>> } > >>> > >>> class Derived extends Base { > >>> Object o2; > >>> float f; > >>> } > >>> > >>> An instance of Derived would contain a Base subobject within > itself. > >>> It's straightforward to keep the Base's field layout in the > subobject > >> in > >>> an Derived instance; in other words, Base::o1 and Base::i would be > at > >>> the same offset in a Base instance and in a Derived instance. > >>> > >>> So, to pack oops in Base and Derived together while keeping Base's > >>> layout intact in Derived, a reasonable solution is to alternate > >> between > >>> FieldsAllocationStyle=1 and FieldsAllocationStyle=0 in an > inheritance > >>> chain. That's exactly what FieldsAllocationStyle is doing. > >>> > >>> But if we push hard to pack all oop fields in an object together, > >> we'd > >>> probably end up using a bidirectional object layout, like the one > >> used > >>> in SableVM (http://www.sablevm.org/features.html). It'd be really > fun > >> to > >>> see this implemented in HotSpot VM sometime in the future. > >>> > >>> This paper is worth reading if you're interested in object layouts: > >>> A Comprehensive Evaluation of Object Scanning > >>> Techniques, > http://users.cecs.anu.edu.au/~steveb/downloads/pdf/scan- > >> ismm-2011.pdf > >>> Regards, > >>> Kris Mok > >>> > >>> On Thu, Jun 23, 2011 at 2:29 AM, David Dabbs >>> > wrote: > >>> > >>> > >>> > >>> > -----Original Message----- > >>> > From: hotspot-dev-bounces at openjdk.java.net > >>> > [mailto:hotspot- > >> dev- > >>> > >>> > bounces at openjdk.java.net] > On > >>> Behalf Of Vladimir Kozlov > >>> > Sent: Wednesday, June 22, 2011 12:39 PM > >>> > To: Krystal Mok > >>> > Cc: hotspot-dev > >>> > Subject: Re: Bug in FieldsAllocationStyle=2 logic > >>> > > >>> > Thank you for such detail analysis and suggested fix. > >>> > I filed bug and I will fix it in 7u2. > >>> > > >>> > 7058036: FieldsAllocationStyle=2 does not work in 32-bit > VM > >>> > > >>> > Thanks, > >>> > Vladimir > >>> > > >>> > PS: if possible, please, report problems to hotspot- > >>> > dev at openjdk.java.net alias > >>> > so all Hotspot developers can see it. I did original > changes > >> but I am > >>> > in > >>> > Compiler (JIT) group. > >>> > > >>> > Krystal Mok wrote: > >>> > > Hi all, > >>> > > > >>> > > I think I've found a bug in > >> ClassFileParser::parseClassFile() that > >>> > deals > >>> > > with FieldsAllocationStyle=2, which was introduced > about a > >> year > >>> > > ago: > >> http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/b9d85fcdf743 > >>> > > > >>> > > int map_size = super_klass->nonstatic_oop_map_size(); > >>> > > OopMapBlock* first_map = > >>> super_klass->start_of_nonstatic_oop_maps(); > >>> > > OopMapBlock* last_map = first_map + map_size - 1; > >>> > > > >>> > > This code accidentally works on LP64 systems because it > >> takes 1 > >>> word > >>> > per > >>> > > OopMapBlock, so nonstatic_oop_map_size() and > >>> > nonstatic_oop_map_count() > >>> > > would actually return the same value. > >>> > > > >>> > > But on 32-bit systems, an OopMapBlock takes 2 words, > which > >>> > > makes nonstatic_oop_map_size() == > nonstatic_oop_map_count() > >> * > >>> 2, and > >>> > > breaks the code above. > >>> > > > >>> > > The code should really be: > >>> > > > >>> > > int map_count = super_klass->nonstatic_oop_map_count(); > >>> > > OopMapBlock* first_map = > >>> super_klass->start_of_nonstatic_oop_maps(); > >>> > > OopMapBlock* last_map = first_map + map_count - 1; > >>> > > > >>> > > I found this because FieldsAllocationStyle=2 doesn't > work > >> for me on > >>> > > 32-bit Windows (JDK6u25 and 6u26), but works on 64-bit > >> Ubuntu > >>> > JDK6u25. > >>> > > Here's a min repro of my test: > >> https://gist.github.com/1037866 > >>> > > > >>> > > Could anybody please verify this? > >>> > > Just checked the current tip of hsx/hotspot-rt, and it > still > >>> has this > >>> > > behavior: > >>> > > http://hg.openjdk.java.net/hsx/hotspot- > >>> > > >>> > >> > rt/hotspot/file/1744e37e032b/src/share/vm/classfile/classFileParser.cpp > >>> > > line 3290 > >>> > > > >>> > > Regards, > >>> > > Kris Mok > >>> > >>> > >>> What would be the use case/work load for choosing this option? > >>> > >>> > >>> Thanks, > >>> > >>> David > >>> > >>> > >>> From c.m.bockisch at cs.utwente.nl Thu Jun 23 08:17:33 2011 From: c.m.bockisch at cs.utwente.nl (Christoph Bockisch) Date: Thu, 23 Jun 2011 17:17:33 +0200 Subject: invitation to submit to workshop on Virtual Machines and Intermediate Languages (VMIL) Message-ID: <4E03590D.8040607@cs.utwente.nl> Dear Colleagues: It gives us great pleasure to invite you to submit your contributions to **the fifth international workshop on Virtual Machines and Intermediate Languages (VMIL 2011)**, which will be co-located with SPLASH 2011. This workshop is a forum for research in virtual machines (VM) and intermediate languages (IL). It is dedicated to identifying programming mechanisms and constructs that are currently realized as code transformations or implemented in libraries but should rather be supported at VM and IL level. ------------------------------------------------------------ **Invited Talks** In the tradition of past VMIL workshops, the 2011 edition will feature high-quality, on-topic invited talks. Speakers and titles will be announced later. ------------------------------------------------------------ **Due Dates** Papers for VMIL are due Aug 8, 2011. Abstract submission is not required but recommended until August 1, 2011. Notification of acceptance will be on Sep 1, 2011. ------------------------------------------------------------ **Program Committee** We have once again assembled an excellent program committee which consists of: Steve Blackburn (Chair), Cliff Click, David Grove, Kim Hazelwood, Antony Hosking, Doug Lea, Ben Titzer, and Olivier Zendra. ------------------------------------------------------------ For more details please see: http://www.cs.iastate.edu/~design/vmil/ We look forward to your submissions to VMIL 2011. Best regards, Hridesh Rajan, Christoph Bockisch, Michael Haupt and Robert Dyer VMIL 2011 Organizers From vladimir.kozlov at oracle.com Thu Jun 23 16:31:05 2011 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 23 Jun 2011 23:31:05 +0000 Subject: hg: jdk7/hotspot/hotspot: 3 new changesets Message-ID: <20110623233113.3BF6847297@hg.openjdk.java.net> Changeset: 782e2bb60c41 Author: kvn Date: 2011-06-20 16:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/782e2bb60c41 7052494: Eclipse test fails on JDK 7 b142 Summary: Keep 'ne' test in Counted loop when we can't guarantee during compilation that init < limit. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp + test/compiler/7052494/Test7052494.java Changeset: a3081a3a2b54 Author: never Date: 2011-06-21 09:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a3081a3a2b54 7056380: VM crashes with SIGSEGV in compiled code Summary: code was using andq reg, imm instead of addq addr, imm Reviewed-by: kvn, jrose, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_64.ad Changeset: 393e144bb99b Author: never Date: 2011-06-22 14:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/393e144bb99b 7057587: JSR 292 - crash with jruby in test/test_respond_to.rb Summary: don't skip receiver when GC'ing compiled invokedynamic callsites Reviewed-by: twisti, kvn, jrose ! src/share/vm/code/nmethod.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp From erik.trimble at oracle.com Thu Jun 23 22:51:15 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Fri, 24 Jun 2011 05:51:15 +0000 Subject: hg: jdk7/hotspot/hotspot: 4 new changesets Message-ID: <20110624055122.90537472BB@hg.openjdk.java.net> Changeset: f6ba9007b2c6 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f6ba9007b2c6 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 5bb91b0db2c9 Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/5bb91b0db2c9 Merge Changeset: b3a485ccfe86 Author: trims Date: 2011-06-23 22:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/b3a485ccfe86 Merge Changeset: e9b51b4bdcc7 Author: trims Date: 2011-06-23 22:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/e9b51b4bdcc7 7057556: Bump the HS21 build number to 17 Summary: Update the HS21 build number to 17 Reviewed-by: jcoomes ! make/hotspot_version From john.r.rose at oracle.com Sat Jun 25 02:38:00 2011 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 25 Jun 2011 09:38:00 +0000 Subject: hg: jdk7/hotspot/hotspot: 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path Message-ID: <20110625093802.CCE90472FE@hg.openjdk.java.net> Changeset: 81d815b05abb Author: jrose Date: 2011-06-23 17:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/81d815b05abb 7056328: JSR 292 invocation sometimes fails in adapters for types not on boot class path Reviewed-by: never ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp From David.Holmes at oracle.com Sat Jun 25 03:05:24 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 25 Jun 2011 20:05:24 +1000 Subject: 64-bit client VM In-Reply-To: References: Message-ID: <4E05B2E4.3020607@oracle.com> Aekold Helbrass said the following on 06/25/11 19:37: > Sorry if this is wrong mailing list to ask that question, but it's the > only one that looks suitable by its description... It's really a hotspot question so I've cc'ed that list. > README file tells "64-bit client builds are not directly supported". So: > 1) What is the reason of this? Does it mean that client vm source code > was not adapted to 64-bit systems or just that Sun/Oracle don't want > to provide technical support for this? We don't build it nor test it on a regular basis internally. The code was originally developed for a proprietary product - Sun Java Real-Time System - and was then added to OpenJDK. We don't officially support it. > 2) How badly unsupported it it? Will it work fine but possibly will > have some bugs, will it work fine but not as efficient as 32-bit > client, or it will hardly work at all? I don't know where it stands regarding support for latest Java 7 features, but otherwise it should work ok. No idea how to compare performance against 32-bit client. Build it and see is all I can advise. The Makefiles will need some tweaking to allow this when doing a full JDK build. Otherwise I think you can just do: cd hotspot/make make LP64=1 product1 David Holmes From erik.trimble at oracle.com Sat Jun 25 03:48:51 2011 From: erik.trimble at oracle.com (Erik Trimble) Date: Sat, 25 Jun 2011 03:48:51 -0700 Subject: 64-bit client VM In-Reply-To: <4E05B2E4.3020607@oracle.com> References: <4E05B2E4.3020607@oracle.com> Message-ID: <4E05BD13.8070406@oracle.com> On 6/25/2011 3:05 AM, David Holmes wrote: > Aekold Helbrass said the following on 06/25/11 19:37: >> Sorry if this is wrong mailing list to ask that question, but it's the >> only one that looks suitable by its description... > > It's really a hotspot question so I've cc'ed that list. > >> README file tells "64-bit client builds are not directly supported". So: >> 1) What is the reason of this? Does it mean that client vm source code >> was not adapted to 64-bit systems or just that Sun/Oracle don't want >> to provide technical support for this? > > We don't build it nor test it on a regular basis internally. The code > was originally developed for a proprietary product - Sun Java > Real-Time System - and was then added to OpenJDK. We don't officially > support it. > >> 2) How badly unsupported it it? Will it work fine but possibly will >> have some bugs, will it work fine but not as efficient as 32-bit >> client, or it will hardly work at all? > > I don't know where it stands regarding support for latest Java 7 > features, but otherwise it should work ok. No idea how to compare > performance against 32-bit client. > I'd have to re-look, by AFAIK, the 64-bit client VM is fully jdk7-compliant. I don't know about support for the G1 Garbage collector, but it has the others. Performance is a complete unknown. > Build it and see is all I can advise. The Makefiles will need some > tweaking to allow this when doing a full JDK build. Otherwise I think > you can just do: > > cd hotspot/make > make LP64=1 product1 > > David Holmes Please don't take this as gospel, and I certainly don't speak for Oracle in any way, but as the proliferation of 64-bit client OSes increases drastically, I would expect that the community will want a 64-bit client VM much sooner than otherwise anticipated. Of course, most OSes will continue to support running 32-bit binaries on a fully 64-bit system, but I expect many of the "purists" out there will be very interested in getting the client VM fully on 64-bit. If, for no other reason, than to run with 64-bit Firefox on Linux. Also, it might actually simplify Oracle's support in some ways - in particular, if we had a 64-bit client VM for Solaris, we could (and likely would) completely dump the 32-bit JDK/JRE on Solaris. Once again, that is speculation, but I also can see it happening quite easily. If someone wants to work on 64-bit client, I certainly don't see anyone discouraging it. -- Erik Trimble Java Platform Group Infrastructure Mailstop: usca22-317 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (UTC-0800) From David.Holmes at oracle.com Sat Jun 25 04:49:32 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 25 Jun 2011 21:49:32 +1000 Subject: 64-bit client VM In-Reply-To: <4E05BD13.8070406@oracle.com> References: <4E05B2E4.3020607@oracle.com> <4E05BD13.8070406@oracle.com> Message-ID: <4E05CB4C.1060507@oracle.com> Erik Trimble said the following on 06/25/11 20:48: > Also, it might actually simplify Oracle's support in some ways - in > particular, if we had a 64-bit client VM for Solaris, we could (and > likely would) completely dump the 32-bit JDK/JRE on Solaris. Once > again, that is speculation, but I also can see it happening quite easily. Given I run Solaris on a x86 system (not x64) I'd be pretty peeved if that were to happen. ;-) David From y.s.ramakrishna at oracle.com Sat Jun 25 08:51:45 2011 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Sat, 25 Jun 2011 08:51:45 -0700 Subject: 64-bit client VM In-Reply-To: <4E05CB4C.1060507@oracle.com> References: <4E05B2E4.3020607@oracle.com> <4E05BD13.8070406@oracle.com> <4E05CB4C.1060507@oracle.com> Message-ID: <4E060411.2040508@oracle.com> On 6/25/2011 4:49 AM, David Holmes wrote: > Erik Trimble said the following on 06/25/11 20:48: > >> Also, it might actually simplify Oracle's support in some ways - in particular, if we had a 64-bit >> client VM for Solaris, we could (and likely would) completely dump the 32-bit JDK/JRE on Solaris. >> Once again, that is speculation, but I also can see it happening quite easily. > > Given I run Solaris on a x86 system (not x64) I'd be pretty peeved if that were to happen. ;-) Going further, one could dump the "pure" client VM and just use server, given we have tiered in place now (but off by default?) ? -- ramki From y.s.ramakrishna at oracle.com Sat Jun 25 08:55:56 2011 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Sat, 25 Jun 2011 08:55:56 -0700 Subject: 64-bit client VM In-Reply-To: <4E060411.2040508@oracle.com> References: <4E05B2E4.3020607@oracle.com> <4E05BD13.8070406@oracle.com> <4E05CB4C.1060507@oracle.com> <4E060411.2040508@oracle.com> Message-ID: <4E06050C.1050804@oracle.com> On 6/25/2011 8:51 AM, Y. Srinivas Ramakrishna wrote: > On 6/25/2011 4:49 AM, David Holmes wrote: >> Erik Trimble said the following on 06/25/11 20:48: >> >>> Also, it might actually simplify Oracle's support in some ways - in particular, if we had a 64-bit >>> client VM for Solaris, we could (and likely would) completely dump the 32-bit JDK/JRE on Solaris. >>> Once again, that is speculation, but I also can see it happening quite easily. >> >> Given I run Solaris on a x86 system (not x64) I'd be pretty peeved if that were to happen. ;-) > > Going further, one could dump the "pure" client VM and just use server, given we have > tiered in place now (but off by default?) ? Of course that wouldn't reduce support costs (since the client vm would still be in the vm binaries, it would be that we'd just ship/support a single tiered 32-bit JVM binary and a single tiered 64 bit JVM binary, instead of the 3 JVM binaries per OS that we currently do. -- ramki From paul.hohensee at oracle.com Sat Jun 25 12:30:58 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Sat, 25 Jun 2011 15:30:58 -0400 Subject: 64-bit client VM In-Reply-To: <4E060411.2040508@oracle.com> References: <4E05B2E4.3020607@oracle.com> <4E05BD13.8070406@oracle.com> <4E05CB4C.1060507@oracle.com> <4E060411.2040508@oracle.com> Message-ID: <4E063772.5060901@oracle.com> Making tiered the default is on the list of things to do. As Ramki implies, when that happens, we expect there not to be much call for a pure 64-bit client jvm. And there might indeed be little call for a 32-bit jvm on Solaris-x64 systems at that point. Paul On 6/25/11 11:51 AM, Y. Srinivas Ramakrishna wrote: > On 6/25/2011 4:49 AM, David Holmes wrote: >> Erik Trimble said the following on 06/25/11 20:48: >> >>> Also, it might actually simplify Oracle's support in some ways - in >>> particular, if we had a 64-bit >>> client VM for Solaris, we could (and likely would) completely dump >>> the 32-bit JDK/JRE on Solaris. >>> Once again, that is speculation, but I also can see it happening >>> quite easily. >> >> Given I run Solaris on a x86 system (not x64) I'd be pretty peeved if >> that were to happen. ;-) > > Going further, one could dump the "pure" client VM and just use > server, given we have > tiered in place now (but off by default?) ? > > -- ramki From huangyifei123 at gmail.com Sun Jun 26 05:10:23 2011 From: huangyifei123 at gmail.com (Huang Yifei) Date: Sun, 26 Jun 2011 20:10:23 +0800 Subject: What the difference between -Xss and -XX:ThreadStackSize is? Message-ID: Rencently, i have found another JVM option -XX:ThreadStackSize to set thread stack size in java, but who can tell me what the difference between -Xss and -XX:ThreadStackSize in java? By the way, I also want to know whether the java thread stack is equivalent to the native thread stack? Oscar Huang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110626/bdad6ea8/attachment.html From rednaxelafx at gmail.com Sun Jun 26 08:02:50 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Sun, 26 Jun 2011 23:02:50 +0800 Subject: What the difference between -Xss and -XX:ThreadStackSize is? In-Reply-To: References: Message-ID: Hi Oscar, who can tell me what the difference between -Xss and -XX:ThreadStackSize in > java? There's basically no difference between -Xss and -XX:ThreadStackSize, except that the former dates before HotSpot became the default JVM in Sun's JDK, where as the latter is an internal VM flag of HotSpot. In effect, the former is support in a lot of other JVMs, but the latter is specific to HotSpot. As an historical aside, the command line arguments for Sun JDK 1.0.x and 1.1.x had these: -ss set the C stack size of a process -oss set the JAVA stack size of a process These arguments got deprecated by -Xss and -Xoss in later versions of JDK. Non-internal flags either get processd by the java launcher (such as -server, -client, -verbosegc, etc.) or get converted into VM internal flags by HotSpot. See hotspot/src/share/vm/runtime/arguments.cpp for details. For example, see this version: the launcher part: http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/f097ca2434b1/src/share/bin/java.c lines 1052 - 1058, and the VM part: http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/81d815b05abb/src/share/vm/runtime/arguments.cpp lines 2227 - 2240. As you can see, -Xss gets converted into ThreadStackSize before the VM gets to use it. If the user did specify -ss or -Xss in command line arguments, that'll get picked up directly by the launcher to run the main Java thread. Otherwise, the launcher asks the VM for a preferred stack size, and HotSpot will return ThreadStackSize, see here: http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/81d815b05abb/src/share/vm/prims/jni.cpp, lines 3286 - 3295. That should explain how they've been implemented to be basically equivalent in HotSpot. One thing, though: because the -Xss/-XX:ThreadStackSize argument is handled by the VM, *after* the primordial thread has been created, so they won't cover the stack size of the primordial thread. In order to control stack size correctly, Oracle/Sun's JDK doesn't run Java code in the primordial thread. See this bug: http://bugs.sun.com/view_bug.do?bug_id=6316197. If you ever felt the function "ContinueInNewThread" in the launcher was weird, that's the fix for this issue, so that Java code doesn't get run in the primordial thread in HotSpot. By the way, I also want to know whether the java thread stack is equivalent > to the native thread stack? The stock HotSpot VM (the one in Oracle's Java SE JDK and OpenJDK) uses the same stack for Java and native methods for a Java thread; Java frames and native frames can be mixed together in such a stack. -Xss/-XX:ThreadStackSize controls the whole stack's size for Java threads. Because of this, -Xoss is simply ignored by HotSpot -- there's no separate stack to set the size for. There are some variants of HotSpot VM that does use a separate interpreter stack, e.g. Azul's version. See this post from Cliff Click for more details of the Azul implementation: http://www.azulsystems.com/blog/cliff/2010-04-06-jitd-code-calling-conventions-or-answering-plea-geekyness Regards, Kris Mok On Sun, Jun 26, 2011 at 8:10 PM, Huang Yifei wrote: > Rencently, i have found another JVM option -XX:ThreadStackSize to set > thread stack size in java, but who can tell me what the difference > between -Xss and -XX:ThreadStackSize in java? > > By the way, I also want to know whether the java thread stack is > equivalent to the native thread stack? > > Oscar Huang -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20110626/c4cf2966/attachment.html From erik.trimble at oracle.com Tue Jun 28 11:20:04 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 28 Jun 2011 18:20:04 +0000 Subject: hg: jdk7/hotspot: 3 new changesets Message-ID: <20110628182004.80CC9473D8@hg.openjdk.java.net> Changeset: 8da980eedab6 Author: jeff Date: 2011-06-22 10:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/8da980eedab6 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: d91364304d7c Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/d91364304d7c Merge Changeset: ee67ee3bd597 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/rev/ee67ee3bd597 Added tag jdk7-b147 for changeset d91364304d7c ! .hgtags From erik.trimble at oracle.com Tue Jun 28 11:20:14 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 28 Jun 2011 18:20:14 +0000 Subject: hg: jdk7/hotspot/corba: 3 new changesets Message-ID: <20110628182016.E47FB473D9@hg.openjdk.java.net> Changeset: bba0e37d7006 Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/bba0e37d7006 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 73323cb33962 Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/73323cb33962 Merge Changeset: 960011ba4bf2 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/corba/rev/960011ba4bf2 Added tag jdk7-b147 for changeset 73323cb33962 ! .hgtags From erik.trimble at oracle.com Tue Jun 28 11:20:58 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 28 Jun 2011 18:20:58 +0000 Subject: hg: jdk7/hotspot/hotspot: 2 new changesets Message-ID: <20110628182110.6E2B2473DA@hg.openjdk.java.net> Changeset: 684b3ad7bfbc Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/684b3ad7bfbc Added tag jdk7-b147 for changeset 81d815b05abb ! .hgtags Changeset: 9b0ca45cd756 Author: trims Date: 2011-06-28 10:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/9b0ca45cd756 Added tag hs21-b17 for changeset 81d815b05abb ! .hgtags From erik.trimble at oracle.com Tue Jun 28 11:22:11 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 28 Jun 2011 18:22:11 +0000 Subject: hg: jdk7/hotspot/jaxp: 3 new changesets Message-ID: <20110628182211.5F52B473DB@hg.openjdk.java.net> Changeset: eed2486cb10b Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/eed2486cb10b 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: fc268cd1dd5d Author: lana Date: 2011-06-22 12:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/fc268cd1dd5d Merge Changeset: 6c9ac74190a0 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxp/rev/6c9ac74190a0 Added tag jdk7-b147 for changeset fc268cd1dd5d ! .hgtags From erik.trimble at oracle.com Tue Jun 28 11:22:20 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 28 Jun 2011 18:22:20 +0000 Subject: hg: jdk7/hotspot/jaxws: 3 new changesets Message-ID: <20110628182220.AEBA5473DC@hg.openjdk.java.net> Changeset: 632e38191caa Author: jeff Date: 2011-06-22 10:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/632e38191caa 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: d13b1f877bb5 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/d13b1f877bb5 Merge Changeset: 2605f832dfbf Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jaxws/rev/2605f832dfbf Added tag jdk7-b147 for changeset d13b1f877bb5 ! .hgtags From erik.trimble at oracle.com Tue Jun 28 11:22:32 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 28 Jun 2011 18:22:32 +0000 Subject: hg: jdk7/hotspot/jdk: 3 new changesets Message-ID: <20110628182328.8ADC5473DD@hg.openjdk.java.net> Changeset: cfd7602f5c52 Author: jeff Date: 2011-06-22 10:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/cfd7602f5c52 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: f097ca2434b1 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/f097ca2434b1 Merge Changeset: 9b8c96f96a0f Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/jdk/rev/9b8c96f96a0f Added tag jdk7-b147 for changeset f097ca2434b1 ! .hgtags From erik.trimble at oracle.com Tue Jun 28 11:24:47 2011 From: erik.trimble at oracle.com (erik.trimble at oracle.com) Date: Tue, 28 Jun 2011 18:24:47 +0000 Subject: hg: jdk7/hotspot/langtools: 3 new changesets Message-ID: <20110628182459.6D186473DE@hg.openjdk.java.net> Changeset: a72412b148d7 Author: jeff Date: 2011-06-22 10:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/a72412b148d7 7057046: Add embedded license to THIRD PARTY README Reviewed-by: lana ! THIRD_PARTY_README Changeset: 58bc532d6341 Author: lana Date: 2011-06-22 12:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/58bc532d6341 Merge Changeset: ce654f4ecfd8 Author: schien Date: 2011-06-27 13:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot/langtools/rev/ce654f4ecfd8 Added tag jdk7-b147 for changeset 58bc532d6341 ! .hgtags