From coleen.phillimore at oracle.com Wed Jun 1 07:50:27 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 01 Jun 2011 10:50:27 -0400 Subject: Request for review 7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63 Message-ID: <4DE651B3.7040607@oracle.com> Summary: Removed extra change from another bug fix that caused this regression I'd left a line in from a different bug fix thinking it couldn't hurt anything, but it did. Tested with stress test suite that showed this bug. open webrev at http://cr.openjdk.java.net/~coleenp/7049928/ bug link at http://bugs.sun.com/view_bug.do?bug_id=7049928 Thanks, Coleen From daniel.daugherty at oracle.com Wed Jun 1 08:34:42 2011 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 01 Jun 2011 09:34:42 -0600 Subject: Request for review 7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63 In-Reply-To: <4DE651B3.7040607@oracle.com> References: <4DE651B3.7040607@oracle.com> Message-ID: <4DE65C12.2030907@oracle.com> Thumbs up. Dan On 6/1/2011 8:50 AM, Coleen Phillimore wrote: > Summary: Removed extra change from another bug fix that caused this > regression > > I'd left a line in from a different bug fix thinking it couldn't hurt > anything, but it did. > Tested with stress test suite that showed this bug. > > open webrev at http://cr.openjdk.java.net/~coleenp/7049928/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7049928 > > Thanks, > Coleen From vladimir.kozlov at oracle.com Wed Jun 1 09:04:58 2011 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Jun 2011 09:04:58 -0700 Subject: Request for review 7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63 In-Reply-To: <4DE651B3.7040607@oracle.com> References: <4DE651B3.7040607@oracle.com> Message-ID: <4DE6632A.6080406@oracle.com> Looks good. Vladimir Coleen Phillimore wrote: > Summary: Removed extra change from another bug fix that caused this > regression > > I'd left a line in from a different bug fix thinking it couldn't hurt > anything, but it did. > Tested with stress test suite that showed this bug. > > open webrev at http://cr.openjdk.java.net/~coleenp/7049928/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7049928 > > Thanks, > Coleen From tom.rodriguez at oracle.com Wed Jun 1 09:12:03 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 1 Jun 2011 09:12:03 -0700 Subject: Request for review 7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63 In-Reply-To: <4DE651B3.7040607@oracle.com> References: <4DE651B3.7040607@oracle.com> Message-ID: Looks good. tom On Jun 1, 2011, at 7:50 AM, Coleen Phillimore wrote: > Summary: Removed extra change from another bug fix that caused this regression > > I'd left a line in from a different bug fix thinking it couldn't hurt anything, but it did. > Tested with stress test suite that showed this bug. > > open webrev at http://cr.openjdk.java.net/~coleenp/7049928/ > bug link at http://bugs.sun.com/view_bug.do?bug_id=7049928 > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Jun 1 11:22:49 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 01 Jun 2011 14:22:49 -0400 Subject: Request for review 7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63 In-Reply-To: References: <4DE651B3.7040607@oracle.com> Message-ID: <4DE68379.30702@oracle.com> Thanks! Coleen On 6/1/2011 12:12 PM, Tom Rodriguez wrote: > Looks good. > > tom > > On Jun 1, 2011, at 7:50 AM, Coleen Phillimore wrote: > >> Summary: Removed extra change from another bug fix that caused this regression >> >> I'd left a line in from a different bug fix thinking it couldn't hurt anything, but it did. >> Tested with stress test suite that showed this bug. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/7049928/ >> bug link at http://bugs.sun.com/view_bug.do?bug_id=7049928 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Thu Jun 2 15:28:59 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 02 Jun 2011 22:28:59 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7049928: VM crashes with "assert(_adapter != NULL) failed: must have" at methodOop.cpp:63 Message-ID: <20110602222904.B6D2347B22@hg.openjdk.java.net> Changeset: 9dd6c4ba364f Author: coleenp Date: 2011-06-02 14:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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 From coleen.phillimore at oracle.com Thu Jun 2 23:39:35 2011 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 03 Jun 2011 06:39:35 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 15 new changesets Message-ID: <20110603064007.403AE47B42@hg.openjdk.java.net> Changeset: 789d04408ca3 Author: kvn Date: 2011-05-21 11:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/789d04408ca3 7045693: java/util/EnumSet/EnumSetBash.java still failing intermittently Summary: New limit for unrolled loop should be set only for zero trip guard and loop iteration test. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp Changeset: b55f5bd7ec66 Author: kvn Date: 2011-05-21 13:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b55f5bd7ec66 7045506: assert(!can_reshape || !new_phi) failed: for igvn new phi should be hooked Summary: Replace the assert in PhiNode::Ideal with check to avoid transformation of new phi. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp Changeset: 7523488edce5 Author: kvn Date: 2011-05-24 12:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7523488edce5 7047300: VM crashes with assert(_base == InstPtr) failed: Not an object pointer Summary: The code incorrectly used is_instptr() instead of is_oopptr() to get const_oop. Reviewed-by: never ! src/share/vm/opto/output.cpp Changeset: ccf072cdba91 Author: iveresov Date: 2011-05-24 15:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ccf072cdba91 7046893: LP64 problem with double_quadword in c1_LIRAssembler_x86.cpp Summary: Fixed invalid casts in address computation Reviewed-by: kvn, never Contributed-by: thomas.salter at unisys.com ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 28a9fe9534ea Author: kvn Date: 2011-05-24 20:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/28a9fe9534ea 7048030: is_scavengable changes causing compiler to embed more constants Summary: ciObject::can_be_constant() and should_be_constant() should use is_perm() instead of !is_scavengable() Reviewed-by: never, jrose ! src/share/vm/ci/ciObject.cpp ! src/share/vm/ci/ciObject.hpp Changeset: 7db2b9499c36 Author: never Date: 2011-05-25 16:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/7db2b9499c36 7046732: JSR 292 assert(result == cpce->f1()) failed: expected result for assembly code Reviewed-by: kvn, iveresov, jrose ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: c7c81f18c834 Author: kvn Date: 2011-05-25 21:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c7c81f18c834 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: 28263a73ebfb Author: iveresov Date: 2011-05-26 13:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/28263a73ebfb 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: 5ac411b3b8fc Author: never Date: 2011-05-26 14:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/5ac411b3b8fc 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 Changeset: c76c13577460 Author: never Date: 2011-05-26 16:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c76c13577460 Merge Changeset: b2cb497dec28 Author: kvn Date: 2011-05-27 12:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/b2cb497dec28 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 Changeset: 33e2b8f1d466 Author: kvn Date: 2011-05-31 10:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/33e2b8f1d466 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 Changeset: 60b8287df30e Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/60b8287df30e 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: a93146d0e4be Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/a93146d0e4be 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: 96c891ebe56a Author: coleenp Date: 2011-06-02 21:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/96c891ebe56a Merge ! src/share/vm/prims/methodHandleWalk.cpp From suenaga.yasumasa at oss.ntt.co.jp Mon Jun 6 04:24:08 2011 From: suenaga.yasumasa at oss.ntt.co.jp (Yasumasa Suenaga) Date: Mon, 06 Jun 2011 20:24:08 +0900 Subject: 7044285: VM crashes in server app Message-ID: <4DECB8D8.50206@oss.ntt.co.jp> Hi, Our customer's system was also crashed in the same case. I check core image, and I suspect overflow of "pDst" in "Java_sun_java2d_loops_MaskFill_MaskFill()" In order to fix this problem, I made a patch for typecasting "ptrdiff_t" in PtrCoord macro. Please merge this patch if you don't fix this problem yet. ("test.c" is not a patch. It is minimal sample of this overflow problem.) from hs_err log: ---------------------------- # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00002aabcb644177, pid=27759, tid=1142659392 # # Java VM: OpenJDK 64-Bit Server VM (1.6.0-b09 mixed mode linux-amd64) # Problematic frame: # C [libawt.so+0x63177] IntArgbSrcOverMaskFill+0x127 # # If you would like to submit a bug report, please visit: # http://icedtea.classpath.org/bugzilla # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. : : OS:Red Hat Enterprise Linux Server release 5.4 (Tikanga) uname:Linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 libc:glibc 2.5 NPTL 2.5 rlimit: STACK 10240k, CORE infinity, NPROC infinity, NOFILE 65536, AS infinity load average:1.04 0.56 0.41 CPU:total 4 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 5, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3 Memory: 4k page, physical 5830108k(39684k free), swap 4192956k(4065544k free) vm_info: OpenJDK 64-Bit Server VM (1.6.0-b09) for linux-amd64 JRE (1.6.0-b09), built on Aug 5 2009 11:16:51 by "mockbuild" with gcc 4.1.2 20080704 (Red Hat 4.1.2-44) time: Thu Jun 2 21:04:51 2011 elapsed time: 517630 seconds ---------------------------- from core image: ---------------------------- [root at RHEL5-4 T2011060009]# gdb java core.27759 : : (gdb) f 7 #7 0x00002aabcb61cd3d in Java_sun_java2d_loops_MaskFill_MaskFill (env=0x2aabcc36f598, self=, sg2d=0x441b70c8, sData=, comp=, x=50, y=26188, w=32, h=32, maskArray=0x441b7120, maskoff=0, maskscan=32) at ../../../src/share/native/sun/java2d/loops/MaskFill.c:85 85 ../../../src/share/native/sun/java2d/loops/MaskFill.c: No such file or directory. in ../../../src/share/native/sun/java2d/loops/MaskFill.c (gdb) p pDst $1 = (void *) 0x2aaa8aaea6e0 (gdb) p rasInfo $2 = {bounds = {x1 = 50, y1 = 26188, x2 = 82, y2 = 26220}, rasBase = 0x2aab0a4fc718, pixelBitOffset = 0, pixelStride = 4, scanStride = 82240, lutSize = 0, lutBase = 0x0, invColorTable = 0x0, redErrTable = 0x0, grnErrTable = 0x0, bluErrTable = 0x0, invGrayTable = 0x2aabb15d4d68, priv = {align = 0x3, data = "\003\000\000\000\000\000\000\000\030?O\n?*", '\0' , "@\000\000\000\000\000\000\000X\213P?*\000\000\001", '\0' }} ---------------------------- "pDst" is calculated in "MaskFill.c" as following: ---------------------------- void *pDst = PtrCoord(rasInfo.rasBase, rasInfo.bounds.x1, rasInfo.pixelStride, rasInfo.bounds.y1, rasInfo.scanStride); ---------------------------- "PtrCoord" is defined in "GraphicsPrimitiveMgr.h": ---------------------------- #define PtrAddBytes(p, b) ((void *) (((intptr_t) (p)) + (b))) #define PtrCoord(p, x, xinc, y, yinc) PtrAddBytes(p, (y)*(yinc) + (x)*(xinc)) ---------------------------- In this case, "b" in PtrAddBytes macro is (rasInfo.bounds.y1 * rasInfo.scanStride) + (rasInfo.bounds.x1 * rasInfo.pixelStride) = (26188 * 82240) + (50 * 4) = 2153701320 ( > INT_MAX ( 2147483647 (0x7fffffff) )) "b" sets to be -2141265976. So, "pDst" set to be as following: pDst = rasInfo.bounds.rasBase - 2141265976 = 0x2aaa8aaea6e0 pDst should set to be 0x2aab8aaea6e0, however, it set to be 0x2aaa8aaea6e0. Best regards, Yasumasa -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: test.c Url: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110606/dc23ad43/attachment.c -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 7044285.patch Url: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110606/dc23ad43/attachment.ksh From paul.hohensee at oracle.com Mon Jun 6 05:39:05 2011 From: paul.hohensee at oracle.com (Paul Hohensee) Date: Mon, 06 Jun 2011 08:39:05 -0400 Subject: 7044285: VM crashes in server app In-Reply-To: <4DECB8D8.50206@oss.ntt.co.jp> References: <4DECB8D8.50206@oss.ntt.co.jp> Message-ID: <4DECCA69.4060608@oracle.com> This doesn't look like a jvm problem, rather it's a problem in the graphics library. At least, that's where the code is. I'm not sure who's responsible for java2d these days, so I've cc'ed Andrey Pikalev (swing/awt manager) and Rich Bair (client java architect). Paul On 6/6/11 7:24 AM, Yasumasa Suenaga wrote: > Hi, > > Our customer's system was also crashed in the same case. > I check core image, and I suspect overflow of "pDst" in "Java_sun_java2d_loops_MaskFill_MaskFill()" > > In order to fix this problem, I made a patch for typecasting "ptrdiff_t" in PtrCoord macro. > > Please merge this patch if you don't fix this problem yet. > ("test.c" is not a patch. It is minimal sample of this overflow problem.) > > > from hs_err log: > ---------------------------- > # > # An unexpected error has been detected by Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00002aabcb644177, pid=27759, tid=1142659392 > # > # Java VM: OpenJDK 64-Bit Server VM (1.6.0-b09 mixed mode linux-amd64) > # Problematic frame: > # C [libawt.so+0x63177] IntArgbSrcOverMaskFill+0x127 > # > # If you would like to submit a bug report, please visit: > # http://icedtea.classpath.org/bugzilla > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > > : > : > > OS:Red Hat Enterprise Linux Server release 5.4 (Tikanga) > > uname:Linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 > libc:glibc 2.5 NPTL 2.5 > rlimit: STACK 10240k, CORE infinity, NPROC infinity, NOFILE 65536, AS infinity > load average:1.04 0.56 0.41 > > CPU:total 4 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 5, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3 > > Memory: 4k page, physical 5830108k(39684k free), swap 4192956k(4065544k free) > > vm_info: OpenJDK 64-Bit Server VM (1.6.0-b09) for linux-amd64 JRE (1.6.0-b09), built on Aug 5 2009 11:16:51 by "mockbuild" with gcc 4.1.2 20080704 (Red Hat 4.1.2-44) > > time: Thu Jun 2 21:04:51 2011 > elapsed time: 517630 seconds > ---------------------------- > > from core image: > ---------------------------- > [root at RHEL5-4 T2011060009]# gdb java core.27759 > > : > : > > (gdb) f 7 > #7 0x00002aabcb61cd3d in Java_sun_java2d_loops_MaskFill_MaskFill (env=0x2aabcc36f598, > self=, sg2d=0x441b70c8, sData=, > comp=, x=50, y=26188, w=32, h=32, maskArray=0x441b7120, > maskoff=0, maskscan=32) at ../../../src/share/native/sun/java2d/loops/MaskFill.c:85 > 85 ../../../src/share/native/sun/java2d/loops/MaskFill.c: No such file or directory. > in ../../../src/share/native/sun/java2d/loops/MaskFill.c > (gdb) p pDst > $1 = (void *) 0x2aaa8aaea6e0 > (gdb) p rasInfo > $2 = {bounds = {x1 = 50, y1 = 26188, x2 = 82, y2 = 26220}, rasBase = 0x2aab0a4fc718, > pixelBitOffset = 0, pixelStride = 4, scanStride = 82240, lutSize = 0, lutBase = 0x0, > invColorTable = 0x0, redErrTable = 0x0, grnErrTable = 0x0, bluErrTable = 0x0, > invGrayTable = 0x2aabb15d4d68, priv = {align = 0x3, > data = "\003\000\000\000\000\000\000\000\030?O\n?*", '\0' , "@\000\000\000\000\000\000\000X\213P?*\000\000\001", '\0' }} > ---------------------------- > > "pDst" is calculated in "MaskFill.c" as following: > ---------------------------- > void *pDst = PtrCoord(rasInfo.rasBase, > rasInfo.bounds.x1, rasInfo.pixelStride, > rasInfo.bounds.y1, rasInfo.scanStride); > ---------------------------- > > "PtrCoord" is defined in "GraphicsPrimitiveMgr.h": > ---------------------------- > #define PtrAddBytes(p, b) ((void *) (((intptr_t) (p)) + (b))) > #define PtrCoord(p, x, xinc, y, yinc) PtrAddBytes(p, (y)*(yinc) + (x)*(xinc)) > ---------------------------- > > In this case, "b" in PtrAddBytes macro is > > (rasInfo.bounds.y1 * rasInfo.scanStride) + (rasInfo.bounds.x1 * rasInfo.pixelStride) > = (26188 * 82240) + (50 * 4) > = 2153701320 ( > INT_MAX ( 2147483647 (0x7fffffff) )) > > "b" sets to be -2141265976. So, "pDst" set to be as following: > > pDst = rasInfo.bounds.rasBase - 2141265976 > = 0x2aaa8aaea6e0 > > > pDst should set to be 0x2aab8aaea6e0, > however, it set to be 0x2aaa8aaea6e0. > > > > Best regards, > > Yasumasa From james.melvin at oracle.com Mon Jun 6 05:51:15 2011 From: james.melvin at oracle.com (James Melvin) Date: Mon, 06 Jun 2011 08:51:15 -0400 Subject: 7044285: VM crashes in server app In-Reply-To: <4DECCA69.4060608@oracle.com> References: <4DECB8D8.50206@oss.ntt.co.jp> <4DECCA69.4060608@oracle.com> Message-ID: <4DECCD43.6040507@oracle.com> Hi Paul, Sent a note to Phil Race in Java 2D. The bug appears to be an incident report at this point and has not yet been promoted to a java2d bug. - Jim On 6/6/11 8:39 AM, Paul Hohensee wrote: > This doesn't look like a jvm problem, rather it's a problem in the graphics > library. At least, that's where the code is. I'm not sure who's responsible > for java2d these days, so I've cc'ed Andrey Pikalev (swing/awt manager) > and Rich Bair (client java architect). > > Paul > > On 6/6/11 7:24 AM, Yasumasa Suenaga wrote: >> Hi, >> >> Our customer's system was also crashed in the same case. >> I check core image, and I suspect overflow of "pDst" in "Java_sun_java2d_loops_MaskFill_MaskFill()" >> >> In order to fix this problem, I made a patch for typecasting "ptrdiff_t" in PtrCoord macro. >> >> Please merge this patch if you don't fix this problem yet. >> ("test.c" is not a patch. It is minimal sample of this overflow problem.) >> >> >> from hs_err log: >> ---------------------------- >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00002aabcb644177, pid=27759, tid=1142659392 >> # >> # Java VM: OpenJDK 64-Bit Server VM (1.6.0-b09 mixed mode linux-amd64) >> # Problematic frame: >> # C [libawt.so+0x63177] IntArgbSrcOverMaskFill+0x127 >> # >> # If you would like to submit a bug report, please visit: >> # http://icedtea.classpath.org/bugzilla >> # The crash happened outside the Java Virtual Machine in native code. >> # See problematic frame for where to report the bug. >> >> : >> : >> >> OS:Red Hat Enterprise Linux Server release 5.4 (Tikanga) >> >> uname:Linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 >> libc:glibc 2.5 NPTL 2.5 >> rlimit: STACK 10240k, CORE infinity, NPROC infinity, NOFILE 65536, AS infinity >> load average:1.04 0.56 0.41 >> >> CPU:total 4 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 5, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3 >> >> Memory: 4k page, physical 5830108k(39684k free), swap 4192956k(4065544k free) >> >> vm_info: OpenJDK 64-Bit Server VM (1.6.0-b09) for linux-amd64 JRE (1.6.0-b09), built on Aug 5 2009 11:16:51 by "mockbuild" with gcc 4.1.2 20080704 (Red Hat 4.1.2-44) >> >> time: Thu Jun 2 21:04:51 2011 >> elapsed time: 517630 seconds >> ---------------------------- >> >> from core image: >> ---------------------------- >> [root at RHEL5-4 T2011060009]# gdb java core.27759 >> >> : >> : >> >> (gdb) f 7 >> #7 0x00002aabcb61cd3d in Java_sun_java2d_loops_MaskFill_MaskFill (env=0x2aabcc36f598, >> self=, sg2d=0x441b70c8, sData=, >> comp=, x=50, y=26188, w=32, h=32, maskArray=0x441b7120, >> maskoff=0, maskscan=32) at ../../../src/share/native/sun/java2d/loops/MaskFill.c:85 >> 85 ../../../src/share/native/sun/java2d/loops/MaskFill.c: No such file or directory. >> in ../../../src/share/native/sun/java2d/loops/MaskFill.c >> (gdb) p pDst >> $1 = (void *) 0x2aaa8aaea6e0 >> (gdb) p rasInfo >> $2 = {bounds = {x1 = 50, y1 = 26188, x2 = 82, y2 = 26220}, rasBase = 0x2aab0a4fc718, >> pixelBitOffset = 0, pixelStride = 4, scanStride = 82240, lutSize = 0, lutBase = 0x0, >> invColorTable = 0x0, redErrTable = 0x0, grnErrTable = 0x0, bluErrTable = 0x0, >> invGrayTable = 0x2aabb15d4d68, priv = {align = 0x3, >> data = "\003\000\000\000\000\000\000\000\030?O\n?*", '\0', "@\000\000\000\000\000\000\000X\213P?*\000\000\001", '\0'}} >> ---------------------------- >> >> "pDst" is calculated in "MaskFill.c" as following: >> ---------------------------- >> void *pDst = PtrCoord(rasInfo.rasBase, >> rasInfo.bounds.x1, rasInfo.pixelStride, >> rasInfo.bounds.y1, rasInfo.scanStride); >> ---------------------------- >> >> "PtrCoord" is defined in "GraphicsPrimitiveMgr.h": >> ---------------------------- >> #define PtrAddBytes(p, b) ((void *) (((intptr_t) (p)) + (b))) >> #define PtrCoord(p, x, xinc, y, yinc) PtrAddBytes(p, (y)*(yinc) + (x)*(xinc)) >> ---------------------------- >> >> In this case, "b" in PtrAddBytes macro is >> >> (rasInfo.bounds.y1 * rasInfo.scanStride) + (rasInfo.bounds.x1 * rasInfo.pixelStride) >> = (26188 * 82240) + (50 * 4) >> = 2153701320 (> INT_MAX ( 2147483647 (0x7fffffff) )) >> >> "b" sets to be -2141265976. So, "pDst" set to be as following: >> >> pDst = rasInfo.bounds.rasBase - 2141265976 >> = 0x2aaa8aaea6e0 >> >> >> pDst should set to be 0x2aab8aaea6e0, >> however, it set to be 0x2aaa8aaea6e0. >> >> >> >> Best regards, >> >> Yasumasa From David.Holmes at oracle.com Mon Jun 6 05:08:14 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 06 Jun 2011 22:08:14 +1000 Subject: 7044285: VM crashes in server app In-Reply-To: <4DECB8D8.50206@oss.ntt.co.jp> References: <4DECB8D8.50206@oss.ntt.co.jp> Message-ID: <4DECC32E.7080403@oracle.com> This isn't a hotspot issue but an AWT (or rather java2d) issue. I've cc'ed the AWT folk and bcc'd hotspot. The incident report is mis-filed and I'll report that. David Holmes Yasumasa Suenaga said the following on 06/06/11 21:24: > Hi, > > Our customer's system was also crashed in the same case. > I check core image, and I suspect overflow of "pDst" in "Java_sun_java2d_loops_MaskFill_MaskFill()" > > In order to fix this problem, I made a patch for typecasting "ptrdiff_t" in PtrCoord macro. > > Please merge this patch if you don't fix this problem yet. > ("test.c" is not a patch. It is minimal sample of this overflow problem.) > > > from hs_err log: > ---------------------------- > # > # An unexpected error has been detected by Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00002aabcb644177, pid=27759, tid=1142659392 > # > # Java VM: OpenJDK 64-Bit Server VM (1.6.0-b09 mixed mode linux-amd64) > # Problematic frame: > # C [libawt.so+0x63177] IntArgbSrcOverMaskFill+0x127 > # > # If you would like to submit a bug report, please visit: > # http://icedtea.classpath.org/bugzilla > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > > : > : > > OS:Red Hat Enterprise Linux Server release 5.4 (Tikanga) > > uname:Linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 > libc:glibc 2.5 NPTL 2.5 > rlimit: STACK 10240k, CORE infinity, NPROC infinity, NOFILE 65536, AS infinity > load average:1.04 0.56 0.41 > > CPU:total 4 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 5, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3 > > Memory: 4k page, physical 5830108k(39684k free), swap 4192956k(4065544k free) > > vm_info: OpenJDK 64-Bit Server VM (1.6.0-b09) for linux-amd64 JRE (1.6.0-b09), built on Aug 5 2009 11:16:51 by "mockbuild" with gcc 4.1.2 20080704 (Red Hat 4.1.2-44) > > time: Thu Jun 2 21:04:51 2011 > elapsed time: 517630 seconds > ---------------------------- > > from core image: > ---------------------------- > [root at RHEL5-4 T2011060009]# gdb java core.27759 > > : > : > > (gdb) f 7 > #7 0x00002aabcb61cd3d in Java_sun_java2d_loops_MaskFill_MaskFill (env=0x2aabcc36f598, > self=, sg2d=0x441b70c8, sData=, > comp=, x=50, y=26188, w=32, h=32, maskArray=0x441b7120, > maskoff=0, maskscan=32) at ../../../src/share/native/sun/java2d/loops/MaskFill.c:85 > 85 ../../../src/share/native/sun/java2d/loops/MaskFill.c: No such file or directory. > in ../../../src/share/native/sun/java2d/loops/MaskFill.c > (gdb) p pDst > $1 = (void *) 0x2aaa8aaea6e0 > (gdb) p rasInfo > $2 = {bounds = {x1 = 50, y1 = 26188, x2 = 82, y2 = 26220}, rasBase = 0x2aab0a4fc718, > pixelBitOffset = 0, pixelStride = 4, scanStride = 82240, lutSize = 0, lutBase = 0x0, > invColorTable = 0x0, redErrTable = 0x0, grnErrTable = 0x0, bluErrTable = 0x0, > invGrayTable = 0x2aabb15d4d68, priv = {align = 0x3, > data = "\003\000\000\000\000\000\000\000\030?O\n?*", '\0' , "@\000\000\000\000\000\000\000X\213P?*\000\000\001", '\0' }} > ---------------------------- > > "pDst" is calculated in "MaskFill.c" as following: > ---------------------------- > void *pDst = PtrCoord(rasInfo.rasBase, > rasInfo.bounds.x1, rasInfo.pixelStride, > rasInfo.bounds.y1, rasInfo.scanStride); > ---------------------------- > > "PtrCoord" is defined in "GraphicsPrimitiveMgr.h": > ---------------------------- > #define PtrAddBytes(p, b) ((void *) (((intptr_t) (p)) + (b))) > #define PtrCoord(p, x, xinc, y, yinc) PtrAddBytes(p, (y)*(yinc) + (x)*(xinc)) > ---------------------------- > > In this case, "b" in PtrAddBytes macro is > > (rasInfo.bounds.y1 * rasInfo.scanStride) + (rasInfo.bounds.x1 * rasInfo.pixelStride) > = (26188 * 82240) + (50 * 4) > = 2153701320 ( > INT_MAX ( 2147483647 (0x7fffffff) )) > > "b" sets to be -2141265976. So, "pDst" set to be as following: > > pDst = rasInfo.bounds.rasBase - 2141265976 > = 0x2aaa8aaea6e0 > > > pDst should set to be 0x2aab8aaea6e0, > however, it set to be 0x2aaa8aaea6e0. > > > > Best regards, > > Yasumasa > From suenaga.yasumasa at oss.ntt.co.jp Mon Jun 6 17:14:25 2011 From: suenaga.yasumasa at oss.ntt.co.jp (Yasumasa Suenaga) Date: Tue, 07 Jun 2011 09:14:25 +0900 Subject: 7044285: VM crashes in server app In-Reply-To: <4DECCA69.4060608@oracle.com> References: <4DECB8D8.50206@oss.ntt.co.jp> <4DECCA69.4060608@oracle.com> Message-ID: <4DED6D61.1010400@oss.ntt.co.jp> Hi, everyone, Thank you for replying, and sorry for submitting to incorrect ML. I hope to fix this problem soon. So, I would like your cooperation. Thanks, Yasumasa (2011/06/06 21:39), Paul Hohensee wrote: > This doesn't look like a jvm problem, rather it's a problem in the graphics > library. At least, that's where the code is. I'm not sure who's responsible > for java2d these days, so I've cc'ed Andrey Pikalev (swing/awt manager) > and Rich Bair (client java architect). > > Paul > > On 6/6/11 7:24 AM, Yasumasa Suenaga wrote: >> Hi, >> >> Our customer's system was also crashed in the same case. >> I check core image, and I suspect overflow of "pDst" in "Java_sun_java2d_loops_MaskFill_MaskFill()" >> >> In order to fix this problem, I made a patch for typecasting "ptrdiff_t" in PtrCoord macro. >> >> Please merge this patch if you don't fix this problem yet. >> ("test.c" is not a patch. It is minimal sample of this overflow problem.) >> >> >> from hs_err log: >> ---------------------------- >> # >> # An unexpected error has been detected by Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00002aabcb644177, pid=27759, tid=1142659392 >> # >> # Java VM: OpenJDK 64-Bit Server VM (1.6.0-b09 mixed mode linux-amd64) >> # Problematic frame: >> # C [libawt.so+0x63177] IntArgbSrcOverMaskFill+0x127 >> # >> # If you would like to submit a bug report, please visit: >> # http://icedtea.classpath.org/bugzilla >> # The crash happened outside the Java Virtual Machine in native code. >> # See problematic frame for where to report the bug. >> >> : >> : >> >> OS:Red Hat Enterprise Linux Server release 5.4 (Tikanga) >> >> uname:Linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 >> libc:glibc 2.5 NPTL 2.5 >> rlimit: STACK 10240k, CORE infinity, NPROC infinity, NOFILE 65536, AS infinity >> load average:1.04 0.56 0.41 >> >> CPU:total 4 (1 cores per cpu, 1 threads per core) family 6 model 10 stepping 5, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3 >> >> Memory: 4k page, physical 5830108k(39684k free), swap 4192956k(4065544k free) >> >> vm_info: OpenJDK 64-Bit Server VM (1.6.0-b09) for linux-amd64 JRE (1.6.0-b09), built on Aug 5 2009 11:16:51 by "mockbuild" with gcc 4.1.2 20080704 (Red Hat 4.1.2-44) >> >> time: Thu Jun 2 21:04:51 2011 >> elapsed time: 517630 seconds >> ---------------------------- >> >> from core image: >> ---------------------------- >> [root at RHEL5-4 T2011060009]# gdb java core.27759 >> >> : >> : >> >> (gdb) f 7 >> #7 0x00002aabcb61cd3d in Java_sun_java2d_loops_MaskFill_MaskFill (env=0x2aabcc36f598, >> self=, sg2d=0x441b70c8, sData=, >> comp=, x=50, y=26188, w=32, h=32, maskArray=0x441b7120, >> maskoff=0, maskscan=32) at ../../../src/share/native/sun/java2d/loops/MaskFill.c:85 >> 85 ../../../src/share/native/sun/java2d/loops/MaskFill.c: No such file or directory. >> in ../../../src/share/native/sun/java2d/loops/MaskFill.c >> (gdb) p pDst >> $1 = (void *) 0x2aaa8aaea6e0 >> (gdb) p rasInfo >> $2 = {bounds = {x1 = 50, y1 = 26188, x2 = 82, y2 = 26220}, rasBase = 0x2aab0a4fc718, >> pixelBitOffset = 0, pixelStride = 4, scanStride = 82240, lutSize = 0, lutBase = 0x0, >> invColorTable = 0x0, redErrTable = 0x0, grnErrTable = 0x0, bluErrTable = 0x0, >> invGrayTable = 0x2aabb15d4d68, priv = {align = 0x3, >> data = "\003\000\000\000\000\000\000\000\030?O\n?*", '\0', "@\000\000\000\000\000\000\000X\213P?*\000\000\001", '\0'}} >> ---------------------------- >> >> "pDst" is calculated in "MaskFill.c" as following: >> ---------------------------- >> void *pDst = PtrCoord(rasInfo.rasBase, >> rasInfo.bounds.x1, rasInfo.pixelStride, >> rasInfo.bounds.y1, rasInfo.scanStride); >> ---------------------------- >> >> "PtrCoord" is defined in "GraphicsPrimitiveMgr.h": >> ---------------------------- >> #define PtrAddBytes(p, b) ((void *) (((intptr_t) (p)) + (b))) >> #define PtrCoord(p, x, xinc, y, yinc) PtrAddBytes(p, (y)*(yinc) + (x)*(xinc)) >> ---------------------------- >> >> In this case, "b" in PtrAddBytes macro is >> >> (rasInfo.bounds.y1 * rasInfo.scanStride) + (rasInfo.bounds.x1 * rasInfo.pixelStride) >> = (26188 * 82240) + (50 * 4) >> = 2153701320 (> INT_MAX ( 2147483647 (0x7fffffff) )) >> >> "b" sets to be -2141265976. So, "pDst" set to be as following: >> >> pDst = rasInfo.bounds.rasBase - 2141265976 >> = 0x2aaa8aaea6e0 >> >> >> pDst should set to be 0x2aab8aaea6e0, >> however, it set to be 0x2aaa8aaea6e0. >> >> >> >> Best regards, >> >> Yasumasa From dmitriy.samersoff at oracle.com Wed Jun 8 16:47:21 2011 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Wed, 08 Jun 2011 23:47:21 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 3 new changesets Message-ID: <20110608234729.02FEC47D21@hg.openjdk.java.net> Changeset: 537a4053b0f9 Author: ysr Date: 2011-05-23 16:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/hotspot/rev/f153114134c8 Merge Changeset: 20cac004a4f9 Author: dsamersoff Date: 2011-06-09 01:06 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/20cac004a4f9 Merge From dmitriy.samersoff at oracle.com Thu Jun 9 16:45:27 2011 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Thu, 09 Jun 2011 23:45:27 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 35 new changesets Message-ID: <20110609234632.0130D47DF3@hg.openjdk.java.net> Changeset: 789d04408ca3 Author: kvn Date: 2011-05-21 11:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/789d04408ca3 7045693: java/util/EnumSet/EnumSetBash.java still failing intermittently Summary: New limit for unrolled loop should be set only for zero trip guard and loop iteration test. Reviewed-by: never ! src/share/vm/opto/loopTransform.cpp Changeset: b55f5bd7ec66 Author: kvn Date: 2011-05-21 13:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b55f5bd7ec66 7045506: assert(!can_reshape || !new_phi) failed: for igvn new phi should be hooked Summary: Replace the assert in PhiNode::Ideal with check to avoid transformation of new phi. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp Changeset: 7523488edce5 Author: kvn Date: 2011-05-24 12:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7523488edce5 7047300: VM crashes with assert(_base == InstPtr) failed: Not an object pointer Summary: The code incorrectly used is_instptr() instead of is_oopptr() to get const_oop. Reviewed-by: never ! src/share/vm/opto/output.cpp Changeset: ccf072cdba91 Author: iveresov Date: 2011-05-24 15:30 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/ccf072cdba91 7046893: LP64 problem with double_quadword in c1_LIRAssembler_x86.cpp Summary: Fixed invalid casts in address computation Reviewed-by: kvn, never Contributed-by: thomas.salter at unisys.com ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 28a9fe9534ea Author: kvn Date: 2011-05-24 20:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/28a9fe9534ea 7048030: is_scavengable changes causing compiler to embed more constants Summary: ciObject::can_be_constant() and should_be_constant() should use is_perm() instead of !is_scavengable() Reviewed-by: never, jrose ! src/share/vm/ci/ciObject.cpp ! src/share/vm/ci/ciObject.hpp Changeset: 7db2b9499c36 Author: never Date: 2011-05-25 16:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7db2b9499c36 7046732: JSR 292 assert(result == cpce->f1()) failed: expected result for assembly code Reviewed-by: kvn, iveresov, jrose ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: 2d4b2b833d29 Author: coleenp Date: 2011-05-27 15:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/2d4b2b833d29 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: 8cbcd406c42e Author: ysr Date: 2011-05-27 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8cbcd406c42e 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: d9dc0a55c848 Author: schien Date: 2011-05-20 16:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d9dc0a55c848 Added tag jdk7-b143 for changeset c149193c768b ! .hgtags Changeset: 278445be9145 Author: trims Date: 2011-05-24 14:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/278445be9145 Added tag hs21-b13 for changeset c149193c768b ! .hgtags Changeset: 01e01c25d24a Author: trims Date: 2011-05-24 14:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/01e01c25d24a Merge ! .hgtags Changeset: fe189d4a44e9 Author: katleman Date: 2011-05-25 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/fe189d4a44e9 7044486: open jdk repos have files with incorrect copyright headers, which can end up in src bundles Reviewed-by: ohair, trims ! agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java ! make/linux/README ! make/windows/projectfiles/kernel/Makefile ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.s ! src/share/tools/hsdis/README ! src/share/vm/gc_implementation/g1/heapRegionSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionSets.hpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/utilities/yieldingWorkgroup.cpp Changeset: d920485ae93b Author: schien Date: 2011-05-26 20:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/d920485ae93b Added tag jdk7-b144 for changeset fe189d4a44e9 ! .hgtags Changeset: b36598cf2c62 Author: jcoomes Date: 2011-05-27 23:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b36598cf2c62 Merge Changeset: 472fc37e14a9 Author: jcoomes Date: 2011-05-27 23:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/472fc37e14a9 7049385: Bump the HS21 build number to 15 Summary: Update the HS21 build number to 15 Reviewed-by: trims ! make/hotspot_version Changeset: 9340a27154cb Author: kvn Date: 2011-05-25 21:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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 Changeset: 88559690c95a Author: never Date: 2011-05-26 14:44 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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 Changeset: 442ef93966a9 Author: iveresov Date: 2011-05-26 13:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/hotspot/rev/3f7a95be91ef Merge Changeset: 7c907a50c1bb Author: iveresov Date: 2011-06-01 14:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7c907a50c1bb Merge Changeset: f88fb2fa90cf Author: kvn Date: 2011-05-31 10:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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 Changeset: ba550512d3b2 Author: jrose Date: 2011-06-01 23:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/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-rt/hotspot/rev/e5ae807761b8 Added tag hs21-b14 for changeset 62f39d40ebf1 ! .hgtags Changeset: f56542cb325a Author: never Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/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 Changeset: 1aa57c62d0e4 Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/hotspot/rev/63d3fb179034 Merge Changeset: 82a81d5c5700 Author: trims Date: 2011-06-03 20:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/82a81d5c5700 Merge Changeset: 48ceeec759b6 Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/hotspot/rev/67c0f5f5deac Merge From john.coomes at oracle.com Thu Jun 9 20:47:25 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jun 2011 03:47:25 +0000 Subject: hg: jdk7/hotspot-rt: 3 new changesets Message-ID: <20110610034725.A27E347E32@hg.openjdk.java.net> Changeset: 93d2590fd849 Author: jeff Date: 2011-05-27 14:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/rev/55e9ebf03218 Merge Changeset: 2d38c2a79c14 Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/2d38c2a79c14 Added tag jdk7-b145 for changeset 55e9ebf03218 ! .hgtags From john.coomes at oracle.com Thu Jun 9 20:47:35 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jun 2011 03:47:35 +0000 Subject: hg: jdk7/hotspot-rt/corba: 5 new changesets Message-ID: <20110610034741.6D05B47E35@hg.openjdk.java.net> Changeset: 93e77c49b3bb Author: miroslawzn Date: 2011-05-26 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/corba/rev/7839048ec99e Merge Changeset: 77ec0541aa2a Author: lana Date: 2011-06-02 13:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/77ec0541aa2a Merge Changeset: 770227a4087e Author: schien Date: 2011-06-07 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/770227a4087e Added tag jdk7-b145 for changeset 77ec0541aa2a ! .hgtags From john.coomes at oracle.com Thu Jun 9 20:47:53 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jun 2011 03:47:53 +0000 Subject: hg: jdk7/hotspot-rt/jaxp: 5 new changesets Message-ID: <20110610034754.0068047E38@hg.openjdk.java.net> Changeset: bdf77cbd9958 Author: ohair Date: 2011-05-19 08:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/jaxp/rev/775dd77e4730 Merge Changeset: a70a042c8600 Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/jaxp/rev/10ca7570f47f Merge Changeset: bcd31fa1e3c6 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/bcd31fa1e3c6 Added tag jdk7-b145 for changeset 10ca7570f47f ! .hgtags From john.coomes at oracle.com Thu Jun 9 20:48:03 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jun 2011 03:48:03 +0000 Subject: hg: jdk7/hotspot-rt/jaxws: 4 new changesets Message-ID: <20110610034803.7D27347E3B@hg.openjdk.java.net> Changeset: c902e39c384e Author: jeff Date: 2011-05-27 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/jaxws/rev/42bfba80beb7 Merge Changeset: 6ec12c60ad13 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/6ec12c60ad13 Added tag jdk7-b145 for changeset 42bfba80beb7 ! .hgtags From john.coomes at oracle.com Thu Jun 9 20:49:02 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 10 Jun 2011 03:49:02 +0000 Subject: hg: jdk7/hotspot-rt/jdk: 42 new changesets Message-ID: <20110610035659.F358747E45@hg.openjdk.java.net> Changeset: f09930d526ba Author: jrose Date: 2011-05-26 17:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/f09930d526ba 7032323: code changes for JSR 292 EG adjustments to API, through Public Review Summary: API code changes and javadoc changes following JSR 292 Public Review comments, through PFD Reviewed-by: never ! src/share/classes/java/lang/BootstrapMethodError.java ! src/share/classes/java/lang/ClassValue.java ! src/share/classes/java/lang/invoke/AdapterMethodHandle.java ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/ConstantCallSite.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/java/lang/invoke/MethodType.java ! src/share/classes/java/lang/invoke/MutableCallSite.java ! src/share/classes/java/lang/invoke/SwitchPoint.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/sun/invoke/util/ValueConversions.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/Wrapper.java ! test/java/lang/invoke/6998541/Test6998541.java ! test/java/lang/invoke/InvokeDynamicPrintArgs.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/indify/Indify.java Changeset: 81f957f86ba5 Author: jcoomes Date: 2011-05-27 19:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/81f957f86ba5 Merge Changeset: 8318d03e1766 Author: jrose Date: 2011-06-01 23:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/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-rt/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 Changeset: bc97b962330e Author: mfang Date: 2011-05-26 20:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/jdk/rev/6943c4d9caa3 Merge Changeset: 7c5bc5a807ee Author: dholmes Date: 2011-05-27 19:04 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/jdk/rev/f4895b3fe1be Merge Changeset: eab27338b3d9 Author: schien Date: 2011-06-01 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/eab27338b3d9 Merge Changeset: 8d91855a1f4e Author: prr Date: 2011-05-27 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/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-rt/jdk/rev/b351af09bfa3 Merge Changeset: d2081a1f417f Author: bagiras Date: 2011-05-27 11:45 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/b955226868af Merge Changeset: 1fbaf2b688a6 Author: rupashka Date: 2011-05-24 11:37 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/jdk/rev/386516fdf40b Merge Changeset: 0a80650409e1 Author: mullan Date: 2011-05-24 14:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/jdk/rev/ace2dfdecda1 Merge Changeset: 70942be348af Author: jeff Date: 2011-05-27 15:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/39de8937c1d8 Merge Changeset: e8e6cdff5995 Author: trims Date: 2011-06-03 20:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e8e6cdff5995 Merge Changeset: 8f19b165347b Author: bae Date: 2011-06-04 23:08 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/jdk/rev/bbb4cef2208b Merge Changeset: 03a828e368ca Author: rupashka Date: 2011-06-04 01:13 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/jdk/rev/6c9c55ae313b Merge Changeset: e81d259442ed Author: lana Date: 2011-06-04 17:32 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/e81d259442ed Merge Changeset: 53d759eb580c Author: alanb Date: 2011-06-04 11:18 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/jdk/rev/1f39ca0b9598 Merge Changeset: 1e04b38b3824 Author: lana Date: 2011-06-04 17:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/1e04b38b3824 Merge Changeset: 7a341c412ea9 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7a341c412ea9 Added tag jdk7-b145 for changeset 1e04b38b3824 ! .hgtags From wonderer_101 at live.com Fri Jun 10 10:58:08 2011 From: wonderer_101 at live.com (Lee Ming) Date: Sat, 11 Jun 2011 01:58:08 +0800 Subject: JVMTI VMObjectAlloc Message-ID: Hi, I'm doing some test with JVMTI VMObjectAlloc, and it seems like the callback cant catch object allocation properly .e.g: regardless how I tried to allocate new objects in Java program, the agent still report the same number of objects allocated. This is the source code of the callback char *generic_name; jvmtiThreadInfo info; jvmtiError error; (void)memset(&info, 0, sizeof(info)); error = (*jvmti)->GetClassSignature(jvmti, object_klass,&generic_name,NULL); check_jvmti_error(jvmti, error, "can't get class name"); //printf(generic_name); gdata->object_size = gdata->object_size + size; gdata->ccount++; stdout_message("%d.Object allocated, class: %s\tsize:%d\n",gdata->ccount,generic_name,size); printf("total size now is: %I64d\n",gdata->object_size); error = (*jvmti)->GetThreadInfo(jvmti,thread, &info); check_jvmti_error(jvmti, error, "can't get thread info"); printf("thread name:%s\n",info.name); (*jvmti)->Deallocate(jvmti, (unsigned char *) info.name); (*env)->DeleteLocalRef(env, info.thread_group); (*env)->DeleteLocalRef(env, info.context_class_loader); And the sample Java test file public class Test { public static void main(String[] args){ for(int i=0; i<10000;i++){ Hello h1 = new Hello(1,2); Hello h2 = new Hello(3,4444); Hello h3 = new Hello(3,44); h1.w(); h2.w(); h3.w(); //System.out.println("alloc"); } } } Please let's me know whether i have made any mistake Thank you Bhm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110611/51aca482/attachment.html From coleen.phillimore at oracle.com Fri Jun 10 11:16:11 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 10 Jun 2011 14:16:11 -0400 Subject: openjdk/hsx/hotpot-rt/hotspot repository is unlocked for new work Message-ID: <4DF25F6B.5040700@oracle.com> thanks for your cooperation! Coleen From keith.mcguigan at oracle.com Fri Jun 10 11:28:25 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Fri, 10 Jun 2011 14:28:25 -0400 Subject: JVMTI VMObjectAlloc In-Reply-To: References: Message-ID: <06413E3D-CEFD-455B-954C-5A7C1D1E7AE7@oracle.com> Forwarding to serviceability-dev (and Bcc'ing hotspot-runtime-dev off). I personally don't see anything obviously wrong in the code you sent but it looks like you've only sent a small fragment of the code and the problem could well be somewhere else. What is the output, and what do you expect? Does it count 6, 600, or 6000, 60000 or what? Is it even close? What happens when you change the number of iterations in the java program? Are you seeing any other threads calling allocation, and if so are you implementing the proper locking for your gdata? -- - Keith On Jun 10, 2011, at 1:58 PM, Lee Ming wrote: > Hi, > I'm doing some test with JVMTI VMObjectAlloc, and it seems like the > callback cant catch object allocation properly .e.g: regardless how > I tried to allocate new objects in Java program, the agent still > report the same number of objects allocated. > > This is the source code of the callback > > char *generic_name; > jvmtiThreadInfo info; > jvmtiError error; > > (void)memset(&info, 0, sizeof(info)); > > error = (*jvmti)->GetClassSignature(jvmti, > object_klass,&generic_name,NULL); > check_jvmti_error(jvmti, error, "can't get class name"); > //printf(generic_name); > > gdata->object_size = gdata->object_size + size; > gdata->ccount++; > > stdout_message("%d.Object allocated, class: %s\tsize:%d\n",gdata- > >ccount,gener! ic_name,size); > printf("total size now is: %I64d\n",gdata->object_size); > > > error = (*jvmti)->GetThreadInfo(jvmti,thread, &info); > check_jvmti_error(jvmti, error, "can't get thread info"); > printf("thread name:%s\n",info.name); > (*jvmti)->Deallocate(jvmti, (unsigned char *) info.name); > (*env)->DeleteLocalRef(env, info.thread_group); > (*env)->DeleteLocalRef(env, info.context_class_loader); > > And the sample Java test file > public class Test { > > public static void main(String[] args){ > > for(int i=0; i<10000;i++){ > &nbs! p; &n bsp; Hello h1 = new Hello(1,2); > Hello h2 = new Hello(3,4444); > Hello h3 = new Hello(3,44); > h1.w(); > h2.w(); > h3.w(); > //System.ou! t.println("alloc"); > } > > } > > } > > Please let's me know whether i have made any mistake > > Thank you > Bhm From john.coomes at oracle.com Fri Jun 10 17:22:19 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Sat, 11 Jun 2011 00:22:19 +0000 Subject: hg: jdk7/hotspot-rt/langtools: 5 new changesets Message-ID: <20110611002236.1B60047EFA@hg.openjdk.java.net> Changeset: 6bb526ccf5ff Author: mcimadamore Date: 2011-05-23 11:55 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/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-rt/langtools/rev/c455e2ae5c93 Merge Changeset: 9ff91d0e7154 Author: schien Date: 2011-06-07 14:01 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/langtools/rev/9ff91d0e7154 Added tag jdk7-b145 for changeset c455e2ae5c93 ! .hgtags From bengt.rutisson at oracle.com Mon Jun 13 13:45:06 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Mon, 13 Jun 2011 22:45:06 +0200 Subject: Review request: 6918185 Remove unused code for lost card-marking optimization in BacktraceBuilder (S) Message-ID: <4DF676D2.1020400@oracle.com> Hi Runtime and GC teams, Could I have a couple of reviews for this simple change to remove some dead code? I am sending this request to both the runtime and GC teams, since it is a change in runtime code but I will be pushing it through hotspot-gc. I discussed this with Ramki and Coleen. This is not an optimization that will be implemented any time soon and Coleen was intending to close the CR as WNF at some point. However, there is some dead code left from the orginal fix, so I re-purposed the CR to remove this dead code. Webrev: http://cr.openjdk.java.net/~brutisso/CR6918185-b/webrev.0/ CR: 6918185 Remove unused code for lost card-marking optimization in BacktraceBuilder http://monaco.sfbay.sun.com/detail.jsf?cr=6918185 Thanks, Bengt From David.Holmes at oracle.com Mon Jun 13 15:51:05 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 14 Jun 2011 08:51:05 +1000 Subject: Review request: 6918185 Remove unused code for lost card-marking optimization in BacktraceBuilder (S) In-Reply-To: <4DF676D2.1020400@oracle.com> References: <4DF676D2.1020400@oracle.com> Message-ID: <4DF69459.90801@oracle.com> Hi Bengt, Looks okay to me. David Bengt Rutisson said the following on 06/14/11 06:45: > > Hi Runtime and GC teams, > > Could I have a couple of reviews for this simple change to remove some > dead code? > > I am sending this request to both the runtime and GC teams, since it is > a change in runtime code but I will be pushing it through hotspot-gc. > > I discussed this with Ramki and Coleen. This is not an optimization that > will be implemented any time soon and Coleen was intending to close the > CR as WNF at some point. However, there is some dead code left from the > orginal fix, so I re-purposed the CR to remove this dead code. > > Webrev: > http://cr.openjdk.java.net/~brutisso/CR6918185-b/webrev.0/ > > CR: > 6918185 Remove unused code for lost card-marking optimization in > BacktraceBuilder > http://monaco.sfbay.sun.com/detail.jsf?cr=6918185 > > Thanks, > Bengt > From y.s.ramakrishna at oracle.com Mon Jun 13 16:04:40 2011 From: y.s.ramakrishna at oracle.com (Y. Srinivas Ramakrishna) Date: Mon, 13 Jun 2011 16:04:40 -0700 Subject: Review request: 6918185 Remove unused code for lost card-marking optimization in BacktraceBuilder (S) In-Reply-To: <4DF676D2.1020400@oracle.com> References: <4DF676D2.1020400@oracle.com> Message-ID: <4DF69788.4090306@oracle.com> Looks good. -- ramki On 6/13/2011 1:45 PM, Bengt Rutisson wrote: > > Hi Runtime and GC teams, > > Could I have a couple of reviews for this simple change to remove some dead code? > > I am sending this request to both the runtime and GC teams, since it is a change in runtime code but > I will be pushing it through hotspot-gc. > > I discussed this with Ramki and Coleen. This is not an optimization that will be implemented any > time soon and Coleen was intending to close the CR as WNF at some point. However, there is some dead > code left from the orginal fix, so I re-purposed the CR to remove this dead code. > > Webrev: > http://cr.openjdk.java.net/~brutisso/CR6918185-b/webrev.0/ > > CR: > 6918185 Remove unused code for lost card-marking optimization in BacktraceBuilder > http://monaco.sfbay.sun.com/detail.jsf?cr=6918185 > > Thanks, > Bengt > From coleen.phillimore at oracle.com Mon Jun 13 16:51:49 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 13 Jun 2011 19:51:49 -0400 Subject: Review request: 6918185 Remove unused code for lost card-marking optimization in BacktraceBuilder (S) In-Reply-To: <4DF676D2.1020400@oracle.com> References: <4DF676D2.1020400@oracle.com> Message-ID: <4DF6A295.1090600@oracle.com> Looks good. Thanks for doing this cleanup! Coleen On 6/13/2011 4:45 PM, Bengt Rutisson wrote: > > Hi Runtime and GC teams, > > Could I have a couple of reviews for this simple change to remove some > dead code? > > I am sending this request to both the runtime and GC teams, since it > is a change in runtime code but I will be pushing it through hotspot-gc. > > I discussed this with Ramki and Coleen. This is not an optimization > that will be implemented any time soon and Coleen was intending to > close the CR as WNF at some point. However, there is some dead code > left from the orginal fix, so I re-purposed the CR to remove this dead > code. > > Webrev: > http://cr.openjdk.java.net/~brutisso/CR6918185-b/webrev.0/ > > CR: > 6918185 Remove unused code for lost card-marking optimization in > BacktraceBuilder > http://monaco.sfbay.sun.com/detail.jsf?cr=6918185 > > Thanks, > Bengt > From bengt.rutisson at oracle.com Tue Jun 14 00:21:12 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 14 Jun 2011 09:21:12 +0200 Subject: Review request: 6918185 Remove unused code for lost card-marking optimization in BacktraceBuilder (S) In-Reply-To: <4DF6A295.1090600@oracle.com> References: <4DF676D2.1020400@oracle.com> <4DF6A295.1090600@oracle.com> Message-ID: <4DF70BE8.2080706@oracle.com> David, Ramki and Coleen, Thanks for your reviews. I'm all set to push this now. Bengt On 2011-06-14 01:51, Coleen Phillimore wrote: > Looks good. Thanks for doing this cleanup! > Coleen > > On 6/13/2011 4:45 PM, Bengt Rutisson wrote: >> >> Hi Runtime and GC teams, >> >> Could I have a couple of reviews for this simple change to remove >> some dead code? >> >> I am sending this request to both the runtime and GC teams, since it >> is a change in runtime code but I will be pushing it through hotspot-gc. >> >> I discussed this with Ramki and Coleen. This is not an optimization >> that will be implemented any time soon and Coleen was intending to >> close the CR as WNF at some point. However, there is some dead code >> left from the orginal fix, so I re-purposed the CR to remove this >> dead code. >> >> Webrev: >> http://cr.openjdk.java.net/~brutisso/CR6918185-b/webrev.0/ >> >> CR: >> 6918185 Remove unused code for lost card-marking optimization in >> BacktraceBuilder >> http://monaco.sfbay.sun.com/detail.jsf?cr=6918185 >> >> Thanks, >> Bengt >> From antcrawlerster at gmail.com Tue Jun 14 08:45:34 2011 From: antcrawlerster at gmail.com (wei he) Date: Tue, 14 Jun 2011 23:45:34 +0800 Subject: where is the code for recursive locking of the same thread when use biased locking. Message-ID: dear all, this is my first post, so if there are something wrong, pls to point out. As for biased locking, we know that when one thread has got an object's lock use biased pattern, when the thread want to got the lock again(the thread don't relase the lock at that time), hotspot just to find the thread has already owned the lock and do nothing( at least not change the object's header), could anyone told me where i can find the code to deal with this recursive locking situation. I had read synchronize.hpp(cpp),biasedLocking.hpp(cpp), but find nothing, i think the fast_enter() function in the synchronize.cpp didn't deal this case(The openjdk's version i got is openjdk-7-ea-src-b136-31_mar_2011). Any suggestion is appreciated! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110614/16fcc2a2/attachment.html From yumin.qi at oracle.com Wed Jun 15 12:03:57 2011 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Wed, 15 Jun 2011 12:03:57 -0700 Subject: where is the code for recursive locking of the same thread when use biased locking. In-Reply-To: References: Message-ID: <4DF9021D.9060804@oracle.com> Wei, The code is in Assembler part(platform dependent part), if you follow monitorenter->lock_object->biased_locking_enter, you will find it. If the thread which owns the lock with biased pattern, it will not enter fast_enter/slow_enter. Hope this helps. --Yumin On 6/14/2011 8:45 AM, wei he wrote: > dear all, this is my first post, so if there are something wrong, pls > to point out. > > As for biased locking, we know that when one thread has got an > object's lock use biased pattern, when the thread want to got the lock > again(the thread don't relase the lock at that time), hotspot just to > find the thread has already owned the lock and do nothing( at least > not change the object's header), could anyone told me where i can find > the code to deal with this recursive locking situation. I had read > synchronize.hpp(cpp),biasedLocking.hpp(cpp), but find nothing, i think > the fast_enter() function in the synchronize.cpp didn't deal this > case(The openjdk's version i got is > openjdk-7-ea-src-b136-31_mar_2011). Any suggestion is appreciated! From antcrawlerster at gmail.com Thu Jun 16 08:07:31 2011 From: antcrawlerster at gmail.com (wei he) Date: Thu, 16 Jun 2011 23:07:31 +0800 Subject: How does the openjdk deal with stack lock's recursive exit Message-ID: hi, I read the synchronizer.cpp of the openjdk, and find it when use stack lock, if the current thred recursive enter the stack lock, the stack lock's displace header will be set null, and when the current thread want to release the stack lock(i think by call the function slow_exit, which intrun call the fast_exit), but i find that in the fast exit, when hotspot find that stack lock's displace header is null, it will donothing, just return. so my question is if this thread has recursive exit this stack lock completely, and evry time the fast_exit function do nothing except find the lock's displace header is null, how can this lock's state return to be neutral? by the way, the code i read is openjdk-7-ea-src-b136-31_mar_2011. Any suggestion is appreciated, thks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110616/5ed2e920/attachment.html From David.Holmes at oracle.com Thu Jun 16 19:06:02 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 17 Jun 2011 12:06:02 +1000 Subject: How does the openjdk deal with stack lock's recursive exit In-Reply-To: References: Message-ID: <4DFAB68A.7000904@oracle.com> The synchronization code is rather complicated in its entirety but basically: - when you first lock a monitor you will get a BasicLock with a non-null displaced header - subsequent recursive locks create BasicLocks with null displaced headers A chain of BasicLock objects is formed (in the simplest case implicitly by the frames in the call chain). An unlock processes the BasicLock at the end of the chain (the most recent lock action). If the displaced header is null it was a recursive lock and there is nothing to do. Eventually an unlock must find a BasicLock where the displaced header is not null, and that is when the actual unlock occurs. Hope that makes things clearer. This is an extremely complicated part of the VM. Cheers, David Holmes wei he said the following on 06/17/11 01:07: > hi, > I read the synchronizer.cpp of the openjdk, and find it when use stack > lock, if the current thred recursive enter the stack lock, the stack > lock's displace header will be set null, and when the current thread > want to release the stack lock(i think by call the function slow_exit, > which intrun call the fast_exit), but i find that in the fast exit, when > hotspot find that stack lock's displace header is null, it will > donothing, just return. so my question is if this thread has recursive > exit this stack lock completely, and evry time the fast_exit function do > nothing except find the lock's displace header is null, how can this > lock's state return to be neutral? by the way, the code i read is > openjdk-7-ea-src-b136-31_mar_2011. > > Any suggestion is appreciated, thks. From dmitriy.samersoff at oracle.com Sat Jun 18 04:22:32 2011 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Sat, 18 Jun 2011 11:22:32 +0000 Subject: hg: jdk7/hotspot-rt/hotspot: 24 new changesets Message-ID: <20110618112314.8CFF347103@hg.openjdk.java.net> Changeset: 07c2e7ffd1fc Author: jrose Date: 2011-06-08 17:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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 Changeset: 12537a93a848 Author: asaha Date: 2011-04-08 21:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/12537a93a848 Merge Changeset: 540930dc854d Author: kamg Date: 2011-04-12 16:42 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/hotspot/rev/f0914807c671 Merge Changeset: bad27cd3f646 Author: asaha Date: 2011-04-21 08:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/bad27cd3f646 Merge Changeset: 5e00ed79c8bb Author: asaha Date: 2011-04-21 16:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/5e00ed79c8bb Merge Changeset: c97b08c7d72a Author: asaha Date: 2011-04-21 22:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/c97b08c7d72a Merge Changeset: 5def270bc147 Author: zgu Date: 2011-04-15 09:34 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/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-rt/hotspot/rev/66c17ec20ee2 Merge Changeset: 7c948af3e651 Author: asaha Date: 2011-05-24 11:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/hotspot/rev/ec7055a259a6 Merge Changeset: 8d5208b557b3 Author: asaha Date: 2011-05-26 21:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8d5208b557b3 Merge Changeset: 7bf54248da9f Author: asaha Date: 2011-06-06 10:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/7bf54248da9f Merge Changeset: a983caeb2b3e Author: asaha Date: 2011-06-03 07:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/a983caeb2b3e Merge Changeset: 0e9653efc6ea Author: asaha Date: 2011-06-06 10:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/0e9653efc6ea Merge Changeset: a884a8b0ec6d Author: asaha Date: 2011-06-15 14:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/hotspot/rev/9d7c66d9a203 Merge Changeset: 15e7628f9e92 Author: trims Date: 2011-06-16 19:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/15e7628f9e92 Merge Changeset: fc043ce2136c Author: trims Date: 2011-06-16 19:26 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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 Changeset: a9b8b43b115f Author: never Date: 2011-06-14 14:41 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/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 dmitriy.samersoff at oracle.com Sat Jun 18 06:27:11 2011 From: dmitriy.samersoff at oracle.com (dmitriy.samersoff at oracle.com) Date: Sat, 18 Jun 2011 13:27:11 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 10 new changesets Message-ID: <20110618132729.5906847108@hg.openjdk.java.net> Changeset: ae1d716e395c Author: dsamersoff Date: 2011-06-09 01:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/ae1d716e395c Merge Changeset: f918d6096e23 Author: never Date: 2011-06-02 13:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/hotspot/rev/e2ce15aa3daf Merge Changeset: cfcf2ba8f3eb Author: never Date: 2011-06-15 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cfcf2ba8f3eb Merge ! src/share/vm/prims/methodHandleWalk.cpp Changeset: 1744e37e032b Author: dsamersoff Date: 2011-06-18 13:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/1744e37e032b Merge From bengt.rutisson at oracle.com Tue Jun 21 05:50:33 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 21 Jun 2011 14:50:33 +0200 Subject: Request for review (M): 7016112 CMS: crash during promotion testing Message-ID: <4E009399.4060000@oracle.com> Hi Runtime and GC, Sending this review request to both groups. I fixed a GC bug, but the changes are in runtime code. The bug that I fixed is this one: 7016112 CMS: crash during promotion testing http://monaco.sfbay.sun.com/detail.jsf?cr=7016112 And here is the webrev: http://cr.openjdk.java.net/~brutisso/7016112/webrev.01/ The investigation to find the root of the crashes reported in 7016112 was quite lengthy. It is not that easy to read the CR and figure out what is going on, so here is some background: When we load classes we store references to the methods of a class in an object array. When we have loaded all methods we sort the object array to allow binary search within the array. To do this sort we use stdlib::qsort(), which is the standard library quicksort implementation. If we are using CMS we might be doing concurrent marking while we are sorting the object array. The object array can be found by the concurrent marking code and it may start iterating over the array while we are sorting it. The problem is that on Windows the stdlib::qsort() is not implemented to do atomic updates of elements in the array that it sorts. Instead it does a byte-by-byte swap when it needs to swap two values. That is an easy way to implement different element widths, but it means that at some point in time one element may contain a few bytes from the element above or below. If this happens at the same time as the marking code is trying to read that element, we will be marking some random address and not the method that was supposed to be marked. On Solaris and Linux the stdlib::qsort() implementations try to swap as wide data types as possible so this issue should not occur there. On the other hand we have no guarantees that this will always be how stdlib::qsort() is implemented. After some discussions about different ways of solving this we came to the conclusion that the simplest way is to implement our own quicksort that operates on the correct pointer width (oop or narrowOop). So, this is what I have done to fix this bug. Also, it is likely that this problem will go away when the perm gen removal project is finished. Right now it looks like we will not be tracing and marking methods at all after that change. * Questions * - Should we keep the bubble sort that is done before calling quicksort in methodOopDesc::sort_methods() ? - Should we keep the idempotent option or should we try to always use idempotent sorting (see performance test below)? - What is the best way to handle unit tests? I added a flag called ExecuteInternalVMTests to run unit tests. This is in line with the existing ErrorHandlerTest flag. My thought is that we can use this same flag for other unit tests than just the quicksort tests. Would be good if we could get these tests executed by JPRT as well. I simply run these with "java -XX:+ExecuteInternalVMTests -version". * Testing * Did the obvious testing: Ran JPRT with the changes in the webrev and ran the failing nsk test from the bug (nsk/sysdict/vm/stress/jck12a/sysdictj12a008) repeatedly for sevaral days without failing. I created some unit tests for the quicksort implementation and they all pass. I also made a build that sorts both with my own quicksort and with stdlib::qsort and then compares that the arrays have the same sort order. Ran this through JPRT and it seems to work on all platforms. That run also included the unit tests. If anybody wants to see how this testing was done, there is a separate webrev for that build. The interesting code is in methodOop.cpp: http://cr.openjdk.java.net/~brutisso/7016112/webrev-verify-sorting/ * Performance * I am a bit unsure how to get any relevant performance data for this change. What I have done so far is to create a class that has 65535 methods (which is the maximum - the length of the method array is u2) and I have measured how long it takes to sort this method array. The methods have random names but every hundredth method has 4 overloaded version. This makes sure that there are some duplicates in the array. For now I have run this on my Windows x64 work station with 4 cpus and on a Solaris Sparc machine with 2 cpus (uname says: SunOS sthsparc24 5.10 Generic_139555-08 sun4us sparc FJSV,GPUZC-M Solaris). I am attaching graphs for the results. The Y-axis has time in nano seconds. Judging by this my quicksort is a bit faster on Windows and a bit slower on Solaris. But the interesting thing is that the idempotent version is faster than the default behavior on Windows and on par with the default on Solaris. I assume that this is due to the fact that some stores can be avoided if we don't do swap of duplicates. This means that (at least on Windows) swap is more expensive than compare. If this is true we should probably remove the special treatment of idempotent. I could run this on more machines, but I am not sure how relevant this type of data is. Most method arrays will be much shorter and compared to reading the class from a file the sort will be in the noise. Long email...I hope I covered most of the issues here. Let me know if you have any questions. Thanks, Bengt -------------- next part -------------- A non-text attachment was scrubbed... Name: win_x64_quicksort-perf.png Type: image/png Size: 32741 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110621/6d14848a/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: sparc_quicksort-perf.png Type: image/png Size: 24748 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110621/6d14848a/attachment-0003.png From bengt.rutisson at oracle.com Tue Jun 21 14:32:27 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 21 Jun 2011 23:32:27 +0200 Subject: Request for review (M): 7016112 CMS: crash during promotion testing In-Reply-To: <4E009399.4060000@oracle.com> References: <4E009399.4060000@oracle.com> Message-ID: <4E010DEB.3030104@oracle.com> Hi again, For completeness. Here is the graph for sorting maximum length arrays on Linux x64 (run on my laptop). These runs show that my implementation takes twice as long as the stdlib version. I am not happy about that, but I don't know how much effort it is worth to optimize for this case. Bengt On 2011-06-21 14:50, Bengt Rutisson wrote: > > Hi Runtime and GC, > > Sending this review request to both groups. I fixed a GC bug, but the > changes are in runtime code. > > The bug that I fixed is this one: > 7016112 CMS: crash during promotion testing > http://monaco.sfbay.sun.com/detail.jsf?cr=7016112 > > And here is the webrev: > http://cr.openjdk.java.net/~brutisso/7016112/webrev.01/ > > The investigation to find the root of the crashes reported in 7016112 > was quite lengthy. It is not that easy to read the CR and figure out > what is going on, so here is some background: > > When we load classes we store references to the methods of a class in > an object array. When we have loaded all methods we sort the object > array to allow binary search within the array. To do this sort we use > stdlib::qsort(), which is the standard library quicksort implementation. > > If we are using CMS we might be doing concurrent marking while we are > sorting the object array. The object array can be found by the > concurrent marking code and it may start iterating over the array > while we are sorting it. The problem is that on Windows the > stdlib::qsort() is not implemented to do atomic updates of elements in > the array that it sorts. Instead it does a byte-by-byte swap when it > needs to swap two values. That is an easy way to implement different > element widths, but it means that at some point in time one element > may contain a few bytes from the element above or below. If this > happens at the same time as the marking code is trying to read that > element, we will be marking some random address and not the method > that was supposed to be marked. > > On Solaris and Linux the stdlib::qsort() implementations try to swap > as wide data types as possible so this issue should not occur there. > On the other hand we have no guarantees that this will always be how > stdlib::qsort() is implemented. > > After some discussions about different ways of solving this we came to > the conclusion that the simplest way is to implement our own quicksort > that operates on the correct pointer width (oop or narrowOop). > > So, this is what I have done to fix this bug. > > Also, it is likely that this problem will go away when the perm gen > removal project is finished. Right now it looks like we will not be > tracing and marking methods at all after that change. > > * Questions * > > - Should we keep the bubble sort that is done before calling quicksort > in methodOopDesc::sort_methods() ? > > - Should we keep the idempotent option or should we try to always use > idempotent sorting (see performance test below)? > > - What is the best way to handle unit tests? I added a flag called > ExecuteInternalVMTests to run unit tests. This is in line with the > existing ErrorHandlerTest flag. My thought is that we can use this > same flag for other unit tests than just the quicksort tests. Would be > good if we could get these tests executed by JPRT as well. I simply > run these with "java -XX:+ExecuteInternalVMTests -version". > > > * Testing * > > Did the obvious testing: Ran JPRT with the changes in the webrev and > ran the failing nsk test from the bug > (nsk/sysdict/vm/stress/jck12a/sysdictj12a008) repeatedly for sevaral > days without failing. > > I created some unit tests for the quicksort implementation and they > all pass. > > I also made a build that sorts both with my own quicksort and with > stdlib::qsort and then compares that the arrays have the same sort > order. Ran this through JPRT and it seems to work on all platforms. > That run also included the unit tests. If anybody wants to see how > this testing was done, there is a separate webrev for that build. The > interesting code is in methodOop.cpp: > > http://cr.openjdk.java.net/~brutisso/7016112/webrev-verify-sorting/ > > * Performance * > > I am a bit unsure how to get any relevant performance data for this > change. What I have done so far is to create a class that has 65535 > methods (which is the maximum - the length of the method array is u2) > and I have measured how long it takes to sort this method array. The > methods have random names but every hundredth method has 4 overloaded > version. This makes sure that there are some duplicates in the array. > > For now I have run this on my Windows x64 work station with 4 cpus and > on a Solaris Sparc machine with 2 cpus (uname says: SunOS sthsparc24 > 5.10 Generic_139555-08 sun4us sparc FJSV,GPUZC-M Solaris). > > I am attaching graphs for the results. The Y-axis has time in nano > seconds. Judging by this my quicksort is a bit faster on Windows and a > bit slower on Solaris. But the interesting thing is that the > idempotent version is faster than the default behavior on Windows and > on par with the default on Solaris. I assume that this is due to the > fact that some stores can be avoided if we don't do swap of > duplicates. This means that (at least on Windows) swap is more > expensive than compare. If this is true we should probably remove the > special treatment of idempotent. > > I could run this on more machines, but I am not sure how relevant this > type of data is. Most method arrays will be much shorter and compared > to reading the class from a file the sort will be in the noise. > > Long email...I hope I covered most of the issues here. Let me know if > you have any questions. > > Thanks, > Bengt -------------- next part -------------- A non-text attachment was scrubbed... Name: linux_x64_quicksort-perf.png Type: image/png Size: 21477 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110621/51404556/attachment-0001.png From tom.rodriguez at oracle.com Wed Jun 22 01:05:32 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Jun 2011 01:05:32 -0700 Subject: Request for review (M): 7016112 CMS: crash during promotion testing In-Reply-To: <4E009399.4060000@oracle.com> References: <4E009399.4060000@oracle.com> Message-ID: Overall this looks fine to me. quicksort should really be QuickSort since its a class name and normally we'd make it inherit from AllStatic to indicate that's just a collection of functions. method names should be lower case with underscores though that isn't universally followed. I assume we need to keep the idempotent stuff for the original reasons stated in that comment. We could leave the bubble sort in place or just do some measurement to decide if it's really worth it. It would be nice to get rid of it though. tom On Jun 21, 2011, at 5:50 AM, Bengt Rutisson wrote: > > Hi Runtime and GC, > > Sending this review request to both groups. I fixed a GC bug, but the changes are in runtime code. > > The bug that I fixed is this one: > 7016112 CMS: crash during promotion testing > http://monaco.sfbay.sun.com/detail.jsf?cr=7016112 > > And here is the webrev: > http://cr.openjdk.java.net/~brutisso/7016112/webrev.01/ > > The investigation to find the root of the crashes reported in 7016112 was quite lengthy. It is not that easy to read the CR and figure out what is going on, so here is some background: > > When we load classes we store references to the methods of a class in an object array. When we have loaded all methods we sort the object array to allow binary search within the array. To do this sort we use stdlib::qsort(), which is the standard library quicksort implementation. > > If we are using CMS we might be doing concurrent marking while we are sorting the object array. The object array can be found by the concurrent marking code and it may start iterating over the array while we are sorting it. The problem is that on Windows the stdlib::qsort() is not implemented to do atomic updates of elements in the array that it sorts. Instead it does a byte-by-byte swap when it needs to swap two values. That is an easy way to implement different element widths, but it means that at some point in time one element may contain a few bytes from the element above or below. If this happens at the same time as the marking code is trying to read that element, we will be marking some random address and not the method that was supposed to be marked. > > On Solaris and Linux the stdlib::qsort() implementations try to swap as wide data types as possible so this issue should not occur there. On the other hand we have no guarantees that this will always be how stdlib::qsort() is implemented. > > After some discussions about different ways of solving this we came to the conclusion that the simplest way is to implement our own quicksort that operates on the correct pointer width (oop or narrowOop). > > So, this is what I have done to fix this bug. > > Also, it is likely that this problem will go away when the perm gen removal project is finished. Right now it looks like we will not be tracing and marking methods at all after that change. > > * Questions * > > - Should we keep the bubble sort that is done before calling quicksort in methodOopDesc::sort_methods() ? > > - Should we keep the idempotent option or should we try to always use idempotent sorting (see performance test below)? > > - What is the best way to handle unit tests? I added a flag called ExecuteInternalVMTests to run unit tests. This is in line with the existing ErrorHandlerTest flag. My thought is that we can use this same flag for other unit tests than just the quicksort tests. Would be good if we could get these tests executed by JPRT as well. I simply run these with "java -XX:+ExecuteInternalVMTests -version". > > > * Testing * > > Did the obvious testing: Ran JPRT with the changes in the webrev and ran the failing nsk test from the bug (nsk/sysdict/vm/stress/jck12a/sysdictj12a008) repeatedly for sevaral days without failing. > > I created some unit tests for the quicksort implementation and they all pass. > > I also made a build that sorts both with my own quicksort and with stdlib::qsort and then compares that the arrays have the same sort order. Ran this through JPRT and it seems to work on all platforms. That run also included the unit tests. If anybody wants to see how this testing was done, there is a separate webrev for that build. The interesting code is in methodOop.cpp: > > http://cr.openjdk.java.net/~brutisso/7016112/webrev-verify-sorting/ > > * Performance * > > I am a bit unsure how to get any relevant performance data for this change. What I have done so far is to create a class that has 65535 methods (which is the maximum - the length of the method array is u2) and I have measured how long it takes to sort this method array. The methods have random names but every hundredth method has 4 overloaded version. This makes sure that there are some duplicates in the array. > > For now I have run this on my Windows x64 work station with 4 cpus and on a Solaris Sparc machine with 2 cpus (uname says: SunOS sthsparc24 5.10 Generic_139555-08 sun4us sparc FJSV,GPUZC-M Solaris). > > I am attaching graphs for the results. The Y-axis has time in nano seconds. Judging by this my quicksort is a bit faster on Windows and a bit slower on Solaris. But the interesting thing is that the idempotent version is faster than the default behavior on Windows and on par with the default on Solaris. I assume that this is due to the fact that some stores can be avoided if we don't do swap of duplicates. This means that (at least on Windows) swap is more expensive than compare. If this is true we should probably remove the special treatment of idempotent. > > I could run this on more machines, but I am not sure how relevant this type of data is. Most method arrays will be much shorter and compared to reading the class from a file the sort will be in the noise. > > Long email...I hope I covered most of the issues here. Let me know if you have any questions. > > Thanks, > Bengt > From bengt.rutisson at oracle.com Wed Jun 22 05:17:44 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 22 Jun 2011 14:17:44 +0200 Subject: Request for review (M): 7016112 CMS: crash during promotion testing In-Reply-To: References: <4E009399.4060000@oracle.com> Message-ID: <4E01DD68.4060007@oracle.com> Hi Tom, Thanks for the review! > Overall this looks fine to me. quicksort should really be QuickSort since its a class name and normally we'd make it inherit from AllStatic to indicate that's just a collection of functions. method names should be lower case with underscores though that isn't universally followed. Good points. I am still getting used to the coding standard. I made the changes you proposed. Here is a new webrev: http://cr.openjdk.java.net/~brutisso/7016112/webrev.02/ FYI: I changed the name of the files quicksort.cpp/hpp to quickSort.cpp/hpp. This is not trivial on Windows, since it does not care about case in file names. I got mercurial, Visual Studio and the file system to accept my change. But for some reason webrev still thinks the files are named with all lower case. I'll make sure they are correctly named when I push. > I assume we need to keep the idempotent stuff for the original reasons stated in that comment. We could leave the bubble sort in place or just do some measurement to decide if it's really worth it. It would be nice to get rid of it though. Just to be clear; What I proposed was not to remove the idempotent sorting but to remove the parameter for it and always sort in an idempotent way. I have not seen any performance issues with always sorting with idempotent=true. On the other hand I am still a bit uncertain about performance so it might be best to keep it. Bengt > tom > > On Jun 21, 2011, at 5:50 AM, Bengt Rutisson wrote: > >> Hi Runtime and GC, >> >> Sending this review request to both groups. I fixed a GC bug, but the changes are in runtime code. >> >> The bug that I fixed is this one: >> 7016112 CMS: crash during promotion testing >> http://monaco.sfbay.sun.com/detail.jsf?cr=7016112 >> >> And here is the webrev: >> http://cr.openjdk.java.net/~brutisso/7016112/webrev.01/ >> >> The investigation to find the root of the crashes reported in 7016112 was quite lengthy. It is not that easy to read the CR and figure out what is going on, so here is some background: >> >> When we load classes we store references to the methods of a class in an object array. When we have loaded all methods we sort the object array to allow binary search within the array. To do this sort we use stdlib::qsort(), which is the standard library quicksort implementation. >> >> If we are using CMS we might be doing concurrent marking while we are sorting the object array. The object array can be found by the concurrent marking code and it may start iterating over the array while we are sorting it. The problem is that on Windows the stdlib::qsort() is not implemented to do atomic updates of elements in the array that it sorts. Instead it does a byte-by-byte swap when it needs to swap two values. That is an easy way to implement different element widths, but it means that at some point in time one element may contain a few bytes from the element above or below. If this happens at the same time as the marking code is trying to read that element, we will be marking some random address and not the method that was supposed to be marked. >> >> On Solaris and Linux the stdlib::qsort() implementations try to swap as wide data types as possible so this issue should not occur there. On the other hand we have no guarantees that this will always be how stdlib::qsort() is implemented. >> >> After some discussions about different ways of solving this we came to the conclusion that the simplest way is to implement our own quicksort that operates on the correct pointer width (oop or narrowOop). >> >> So, this is what I have done to fix this bug. >> >> Also, it is likely that this problem will go away when the perm gen removal project is finished. Right now it looks like we will not be tracing and marking methods at all after that change. >> >> * Questions * >> >> - Should we keep the bubble sort that is done before calling quicksort in methodOopDesc::sort_methods() ? >> >> - Should we keep the idempotent option or should we try to always use idempotent sorting (see performance test below)? >> >> - What is the best way to handle unit tests? I added a flag called ExecuteInternalVMTests to run unit tests. This is in line with the existing ErrorHandlerTest flag. My thought is that we can use this same flag for other unit tests than just the quicksort tests. Would be good if we could get these tests executed by JPRT as well. I simply run these with "java -XX:+ExecuteInternalVMTests -version". >> >> >> * Testing * >> >> Did the obvious testing: Ran JPRT with the changes in the webrev and ran the failing nsk test from the bug (nsk/sysdict/vm/stress/jck12a/sysdictj12a008) repeatedly for sevaral days without failing. >> >> I created some unit tests for the quicksort implementation and they all pass. >> >> I also made a build that sorts both with my own quicksort and with stdlib::qsort and then compares that the arrays have the same sort order. Ran this through JPRT and it seems to work on all platforms. That run also included the unit tests. If anybody wants to see how this testing was done, there is a separate webrev for that build. The interesting code is in methodOop.cpp: >> >> http://cr.openjdk.java.net/~brutisso/7016112/webrev-verify-sorting/ >> >> * Performance * >> >> I am a bit unsure how to get any relevant performance data for this change. What I have done so far is to create a class that has 65535 methods (which is the maximum - the length of the method array is u2) and I have measured how long it takes to sort this method array. The methods have random names but every hundredth method has 4 overloaded version. This makes sure that there are some duplicates in the array. >> >> For now I have run this on my Windows x64 work station with 4 cpus and on a Solaris Sparc machine with 2 cpus (uname says: SunOS sthsparc24 5.10 Generic_139555-08 sun4us sparc FJSV,GPUZC-M Solaris). >> >> I am attaching graphs for the results. The Y-axis has time in nano seconds. Judging by this my quicksort is a bit faster on Windows and a bit slower on Solaris. But the interesting thing is that the idempotent version is faster than the default behavior on Windows and on par with the default on Solaris. I assume that this is due to the fact that some stores can be avoided if we don't do swap of duplicates. This means that (at least on Windows) swap is more expensive than compare. If this is true we should probably remove the special treatment of idempotent. >> >> I could run this on more machines, but I am not sure how relevant this type of data is. Most method arrays will be much shorter and compared to reading the class from a file the sort will be in the noise. >> >> Long email...I hope I covered most of the issues here. Let me know if you have any questions. >> >> Thanks, >> Bengt >> From rednaxelafx at gmail.com Wed Jun 22 09:27:01 2011 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 23 Jun 2011 00:27:01 +0800 Subject: Bug in FieldsAllocationStyle=2 logic Message-ID: 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-runtime-dev/attachments/20110623/17bf0a5b/attachment.html From tom.rodriguez at oracle.com Wed Jun 22 14:55:18 2011 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 22 Jun 2011 14:55:18 -0700 Subject: Request for review (M): 7016112 CMS: crash during promotion testing In-Reply-To: <4E01DD68.4060007@oracle.com> References: <4E009399.4060000@oracle.com> <4E01DD68.4060007@oracle.com> Message-ID: On Jun 22, 2011, at 5:17 AM, Bengt Rutisson wrote: > > Hi Tom, > > Thanks for the review! > >> Overall this looks fine to me. quicksort should really be QuickSort since its a class name and normally we'd make it inherit from AllStatic to indicate that's just a collection of functions. method names should be lower case with underscores though that isn't universally followed. > > Good points. I am still getting used to the coding standard. I made the changes you proposed. Here is a new webrev: > > http://cr.openjdk.java.net/~brutisso/7016112/webrev.02/ > > FYI: I changed the name of the files quicksort.cpp/hpp to quickSort.cpp/hpp. This is not trivial on Windows, since it does not care about case in file names. I got mercurial, Visual Studio and the file system to accept my change. But for some reason webrev still thinks the files are named with all lower case. I'll make sure they are correctly named when I push. Ok. > >> I assume we need to keep the idempotent stuff for the original reasons stated in that comment. We could leave the bubble sort in place or just do some measurement to decide if it's really worth it. It would be nice to get rid of it though. > > Just to be clear; What I proposed was not to remove the idempotent sorting but to remove the parameter for it and always sort in an idempotent way. I have not seen any performance issues with always sorting with idempotent=true. On the other hand I am still a bit uncertain about performance so it might be best to keep it. Sorry I misunderstood. I would probably keep it as is. You could use an algorithm which is stable in first place instead but that opens a whole other can of worms. tom > > Bengt > >> tom >> >> On Jun 21, 2011, at 5:50 AM, Bengt Rutisson wrote: >> >>> Hi Runtime and GC, >>> >>> Sending this review request to both groups. I fixed a GC bug, but the changes are in runtime code. >>> >>> The bug that I fixed is this one: >>> 7016112 CMS: crash during promotion testing >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7016112 >>> >>> And here is the webrev: >>> http://cr.openjdk.java.net/~brutisso/7016112/webrev.01/ >>> >>> The investigation to find the root of the crashes reported in 7016112 was quite lengthy. It is not that easy to read the CR and figure out what is going on, so here is some background: >>> >>> When we load classes we store references to the methods of a class in an object array. When we have loaded all methods we sort the object array to allow binary search within the array. To do this sort we use stdlib::qsort(), which is the standard library quicksort implementation. >>> >>> If we are using CMS we might be doing concurrent marking while we are sorting the object array. The object array can be found by the concurrent marking code and it may start iterating over the array while we are sorting it. The problem is that on Windows the stdlib::qsort() is not implemented to do atomic updates of elements in the array that it sorts. Instead it does a byte-by-byte swap when it needs to swap two values. That is an easy way to implement different element widths, but it means that at some point in time one element may contain a few bytes from the element above or below. If this happens at the same time as the marking code is trying to read that element, we will be marking some random address and not the method that was supposed to be marked. >>> >>> On Solaris and Linux the stdlib::qsort() implementations try to swap as wide data types as possible so this issue should not occur there. On the other hand we have no guarantees that this will always be how stdlib::qsort() is implemented. >>> >>> After some discussions about different ways of solving this we came to the conclusion that the simplest way is to implement our own quicksort that operates on the correct pointer width (oop or narrowOop). >>> >>> So, this is what I have done to fix this bug. >>> >>> Also, it is likely that this problem will go away when the perm gen removal project is finished. Right now it looks like we will not be tracing and marking methods at all after that change. >>> >>> * Questions * >>> >>> - Should we keep the bubble sort that is done before calling quicksort in methodOopDesc::sort_methods() ? >>> >>> - Should we keep the idempotent option or should we try to always use idempotent sorting (see performance test below)? >>> >>> - What is the best way to handle unit tests? I added a flag called ExecuteInternalVMTests to run unit tests. This is in line with the existing ErrorHandlerTest flag. My thought is that we can use this same flag for other unit tests than just the quicksort tests. Would be good if we could get these tests executed by JPRT as well. I simply run these with "java -XX:+ExecuteInternalVMTests -version". >>> >>> >>> * Testing * >>> >>> Did the obvious testing: Ran JPRT with the changes in the webrev and ran the failing nsk test from the bug (nsk/sysdict/vm/stress/jck12a/sysdictj12a008) repeatedly for sevaral days without failing. >>> >>> I created some unit tests for the quicksort implementation and they all pass. >>> >>> I also made a build that sorts both with my own quicksort and with stdlib::qsort and then compares that the arrays have the same sort order. Ran this through JPRT and it seems to work on all platforms. That run also included the unit tests. If anybody wants to see how this testing was done, there is a separate webrev for that build. The interesting code is in methodOop.cpp: >>> >>> http://cr.openjdk.java.net/~brutisso/7016112/webrev-verify-sorting/ >>> >>> * Performance * >>> >>> I am a bit unsure how to get any relevant performance data for this change. What I have done so far is to create a class that has 65535 methods (which is the maximum - the length of the method array is u2) and I have measured how long it takes to sort this method array. The methods have random names but every hundredth method has 4 overloaded version. This makes sure that there are some duplicates in the array. >>> >>> For now I have run this on my Windows x64 work station with 4 cpus and on a Solaris Sparc machine with 2 cpus (uname says: SunOS sthsparc24 5.10 Generic_139555-08 sun4us sparc FJSV,GPUZC-M Solaris). >>> >>> I am attaching graphs for the results. The Y-axis has time in nano seconds. Judging by this my quicksort is a bit faster on Windows and a bit slower on Solaris. But the interesting thing is that the idempotent version is faster than the default behavior on Windows and on par with the default on Solaris. I assume that this is due to the fact that some stores can be avoided if we don't do swap of duplicates. This means that (at least on Windows) swap is more expensive than compare. If this is true we should probably remove the special treatment of idempotent. >>> >>> I could run this on more machines, but I am not sure how relevant this type of data is. Most method arrays will be much shorter and compared to reading the class from a file the sort will be in the noise. >>> >>> Long email...I hope I covered most of the issues here. Let me know if you have any questions. >>> >>> Thanks, >>> Bengt >>> > From coleen.phillimore at oracle.com Wed Jun 22 18:46:59 2011 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 22 Jun 2011 21:46:59 -0400 Subject: Request for review (M): 7016112 CMS: crash during promotion testing In-Reply-To: <4E010DEB.3030104@oracle.com> References: <4E009399.4060000@oracle.com> <4E010DEB.3030104@oracle.com> Message-ID: <4E029B13.7030308@oracle.com> http://cr.openjdk.java.net/~brutisso/7016112/webrev.01/src/share/vm/utilities/quicksort.cpp.html 46 bool aIsOdd = a % 2 == 1; 47 bool bIsOdd = b % 2 == 1; Can you add () around the bit operations? Since the order precedence of these operators is always surprising (at least to me). I like the way you set the pattern for the internal testing framework. Thanks for getting this started. When we move these methodOops out of permgen, we might want to go back to stdlib::quicksort. It would be less code for us to maintain. Otherwise, this looks pretty straightforward and I like this fix. Thanks, Coleen On 6/21/2011 5:32 PM, Bengt Rutisson wrote: > > Hi again, > > For completeness. Here is the graph for sorting maximum length arrays > on Linux x64 (run on my laptop). These runs show that my > implementation takes twice as long as the stdlib version. I am not > happy about that, but I don't know how much effort it is worth to > optimize for this case. > > Bengt > > > On 2011-06-21 14:50, Bengt Rutisson wrote: >> >> Hi Runtime and GC, >> >> Sending this review request to both groups. I fixed a GC bug, but the >> changes are in runtime code. >> >> The bug that I fixed is this one: >> 7016112 CMS: crash during promotion testing >> http://monaco.sfbay.sun.com/detail.jsf?cr=7016112 >> >> And here is the webrev: >> http://cr.openjdk.java.net/~brutisso/7016112/webrev.01/ >> >> The investigation to find the root of the crashes reported in 7016112 >> was quite lengthy. It is not that easy to read the CR and figure out >> what is going on, so here is some background: >> >> When we load classes we store references to the methods of a class in >> an object array. When we have loaded all methods we sort the object >> array to allow binary search within the array. To do this sort we use >> stdlib::qsort(), which is the standard library quicksort implementation. >> >> If we are using CMS we might be doing concurrent marking while we are >> sorting the object array. The object array can be found by the >> concurrent marking code and it may start iterating over the array >> while we are sorting it. The problem is that on Windows the >> stdlib::qsort() is not implemented to do atomic updates of elements >> in the array that it sorts. Instead it does a byte-by-byte swap when >> it needs to swap two values. That is an easy way to implement >> different element widths, but it means that at some point in time one >> element may contain a few bytes from the element above or below. If >> this happens at the same time as the marking code is trying to read >> that element, we will be marking some random address and not the >> method that was supposed to be marked. >> >> On Solaris and Linux the stdlib::qsort() implementations try to swap >> as wide data types as possible so this issue should not occur there. >> On the other hand we have no guarantees that this will always be how >> stdlib::qsort() is implemented. >> >> After some discussions about different ways of solving this we came >> to the conclusion that the simplest way is to implement our own >> quicksort that operates on the correct pointer width (oop or narrowOop). >> >> So, this is what I have done to fix this bug. >> >> Also, it is likely that this problem will go away when the perm gen >> removal project is finished. Right now it looks like we will not be >> tracing and marking methods at all after that change. >> >> * Questions * >> >> - Should we keep the bubble sort that is done before calling >> quicksort in methodOopDesc::sort_methods() ? >> >> - Should we keep the idempotent option or should we try to always use >> idempotent sorting (see performance test below)? >> >> - What is the best way to handle unit tests? I added a flag called >> ExecuteInternalVMTests to run unit tests. This is in line with the >> existing ErrorHandlerTest flag. My thought is that we can use this >> same flag for other unit tests than just the quicksort tests. Would >> be good if we could get these tests executed by JPRT as well. I >> simply run these with "java -XX:+ExecuteInternalVMTests -version". >> >> >> * Testing * >> >> Did the obvious testing: Ran JPRT with the changes in the webrev and >> ran the failing nsk test from the bug >> (nsk/sysdict/vm/stress/jck12a/sysdictj12a008) repeatedly for sevaral >> days without failing. >> >> I created some unit tests for the quicksort implementation and they >> all pass. >> >> I also made a build that sorts both with my own quicksort and with >> stdlib::qsort and then compares that the arrays have the same sort >> order. Ran this through JPRT and it seems to work on all platforms. >> That run also included the unit tests. If anybody wants to see how >> this testing was done, there is a separate webrev for that build. The >> interesting code is in methodOop.cpp: >> >> http://cr.openjdk.java.net/~brutisso/7016112/webrev-verify-sorting/ >> >> * Performance * >> >> I am a bit unsure how to get any relevant performance data for this >> change. What I have done so far is to create a class that has 65535 >> methods (which is the maximum - the length of the method array is u2) >> and I have measured how long it takes to sort this method array. The >> methods have random names but every hundredth method has 4 overloaded >> version. This makes sure that there are some duplicates in the array. >> >> For now I have run this on my Windows x64 work station with 4 cpus >> and on a Solaris Sparc machine with 2 cpus (uname says: SunOS >> sthsparc24 5.10 Generic_139555-08 sun4us sparc FJSV,GPUZC-M Solaris). >> >> I am attaching graphs for the results. The Y-axis has time in nano >> seconds. Judging by this my quicksort is a bit faster on Windows and >> a bit slower on Solaris. But the interesting thing is that the >> idempotent version is faster than the default behavior on Windows and >> on par with the default on Solaris. I assume that this is due to the >> fact that some stores can be avoided if we don't do swap of >> duplicates. This means that (at least on Windows) swap is more >> expensive than compare. If this is true we should probably remove the >> special treatment of idempotent. >> >> I could run this on more machines, but I am not sure how relevant >> this type of data is. Most method arrays will be much shorter and >> compared to reading the class from a file the sort will be in the noise. >> >> Long email...I hope I covered most of the issues here. Let me know if >> you have any questions. >> >> Thanks, >> Bengt > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110622/18b59f99/attachment.html From bengt.rutisson at oracle.com Wed Jun 22 22:49:22 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 23 Jun 2011 07:49:22 +0200 Subject: Request for review (M): 7016112 CMS: crash during promotion testing In-Reply-To: <4E029B13.7030308@oracle.com> References: <4E009399.4060000@oracle.com> <4E010DEB.3030104@oracle.com> <4E029B13.7030308@oracle.com> Message-ID: <4E02D3E2.2010608@oracle.com> Coleen, Thanks for the review! On 2011-06-23 03:46, Coleen Phillimore wrote: > http://cr.openjdk.java.net/~brutisso/7016112/webrev.01/src/share/vm/utilities/quicksort.cpp.html > > 46 bool aIsOdd = a % 2 == 1; > 47 bool bIsOdd = b % 2 == 1; > Can you add () around the bit operations? Since the order precedence > of these operators is always surprising (at least to me). Yes, I'll do that. > I like the way you set the pattern for the internal testing > framework. Thanks for getting this started. Thanks, it was really useful to have the unit tests when I made this fix. > When we move these methodOops out of permgen, we might want to go back > to stdlib::quicksort. It would be less code for us to maintain. > Otherwise, this looks pretty straightforward and I like this fix. I agree that we should get back to stdlib::quicksort when it is safe to use it again. Thanks, Bengt > > Thanks, > Coleen > > > On 6/21/2011 5:32 PM, Bengt Rutisson wrote: >> >> Hi again, >> >> For completeness. Here is the graph for sorting maximum length arrays >> on Linux x64 (run on my laptop). These runs show that my >> implementation takes twice as long as the stdlib version. I am not >> happy about that, but I don't know how much effort it is worth to >> optimize for this case. >> >> Bengt >> >> >> On 2011-06-21 14:50, Bengt Rutisson wrote: >>> >>> Hi Runtime and GC, >>> >>> Sending this review request to both groups. I fixed a GC bug, but >>> the changes are in runtime code. >>> >>> The bug that I fixed is this one: >>> 7016112 CMS: crash during promotion testing >>> http://monaco.sfbay.sun.com/detail.jsf?cr=7016112 >>> >>> And here is the webrev: >>> http://cr.openjdk.java.net/~brutisso/7016112/webrev.01/ >>> >>> The investigation to find the root of the crashes reported in >>> 7016112 was quite lengthy. It is not that easy to read the CR and >>> figure out what is going on, so here is some background: >>> >>> When we load classes we store references to the methods of a class >>> in an object array. When we have loaded all methods we sort the >>> object array to allow binary search within the array. To do this >>> sort we use stdlib::qsort(), which is the standard library quicksort >>> implementation. >>> >>> If we are using CMS we might be doing concurrent marking while we >>> are sorting the object array. The object array can be found by the >>> concurrent marking code and it may start iterating over the array >>> while we are sorting it. The problem is that on Windows the >>> stdlib::qsort() is not implemented to do atomic updates of elements >>> in the array that it sorts. Instead it does a byte-by-byte swap when >>> it needs to swap two values. That is an easy way to implement >>> different element widths, but it means that at some point in time >>> one element may contain a few bytes from the element above or below. >>> If this happens at the same time as the marking code is trying to >>> read that element, we will be marking some random address and not >>> the method that was supposed to be marked. >>> >>> On Solaris and Linux the stdlib::qsort() implementations try to swap >>> as wide data types as possible so this issue should not occur there. >>> On the other hand we have no guarantees that this will always be how >>> stdlib::qsort() is implemented. >>> >>> After some discussions about different ways of solving this we came >>> to the conclusion that the simplest way is to implement our own >>> quicksort that operates on the correct pointer width (oop or >>> narrowOop). >>> >>> So, this is what I have done to fix this bug. >>> >>> Also, it is likely that this problem will go away when the perm gen >>> removal project is finished. Right now it looks like we will not be >>> tracing and marking methods at all after that change. >>> >>> * Questions * >>> >>> - Should we keep the bubble sort that is done before calling >>> quicksort in methodOopDesc::sort_methods() ? >>> >>> - Should we keep the idempotent option or should we try to always >>> use idempotent sorting (see performance test below)? >>> >>> - What is the best way to handle unit tests? I added a flag called >>> ExecuteInternalVMTests to run unit tests. This is in line with the >>> existing ErrorHandlerTest flag. My thought is that we can use this >>> same flag for other unit tests than just the quicksort tests. Would >>> be good if we could get these tests executed by JPRT as well. I >>> simply run these with "java -XX:+ExecuteInternalVMTests -version". >>> >>> >>> * Testing * >>> >>> Did the obvious testing: Ran JPRT with the changes in the webrev and >>> ran the failing nsk test from the bug >>> (nsk/sysdict/vm/stress/jck12a/sysdictj12a008) repeatedly for sevaral >>> days without failing. >>> >>> I created some unit tests for the quicksort implementation and they >>> all pass. >>> >>> I also made a build that sorts both with my own quicksort and with >>> stdlib::qsort and then compares that the arrays have the same sort >>> order. Ran this through JPRT and it seems to work on all platforms. >>> That run also included the unit tests. If anybody wants to see how >>> this testing was done, there is a separate webrev for that build. >>> The interesting code is in methodOop.cpp: >>> >>> http://cr.openjdk.java.net/~brutisso/7016112/webrev-verify-sorting/ >>> >>> * Performance * >>> >>> I am a bit unsure how to get any relevant performance data for this >>> change. What I have done so far is to create a class that has 65535 >>> methods (which is the maximum - the length of the method array is >>> u2) and I have measured how long it takes to sort this method array. >>> The methods have random names but every hundredth method has 4 >>> overloaded version. This makes sure that there are some duplicates >>> in the array. >>> >>> For now I have run this on my Windows x64 work station with 4 cpus >>> and on a Solaris Sparc machine with 2 cpus (uname says: SunOS >>> sthsparc24 5.10 Generic_139555-08 sun4us sparc FJSV,GPUZC-M Solaris). >>> >>> I am attaching graphs for the results. The Y-axis has time in nano >>> seconds. Judging by this my quicksort is a bit faster on Windows and >>> a bit slower on Solaris. But the interesting thing is that the >>> idempotent version is faster than the default behavior on Windows >>> and on par with the default on Solaris. I assume that this is due to >>> the fact that some stores can be avoided if we don't do swap of >>> duplicates. This means that (at least on Windows) swap is more >>> expensive than compare. If this is true we should probably remove >>> the special treatment of idempotent. >>> >>> I could run this on more machines, but I am not sure how relevant >>> this type of data is. Most method arrays will be much shorter and >>> compared to reading the class from a file the sort will be in the >>> noise. >>> >>> Long email...I hope I covered most of the issues here. Let me know >>> if you have any questions. >>> >>> Thanks, >>> Bengt >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110623/3d18fd0c/attachment-0001.html From john.coomes at oracle.com Thu Jun 23 20:46:17 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Jun 2011 03:46:17 +0000 Subject: hg: jdk7/hotspot-rt: Added tag jdk7-b146 for changeset 2d38c2a79c14 Message-ID: <20110624034617.C86C7472AF@hg.openjdk.java.net> Changeset: 3e0b96f8f6a0 Author: schien Date: 2011-06-20 16:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/rev/3e0b96f8f6a0 Added tag jdk7-b146 for changeset 2d38c2a79c14 ! .hgtags From john.coomes at oracle.com Thu Jun 23 20:46:27 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Jun 2011 03:46:27 +0000 Subject: hg: jdk7/hotspot-rt/corba: Added tag jdk7-b146 for changeset 770227a4087e Message-ID: <20110624034631.03B8D472B0@hg.openjdk.java.net> Changeset: 36f0efbc66ef Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/corba/rev/36f0efbc66ef Added tag jdk7-b146 for changeset 770227a4087e ! .hgtags From john.coomes at oracle.com Thu Jun 23 20:46:40 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Jun 2011 03:46:40 +0000 Subject: hg: jdk7/hotspot-rt/jaxp: Added tag jdk7-b146 for changeset bcd31fa1e3c6 Message-ID: <20110624034640.76147472B1@hg.openjdk.java.net> Changeset: 9a4d09f33f01 Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxp/rev/9a4d09f33f01 Added tag jdk7-b146 for changeset bcd31fa1e3c6 ! .hgtags From john.coomes at oracle.com Thu Jun 23 20:46:49 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Jun 2011 03:46:49 +0000 Subject: hg: jdk7/hotspot-rt/jaxws: 11 new changesets Message-ID: <20110624034649.E7633472B2@hg.openjdk.java.net> Changeset: 581dab3f0773 Author: asaha Date: 2011-04-21 16:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/581dab3f0773 Merge Changeset: 26610bb80151 Author: asaha Date: 2011-05-04 12:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/26610bb80151 Merge Changeset: c6ff860428c7 Author: asaha Date: 2011-05-05 22:28 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/c6ff860428c7 Merge Changeset: f4e1caef46d0 Author: asaha Date: 2011-05-24 11:11 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/f4e1caef46d0 Merge Changeset: 9896cee00786 Author: asaha Date: 2011-05-26 17:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/9896cee00786 Merge Changeset: d1febdcb0351 Author: asaha Date: 2011-05-26 21:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/d1febdcb0351 Merge Changeset: 239c80c331da Author: asaha Date: 2011-06-06 10:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/239c80c331da Merge Changeset: 09412171ca4b Author: asaha Date: 2011-06-03 07:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/09412171ca4b Merge Changeset: 9d8fd0982fb8 Author: asaha Date: 2011-06-06 10:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/9d8fd0982fb8 Merge Changeset: 05469dd4c366 Author: lana Date: 2011-06-15 16:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/05469dd4c366 Merge Changeset: faa394edbfe3 Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jaxws/rev/faa394edbfe3 Added tag jdk7-b146 for changeset 05469dd4c366 ! .hgtags From john.coomes at oracle.com Thu Jun 23 20:49:56 2011 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 24 Jun 2011 03:49:56 +0000 Subject: hg: jdk7/hotspot-rt/jdk: 44 new changesets Message-ID: <20110624035808.153C9472B5@hg.openjdk.java.net> Changeset: cf0632d2db2c Author: jrose Date: 2011-06-14 22:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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 Changeset: ae731399e525 Author: dav Date: 2011-06-07 22:58 +0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/jdk/rev/f08fcae94813 Merge Changeset: 6e961c328276 Author: michaelm Date: 2011-06-08 10:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/jdk/rev/646ab254ff80 Merge Changeset: aca0dc2b921c Author: weijun Date: 2011-02-09 11:50 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/557bd9b5d92f Merge Changeset: e142148d8b54 Author: asaha Date: 2011-04-12 14:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/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-rt/jdk/rev/0865aa0ad9b2 Merge Changeset: 6f8a4d334fb2 Author: asaha Date: 2011-04-20 09:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/jdk/rev/f3645b5d6e62 Merge Changeset: b626f78c57e1 Author: asaha Date: 2011-04-21 08:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/b626f78c57e1 Merge Changeset: cec45f3353be Author: asaha Date: 2011-04-21 08:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/cec45f3353be Merge Changeset: 6133c9ee3a01 Author: asaha Date: 2011-04-21 08:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/6133c9ee3a01 Merge Changeset: dd06e8d3da91 Author: asaha Date: 2011-04-21 15:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/dd06e8d3da91 Merge Changeset: b2295905901a Author: asaha Date: 2011-04-21 16:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/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-rt/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-rt/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-rt/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-rt/jdk/rev/647b031200f0 Merge Changeset: 92b5197e9ff5 Author: asaha Date: 2011-05-26 21:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/jdk/rev/cca9ea306c6e Merge Changeset: dab3e66ebda7 Author: lana Date: 2011-06-06 19:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/dab3e66ebda7 Merge Changeset: 9f17be5136d1 Author: wetmore Date: 2011-06-09 14:24 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/jdk/rev/4961be00d3b5 Merge Changeset: a65fa0f6717e Author: trims Date: 2011-06-17 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/a65fa0f6717e Merge Changeset: c46f97579fe6 Author: alanb Date: 2011-06-17 16:47 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/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-rt/jdk/rev/c102e1221afa Merge Changeset: 539e576793a8 Author: lana Date: 2011-06-18 10:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/539e576793a8 Merge Changeset: 7b4f4230fecf Author: schien Date: 2011-06-20 16:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-rt/jdk/rev/7b4f4230fecf Added tag jdk7-b146 for changeset 539e576793a8 ! .hgtags From daniel.daugherty at oracle.com Fri Jun 24 00:39:46 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Fri, 24 Jun 2011 07:39:46 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 7043987: 3/3 JVMTI FollowReferences is slow Message-ID: <20110624073951.43115472C1@hg.openjdk.java.net> Changeset: d425748f2203 Author: dcubed Date: 2011-06-23 20:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d425748f2203 7043987: 3/3 JVMTI FollowReferences is slow Summary: VM_HeapWalkOperation::doit() should only reset mark bits when necessary. Reviewed-by: dsamersoff, ysr, dholmes, dcubed Contributed-by: ashok.srinivasa.murthy at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp From David.Holmes at oracle.com Mon Jun 27 00:34:41 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 27 Jun 2011 17:34:41 +1000 Subject: Request for review:7059288 Message-ID: <4E083291.1050809@oracle.com> This only affects JPRT so non-Oracle folk can feel free to ignore. webrev: http://cr.openjdk.java.net/~dholmes/7059288/webrev/ Simple change to add a missing environment variable from the "embedded" JPRT build flavour. This will be pushed to hsx/hotspot-rt/hotspot Thanks, David From bengt.rutisson at oracle.com Mon Jun 27 16:22:15 2011 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 28 Jun 2011 01:22:15 +0200 Subject: Request for review (M): 7016112 CMS: crash during promotion testing In-Reply-To: References: <4E009399.4060000@oracle.com> <4E01DD68.4060007@oracle.com> Message-ID: <4E0910A7.1050604@oracle.com> Tom, Coleen and Ramki, Thanks for the reviews! Here is an updated webrev that I hope includes fixes to all the comments that you had: http://cr.openjdk.java.net/~brutisso/7016112/webrev.03/ The main change compared to the previous version is that I skipped the "middle layer sort" in objArrayOop. This was based on a comment from Ramki that this sort would not be safe for all collectors anyway. Better in that case to do the dirtying of cards directly in methodOop. I also looked some more at performance. It was bugging me that the Linux implementation of stdlib::qsort was so much faster than my version. I picked up some of the optimization that the Linux stdlib::qsort does and this made my implementation quite a bit faster. Not just on Linux, but also on Windows and Solaris. As always there is a trade-off between clean code and fast code. I basically tweaked quickSort.hpp in four ways: 1) Use insertion sort if the length of the array is less than 7 2) Use insertion sort if it appears that the array is almost sorted (partition did not have to do any calls to swap()) 3) Added inline to all inner methods 4) Use more samples for calculating the pivot element if the length of the array is larger than 40 Of these, 4) is the one that has the biggest impact. But they all contribute in some extent to better performance. Here is a webrev with these optimizations. It just contains the changes compared to the webrev above: http://cr.openjdk.java.net/~brutisso/7016112/webrev.03-opt/ I would like to push the optimized version, but I would like to hear your thougths. If you think it is too ugly I am ok with pusing the non-optimized version. I did some runs on Win x64, Linux x64 and Solaris x64 using my test class with 65535 methods. As you can see from the graphs that I attach, my implementation is still behind on Linux but not quite as bad as before. The Linux and Windows runs are made on the same dual-booted computer. So they have identical hardware. It is interesting to see that both my implementations (non-optimized and optimized) take about the same time on Windows and Linux, but stdlib:qsort is much faster on Linux than on Windows. The Y-axis in the graphs now has time in seconds. I also ran RefWorkLoad a bit. I will run it some more, but so far I have not seen any significant differences there. I'll probably focus my runs on Linux to see if I can see any regressions. Any thoughts on this? I would like to push this within the next few days since I will be going on vacation next week. Thanks, Bengt On 2011-06-22 23:55, Tom Rodriguez wrote: > On Jun 22, 2011, at 5:17 AM, Bengt Rutisson wrote: > >> Hi Tom, >> >> Thanks for the review! >> >>> Overall this looks fine to me. quicksort should really be QuickSort since its a class name and normally we'd make it inherit from AllStatic to indicate that's just a collection of functions. method names should be lower case with underscores though that isn't universally followed. >> Good points. I am still getting used to the coding standard. I made the changes you proposed. Here is a new webrev: >> >> http://cr.openjdk.java.net/~brutisso/7016112/webrev.02/ >> >> FYI: I changed the name of the files quicksort.cpp/hpp to quickSort.cpp/hpp. This is not trivial on Windows, since it does not care about case in file names. I got mercurial, Visual Studio and the file system to accept my change. But for some reason webrev still thinks the files are named with all lower case. I'll make sure they are correctly named when I push. > Ok. > >>> I assume we need to keep the idempotent stuff for the original reasons stated in that comment. We could leave the bubble sort in place or just do some measurement to decide if it's really worth it. It would be nice to get rid of it though. >> Just to be clear; What I proposed was not to remove the idempotent sorting but to remove the parameter for it and always sort in an idempotent way. I have not seen any performance issues with always sorting with idempotent=true. On the other hand I am still a bit uncertain about performance so it might be best to keep it. > Sorry I misunderstood. I would probably keep it as is. You could use an algorithm which is stable in first place instead but that opens a whole other can of worms. > > tom > >> Bengt >> >>> tom >>> >>> On Jun 21, 2011, at 5:50 AM, Bengt Rutisson wrote: >>> >>>> Hi Runtime and GC, >>>> >>>> Sending this review request to both groups. I fixed a GC bug, but the changes are in runtime code. >>>> >>>> The bug that I fixed is this one: >>>> 7016112 CMS: crash during promotion testing >>>> http://monaco.sfbay.sun.com/detail.jsf?cr=7016112 >>>> >>>> And here is the webrev: >>>> http://cr.openjdk.java.net/~brutisso/7016112/webrev.01/ >>>> >>>> The investigation to find the root of the crashes reported in 7016112 was quite lengthy. It is not that easy to read the CR and figure out what is going on, so here is some background: >>>> >>>> When we load classes we store references to the methods of a class in an object array. When we have loaded all methods we sort the object array to allow binary search within the array. To do this sort we use stdlib::qsort(), which is the standard library quicksort implementation. >>>> >>>> If we are using CMS we might be doing concurrent marking while we are sorting the object array. The object array can be found by the concurrent marking code and it may start iterating over the array while we are sorting it. The problem is that on Windows the stdlib::qsort() is not implemented to do atomic updates of elements in the array that it sorts. Instead it does a byte-by-byte swap when it needs to swap two values. That is an easy way to implement different element widths, but it means that at some point in time one element may contain a few bytes from the element above or below. If this happens at the same time as the marking code is trying to read that element, we will be marking some random address and not the method that was supposed to be marked. >>>> >>>> On Solaris and Linux the stdlib::qsort() implementations try to swap as wide data types as possible so this issue should not occur there. On the other hand we have no guarantees that this will always be how stdlib::qsort() is implemented. >>>> >>>> After some discussions about different ways of solving this we came to the conclusion that the simplest way is to implement our own quicksort that operates on the correct pointer width (oop or narrowOop). >>>> >>>> So, this is what I have done to fix this bug. >>>> >>>> Also, it is likely that this problem will go away when the perm gen removal project is finished. Right now it looks like we will not be tracing and marking methods at all after that change. >>>> >>>> * Questions * >>>> >>>> - Should we keep the bubble sort that is done before calling quicksort in methodOopDesc::sort_methods() ? >>>> >>>> - Should we keep the idempotent option or should we try to always use idempotent sorting (see performance test below)? >>>> >>>> - What is the best way to handle unit tests? I added a flag called ExecuteInternalVMTests to run unit tests. This is in line with the existing ErrorHandlerTest flag. My thought is that we can use this same flag for other unit tests than just the quicksort tests. Would be good if we could get these tests executed by JPRT as well. I simply run these with "java -XX:+ExecuteInternalVMTests -version". >>>> >>>> >>>> * Testing * >>>> >>>> Did the obvious testing: Ran JPRT with the changes in the webrev and ran the failing nsk test from the bug (nsk/sysdict/vm/stress/jck12a/sysdictj12a008) repeatedly for sevaral days without failing. >>>> >>>> I created some unit tests for the quicksort implementation and they all pass. >>>> >>>> I also made a build that sorts both with my own quicksort and with stdlib::qsort and then compares that the arrays have the same sort order. Ran this through JPRT and it seems to work on all platforms. That run also included the unit tests. If anybody wants to see how this testing was done, there is a separate webrev for that build. The interesting code is in methodOop.cpp: >>>> >>>> http://cr.openjdk.java.net/~brutisso/7016112/webrev-verify-sorting/ >>>> >>>> * Performance * >>>> >>>> I am a bit unsure how to get any relevant performance data for this change. What I have done so far is to create a class that has 65535 methods (which is the maximum - the length of the method array is u2) and I have measured how long it takes to sort this method array. The methods have random names but every hundredth method has 4 overloaded version. This makes sure that there are some duplicates in the array. >>>> >>>> For now I have run this on my Windows x64 work station with 4 cpus and on a Solaris Sparc machine with 2 cpus (uname says: SunOS sthsparc24 5.10 Generic_139555-08 sun4us sparc FJSV,GPUZC-M Solaris). >>>> >>>> I am attaching graphs for the results. The Y-axis has time in nano seconds. Judging by this my quicksort is a bit faster on Windows and a bit slower on Solaris. But the interesting thing is that the idempotent version is faster than the default behavior on Windows and on par with the default on Solaris. I assume that this is due to the fact that some stores can be avoided if we don't do swap of duplicates. This means that (at least on Windows) swap is more expensive than compare. If this is true we should probably remove the special treatment of idempotent. >>>> >>>> I could run this on more machines, but I am not sure how relevant this type of data is. Most method arrays will be much shorter and compared to reading the class from a file the sort will be in the noise. >>>> >>>> Long email...I hope I covered most of the issues here. Let me know if you have any questions. >>>> >>>> Thanks, >>>> Bengt >>>> -------------- next part -------------- A non-text attachment was scrubbed... Name: solarisx64.png Type: image/png Size: 16422 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110628/14479ce3/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: winx64.png Type: image/png Size: 25386 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110628/14479ce3/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: linuxx64.png Type: image/png Size: 16601 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20110628/14479ce3/attachment-0005.png From keith.mcguigan at oracle.com Tue Jun 28 05:52:07 2011 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Tue, 28 Jun 2011 08:52:07 -0400 Subject: Request for review:7059288 In-Reply-To: <4E083291.1050809@oracle.com> References: <4E083291.1050809@oracle.com> Message-ID: <7DD951F1-7958-4FAA-8C7D-E763A0F5DE64@oracle.com> Looks fine. -- - Keith On Jun 27, 2011, at 3:34 AM, David Holmes wrote: > This only affects JPRT so non-Oracle folk can feel free to ignore. > > webrev: http://cr.openjdk.java.net/~dholmes/7059288/webrev/ > > Simple change to add a missing environment variable from the > "embedded" JPRT build flavour. > > This will be pushed to hsx/hotspot-rt/hotspot > > Thanks, > David From Dmitry.Samersoff at oracle.com Tue Jun 28 08:12:25 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 28 Jun 2011 19:12:25 +0400 Subject: Request for review:7059288 In-Reply-To: <7DD951F1-7958-4FAA-8C7D-E763A0F5DE64@oracle.com> References: <4E083291.1050809@oracle.com> <7DD951F1-7958-4FAA-8C7D-E763A0F5DE64@oracle.com> Message-ID: <4E09EF59.7070801@oracle.com> On 2011-06-28 16:52, Keith McGuigan wrote: > > Looks fine. Looks fine. > > -- > - Keith > > On Jun 27, 2011, at 3:34 AM, David Holmes wrote: > >> This only affects JPRT so non-Oracle folk can feel free to ignore. >> >> webrev: http://cr.openjdk.java.net/~dholmes/7059288/webrev/ >> >> Simple change to add a missing environment variable from the >> "embedded" JPRT build flavour. >> >> This will be pushed to hsx/hotspot-rt/hotspot >> >> Thanks, >> David > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From volker.simonis at gmail.com Wed Jun 29 01:26:22 2011 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 29 Jun 2011 10:26:22 +0200 Subject: Question about "6961186: Better VM handling of unexpected exceptions from application native code" Message-ID: Hi, recently the bug "6961186: Better VM handling of unexpected exceptions from application native code" has been fixed but the fix only applies for Windows and Solaris platforms. While the bug evaluation at http://bugs.sun.com/view_bug.do?bug_id=6961186 mentions that the fix for Solaris and Linux would be the same (i.e. using set_terminate to catch uncaught C++ exceptions), the fix was apparently not implemented for Linux. Has the Linux fix been omitted intentionally or accidentally? Regards, Volker From daniel.daugherty at oracle.com Thu Jun 30 00:34:26 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 30 Jun 2011 07:34:26 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 6951623: 3/3 possible performance problems in FollowReferences() and GetObjectsWithTags() Message-ID: <20110630073427.E4EEF4708F@hg.openjdk.java.net> Changeset: 88dce6a60ac8 Author: dcubed Date: 2011-06-29 20:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/88dce6a60ac8 6951623: 3/3 possible performance problems in FollowReferences() and GetObjectsWithTags() Summary: Call collect_stack_roots() before collect_simple_roots() as an optimization. Reviewed-by: ysr, dsamersoff, dcubed Contributed-by: ashok.srinivasa.murthy at oracle.com ! src/share/vm/prims/jvmtiTagMap.cpp From David.Holmes at oracle.com Thu Jun 30 03:13:46 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 30 Jun 2011 20:13:46 +1000 Subject: Question about "6961186: Better VM handling of unexpected exceptions from application native code" In-Reply-To: References: Message-ID: <4E0C4C5A.8030903@oracle.com> Hi Volker, Volker Simonis said the following on 06/29/11 18:26: > recently the bug "6961186: Better VM handling of unexpected exceptions > from application native code" has been fixed but the fix only applies > for Windows and Solaris platforms. > While the bug evaluation at > http://bugs.sun.com/view_bug.do?bug_id=6961186 mentions that the fix > for Solaris and Linux would be the same (i.e. using set_terminate to > catch uncaught C++ exceptions), the fix was apparently not implemented > for Linux. > > Has the Linux fix been omitted intentionally or accidentally? As I understand it, while the suggested fix should work for Linux we actually don't link with the C++ library on Linux that provides this API, and we did not want to start doing so for an obscure problem that hasn't even been reported on Linux. For Linux the error is apparently much clearer even without additional handling by the VM. The problems we've seen here have predominantly been on Windows. Solaris was included as it was trivial to do so. David Holmes > Regards, > Volker From david.holmes at oracle.com Thu Jun 30 21:52:51 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Fri, 01 Jul 2011 04:52:51 +0000 Subject: hg: hsx/hotspot-rt/hotspot: 2 new changesets Message-ID: <20110701045258.996BA470D0@hg.openjdk.java.net> Changeset: aa5f3f597899 Author: dholmes Date: 2011-06-30 02:36 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/aa5f3f597899 7059288: JPRT embedded builds don't set MINIMIZE_RAM_USAGE Reviewed-by: kamg, dsamersoff ! make/jprt.gmk Changeset: 709d9389b2bc Author: dholmes Date: 2011-06-30 15:05 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/709d9389b2bc Merge