From thomas.rodriguez at sun.com Mon Mar 1 14:12:21 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Mon, 01 Mar 2010 22:12:21 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6930398: fix for return address locals in OSR entries uses wrong test Message-ID: <20100301221225.316E441E04@hg.openjdk.java.net> Changeset: 7d236a9688c5 Author: never Date: 2010-03-01 12:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7d236a9688c5 6930398: fix for return address locals in OSR entries uses wrong test Reviewed-by: kvn ! src/share/vm/opto/parse1.cpp From Ulf.Zibis at gmx.de Tue Mar 2 16:46:36 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 03 Mar 2010 01:46:36 +0100 Subject: C2 compiler could be better ... Message-ID: <4B8DB16C.500@gmx.de> Having following code: public String(int[] codePoints, int offset, int count) { ... int n = 0; for (int i = offset; i < offset + count; i++) { int c = codePoints[i]; if (c >> 16 == 0) n += 1; else if ((c >> 16) < (Character.MAX_CODE_POINT + 1 >> 16)) n += 2; else throw new IllegalArgumentException(Integer.toString(c)); } ... } It compiles to: -> int c = codePoints[i]; 0x00b87aa4: mov 0x1c(%esp),%ebp 0x00b87aa8: mov 0xc(%ebp,%edi,4),%ebx ;*iaload ; - java.lang.String::<init>@72 (line 284) -> if (c >> 16 == 0) 0x00b87aac: mov %ebx,%ecx 0x00b87aae: sar $0x10,%ecx ;*ishr ; - java.lang.String::<init>@79 (line 290) 0x00b87ab1: test %ecx,%ecx 0x00b87ab3: je 0x00b87acb ;*ifne ; - java.lang.String::<init>@80 (line 290) -> else if ((c >> 16) < (Character.MAX_CODE_POINT + 1 >> 16)) 0x00b87ab5: cmp $0x11,%ecx -> else 0x00b87ab8: jge 0x00b87ce6 ;*if_icmpge ; - java.lang.String::<init>@96 (line 293) -> n += 2; 0x00b87abe: mov 0x8(%esp),%ebx 0x00b87ac2: add $0x2,%ebx ;*iinc ; - java.lang.String::<init>@99 (line 295) 0x00b87ac5: mov %ebx,0x8(%esp) 0x00b87ac9: jmp 0x00b87ad4 -> n += 1; 0x00b87acb: mov 0x8(%esp),%ecx 0x00b87acf: inc %ecx ;*iinc ; - java.lang.String::<init>@83 (line 292) 0x00b87ad0: mov %ecx,0x8(%esp) ;*goto ; - java.lang.String::<init>@102 (line 295) -> i++ 0x00b87ad4: inc %edi ;*iinc ; - java.lang.String::<init>@118 (line 283) -> i < offset + count; 0x00b87ad5: cmp 0x18(%esp),%edi 0x00b87ad9: jl 0x00b87aa4 ;*if_icmpge ; - java.lang.String::<init>@66 (line 283) 0x00b87adb: My questions/suggestions: 1.) Why is variable n first loaded to register %ebx / %ecx and than copied back? Wouldn't it be better to have: 0x00b87ac2: add $0x2,0x8(%esp) and: 0x00b87acf: inc 0x8(%esp) 2.) Or better, why is,'t variable n constantly held in register e.g. %eax ? 3.) Why is oop of int[] codePoints always newly loaded in each loop? I think it could be held in register %ebp ? -Ulf From Christian.Thalinger at Sun.COM Wed Mar 3 07:46:23 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 03 Mar 2010 15:46:23 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 7 new changesets Message-ID: <20100303154656.A14C943C32@hg.openjdk.java.net> Changeset: b81f3572f355 Author: tonyp Date: 2010-02-23 23:13 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b81f3572f355 6928059: G1: command line parameter renaming Summary: Rename G1 parameters to make them more consistent. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.cpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 1c72304f1885 Author: tonyp Date: 2010-02-23 23:14 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1c72304f1885 6928073: G1: use existing command line parameters for marking cycle initiation Summary: replace the combination of the G1SteadyStateUsed / G1SteadyStateUsedDelta parameteres to decide the marking initiation threshold and instead use InitiatingHeapOccupancyPercent. Reviewed-by: ysr, johnc ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 5f1f51edaff6 Author: jmasa Date: 2010-02-24 07:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5f1f51edaff6 6928081: G1: rename parameters common with CMS Summary: Rename marking stack sizing flags to be common between G1 and CMS Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: a1c410de27e4 Author: tonyp Date: 2010-02-24 14:56 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a1c410de27e4 6928065: G1: use existing command line parameters to set the young generation size Summary: see synopsis Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: ab75c83d7c37 Author: johnc Date: 2010-03-02 13:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ab75c83d7c37 Merge ! src/share/vm/includeDB_core Changeset: 8911d8c0596f Author: phh Date: 2010-02-26 16:40 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8911d8c0596f 6923123: Hotspot refuses to start when -Xmx4m or -Xms4m is specified Summary: Reduce NewSize from 4m to 1m. Reviewed-by: tonyp, jmasa ! src/share/vm/runtime/globals.hpp Changeset: c76ca382971b Author: johnc Date: 2010-03-02 13:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c76ca382971b Merge ! src/share/vm/runtime/globals.hpp From Christian.Thalinger at Sun.COM Fri Mar 5 07:30:13 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 05 Mar 2010 16:30:13 +0100 Subject: Request for reviews (S): 6932536: JSR 292 modified JDK MethodHandlesTest fails on x86_64 Message-ID: <1267803013.16238.8.camel@macbook> http://cr.openjdk.java.net/~twisti/6932536/webrev.01/ Changing the nextArg value of MethodHandlesTest to be bigger than Integer.MAX_VALUE to actually test long arguments reveals a bug on x86_64. There were actually two bugs: 1. For i2l and unboxi long values were stored in two slots as 32-bit words instead of a 64-bit one. 2. The stack-move conversion value was read as 32-bit value and then shifted which resulted in e.g. 0xffffffff values in 64-bit registers instead of -1. Tested: MethodHandlesTest From Thomas.Rodriguez at Sun.COM Fri Mar 5 10:17:28 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 05 Mar 2010 10:17:28 -0800 Subject: Request for reviews (S): 6932536: JSR 292 modified JDK MethodHandlesTest fails on x86_64 In-Reply-To: <1267803013.16238.8.camel@macbook> References: <1267803013.16238.8.camel@macbook> Message-ID: <7B1FBFEA-098B-415D-ADED-840AA4E76628@sun.com> Looks good. tom On Mar 5, 2010, at 7:30 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6932536/webrev.01/ > > Changing the nextArg value of MethodHandlesTest to be bigger than > Integer.MAX_VALUE to actually test long arguments reveals a bug on > x86_64. > > There were actually two bugs: > > 1. For i2l and unboxi long values were stored in two slots as 32-bit > words instead of a 64-bit one. > > 2. The stack-move conversion value was read as 32-bit value and then > shifted which resulted in e.g. 0xffffffff values in 64-bit registers > instead of -1. > > Tested: MethodHandlesTest > From Roland.Westrelin at Sun.COM Fri Mar 5 11:42:14 2010 From: Roland.Westrelin at Sun.COM (Roland Westrelin) Date: Fri, 05 Mar 2010 20:42:14 +0100 Subject: Request for reviews (S): 6932496 c1: deoptimization of jsr subroutine fails on sparcv9 Message-ID: http://cr.openjdk.java.net/~roland/6932496/webrev.00/ From Thomas.Rodriguez at Sun.COM Fri Mar 5 11:45:29 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 05 Mar 2010 11:45:29 -0800 Subject: Request for reviews (S): 6932496 c1: deoptimization of jsr subroutine fails on sparcv9 In-Reply-To: References: Message-ID: Looks good. tom On Mar 5, 2010, at 11:42 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/6932496/webrev.00/ > From John.Rose at Sun.COM Fri Mar 5 16:51:55 2010 From: John.Rose at Sun.COM (John Rose) Date: Fri, 05 Mar 2010 16:51:55 -0800 Subject: Request for reviews (S): 6932536: JSR 292 modified JDK MethodHandlesTest fails on x86_64 In-Reply-To: <1267803013.16238.8.camel@macbook> References: <1267803013.16238.8.camel@macbook> Message-ID: <8577ED27-BC74-420D-8C7E-554111F8ECC9@sun.com> On Mar 5, 2010, at 7:30 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6932536/webrev.01/ Looks good; thanks. And thanks for extending the test suite! -- John P.S. I wish we could factor those ifdefs into the assembler. It would be possible (as it is on SPARC) if x86_32 allowed 64-bit values in one register. Perhaps there's a way to hide the distinction between a movq and two movl's (along with the tagged-stack-interpreter stuff) in an assembler macro. I think it would require an ADT which encapsulates either a single 64-bit reg or a pair of 32-bit regs (depending in CPU mode). That's not worth the effort. But on SPARC, we should expect to have fewer ifdefs. From Christian.Thalinger at Sun.COM Mon Mar 8 04:41:59 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 08 Mar 2010 13:41:59 +0100 Subject: Request for reviews (S): 6932536: JSR 292 modified JDK MethodHandlesTest fails on x86_64 In-Reply-To: <8577ED27-BC74-420D-8C7E-554111F8ECC9@sun.com> References: <1267803013.16238.8.camel@macbook> <8577ED27-BC74-420D-8C7E-554111F8ECC9@sun.com> Message-ID: <1268052120.1318.16.camel@macbook> On Fri, 2010-03-05 at 16:51 -0800, John Rose wrote: > On Mar 5, 2010, at 7:30 AM, Christian Thalinger wrote: > > > http://cr.openjdk.java.net/~twisti/6932536/webrev.01/ > > Looks good; thanks. And thanks for extending the test suite! > > -- John > > P.S. I wish we could factor those ifdefs into the assembler. It > would be possible (as it is on SPARC) if x86_32 allowed 64-bit values > in one register. Perhaps there's a way to hide the distinction > between a movq and two movl's (along with the tagged-stack-interpreter > stuff) in an assembler macro. I think it would require an ADT which > encapsulates either a single 64-bit reg or a pair of 32-bit regs > (depending in CPU mode). That's not worth the effort. Would be nice to have. But as you say, not worth the effort... > But on SPARC, we should expect to have fewer ifdefs. I try to. -- Christian From Christian.Thalinger at Sun.COM Mon Mar 8 07:02:47 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 08 Mar 2010 15:02:47 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6932536: JSR 292 modified JDK MethodHandlesTest fails on x86_64 Message-ID: <20100308150251.0DA17442E0@hg.openjdk.java.net> Changeset: 51db1e4b379d Author: twisti Date: 2010-03-08 04:46 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/51db1e4b379d 6932536: JSR 292 modified JDK MethodHandlesTest fails on x86_64 Summary: A modified MethodHandlesTest revealed two bugs on x86_64. Reviewed-by: never, jrose ! src/cpu/x86/vm/methodHandles_x86.cpp From Christian.Thalinger at Sun.COM Tue Mar 9 03:33:38 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 09 Mar 2010 12:33:38 +0100 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> Message-ID: <1268134418.1823.63.camel@macbook> On Tue, 2010-02-16 at 12:05 -0800, Tom Rodriguez wrote: > > I can change it yes, but I'm really not sure yet if we need to preserve > > the SP on SPARC. > > I don't think they are and I'd rather not have XXX comments lying > around. If they are needed then I suspect you'll figure it out > because of a new bug report, not because the comment is there. Since I've already started the SPARC C1 port I know that we need to implement these methods. I removed the comment and put an Unimplemented() there instead. > > No, RSI is an argument register on 64 bit and I didn't know which one to > > use instead. I guess any callee saved might do it? > > Yep. I used R14. Here is an updated webrev and I will push that one: http://cr.openjdk.java.net/~twisti/6919934/webrev.02/ -- Christian From john.coomes at sun.com Tue Mar 9 08:10:12 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 09 Mar 2010 16:10:12 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b85 for changeset cf26288a114b Message-ID: <20100309161012.3152B4445D@hg.openjdk.java.net> Changeset: 3ddf90b39176 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/3ddf90b39176 Added tag jdk7-b85 for changeset cf26288a114b ! .hgtags From john.coomes at sun.com Tue Mar 9 08:10:17 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 09 Mar 2010 16:10:17 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b85 for changeset c67a9df7bc0c Message-ID: <20100309161019.CE3EF4445F@hg.openjdk.java.net> Changeset: 6253e28826d1 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/6253e28826d1 Added tag jdk7-b85 for changeset c67a9df7bc0c ! .hgtags From john.coomes at sun.com Tue Mar 9 08:15:45 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 09 Mar 2010 16:15:45 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b85 for changeset 6c0ccabb430d Message-ID: <20100309161545.9A0DB44461@hg.openjdk.java.net> Changeset: 81c0f115bbe5 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/81c0f115bbe5 Added tag jdk7-b85 for changeset 6c0ccabb430d ! .hgtags From john.coomes at sun.com Tue Mar 9 08:15:51 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 09 Mar 2010 16:15:51 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b85 for changeset 8424512588ff Message-ID: <20100309161551.44E3C44462@hg.openjdk.java.net> Changeset: 512b0e924a5a Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/512b0e924a5a Added tag jdk7-b85 for changeset 8424512588ff ! .hgtags From john.coomes at sun.com Tue Mar 9 08:16:39 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 09 Mar 2010 16:16:39 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 13 new changesets Message-ID: <20100309162114.5301244464@hg.openjdk.java.net> Changeset: 2ba381560071 Author: dcherepanov Date: 2010-02-12 19:58 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2ba381560071 6705345: Enable multiple file selection in AWT FileDialog Reviewed-by: art, anthony, alexp ! src/share/classes/java/awt/FileDialog.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_FileDialog.h + test/java/awt/FileDialog/MultipleMode/MultipleMode.html + test/java/awt/FileDialog/MultipleMode/MultipleMode.java Changeset: d6d2de6ee2d1 Author: lana Date: 2010-02-19 15:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d6d2de6ee2d1 Merge Changeset: 83c34a6b1458 Author: mchung Date: 2010-02-08 23:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/83c34a6b1458 6924497: HotSpotDiagnosticsMXBean.getDiagnosticOptions throws NPE Summary: Check if the element in the flags array is non-null to filter unsupported flags Reviewed-by: dcubed ! src/share/classes/sun/management/Flag.java ! src/share/native/sun/management/Flag.c Changeset: ec438f2b6886 Author: chegar Date: 2010-02-10 13:23 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/ec438f2b6886 6693244: Java Web Start app fails on 6u10 beta w/ AssertionError in AuthenticationInfo.requestCompleted Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! test/ProblemList.txt ! test/java/net/Authenticator/B4769350.java Changeset: 784e52734b8d Author: mchung Date: 2010-02-10 17:51 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/784e52734b8d 6915413: Module build: building of specified jdk components instead of all Summary: Define new SUBDIRS_* variables for specifying components for one group Reviewed-by: ohair ! make/Makefile ! make/com/Makefile ! make/com/sun/Makefile ! make/com/sun/demo/Makefile ! make/com/sun/demo/jvmti/Makefile ! make/com/sun/inputmethods/Makefile ! make/com/sun/java/Makefile ! make/com/sun/java/browser/Makefile ! make/com/sun/jmx/Makefile ! make/com/sun/jndi/Makefile ! make/com/sun/jndi/rmi/Makefile ! make/com/sun/nio/Makefile ! make/com/sun/org/Makefile ! make/com/sun/org/apache/Makefile ! make/com/sun/security/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tracing/Makefile ! make/common/Defs.gmk ! make/common/Sanity.gmk + make/common/Subdirs.gmk ! make/common/shared/Sanity.gmk ! make/java/Makefile ! make/java/hpi/Makefile ! make/java/java/Makefile ! make/java/java/genlocales.gmk ! make/java/main/Makefile ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile + make/java/nio/mxbean/Makefile ! make/java/redist/Makefile - make/java/text/FILES_java.gmk ! make/java/text/Makefile + make/java/text/base/FILES_java.gmk + make/java/text/base/Makefile + make/java/text/bidi/Makefile ! make/javax/Makefile ! make/javax/rmi/Makefile ! make/javax/sound/Makefile ! make/javax/swing/Makefile ! make/jpda/Makefile ! make/jpda/transport/Makefile ! make/mkdemo/Makefile ! make/mkdemo/applets/Makefile ! make/mkdemo/jfc/Makefile ! make/mkdemo/jni/Makefile ! make/mkdemo/jvmti/Makefile ! make/mkdemo/management/Makefile ! make/mkdemo/scripting/Makefile ! make/mksample/Makefile ! make/mksample/jmx/Makefile ! make/mksample/nio/Makefile ! make/mksample/scripting/Makefile ! make/mksample/webservices/Makefile ! make/org/Makefile ! make/org/ietf/Makefile ! make/sun/Makefile ! make/sun/cmm/Makefile ! make/sun/image/Makefile ! make/sun/management/Makefile ! make/sun/net/Makefile ! make/sun/net/spi/Makefile ! make/sun/net/spi/nameservice/Makefile ! make/sun/nio/Makefile ! make/sun/org/Makefile ! make/sun/org/mozilla/Makefile ! make/sun/rmi/Makefile ! make/sun/security/Makefile ! make/sun/tracing/Makefile ! make/tools/Makefile Changeset: d7d8807fca86 Author: weijun Date: 2010-02-12 10:24 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d7d8807fca86 6925639: keytool -genkeypair -help missing dname option Reviewed-by: mullan ! src/share/classes/sun/security/tools/KeyTool.java Changeset: 74f493fae483 Author: mchung Date: 2010-02-12 11:33 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/74f493fae483 6925868: Eliminate pack200's dependency on logging Summary: Replace j.u.l.Logger with sun.util.logging.PlatformLogger Reviewed-by: alanb, forax ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java Changeset: 328c5d3974fe Author: mchung Date: 2010-02-15 10:18 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/328c5d3974fe Merge Changeset: 84792500750c Author: lana Date: 2010-02-17 10:24 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/84792500750c Merge Changeset: e83d9c0d5e95 Author: chegar Date: 2010-02-22 15:27 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e83d9c0d5e95 6912868: "java.net.useSystemProxies" behavior fails to check "use_same_proxy" in GNOME Reviewed-by: alanb, chegar Contributed-by: damjan.jov at gmail.com ! src/solaris/native/sun/net/spi/DefaultProxySelector.c + test/java/net/ProxySelector/SystemProxies.java Changeset: c96d6cb31723 Author: chegar Date: 2010-02-23 17:08 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c96d6cb31723 6365587: Proxy-Connection header sent through tunnel Reviewed-by: michaelm ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: b396584a3e64 Author: lana Date: 2010-02-23 10:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b396584a3e64 Merge - make/java/text/FILES_java.gmk Changeset: 03cd9e62961f Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/03cd9e62961f Added tag jdk7-b85 for changeset b396584a3e64 ! .hgtags From john.coomes at sun.com Tue Mar 9 08:35:41 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Tue, 09 Mar 2010 16:35:41 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 11 new changesets Message-ID: <20100309163615.43AFB44468@hg.openjdk.java.net> Changeset: 7d9e3a15d2b3 Author: jjg Date: 2010-02-15 16:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/7d9e3a15d2b3 6926555: 6921979 breaks TreePosTest Reviewed-by: darcy ! test/tools/javac/treepostests/TreePosTest.java Changeset: af18e3956985 Author: darcy Date: 2010-02-15 18:20 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/af18e3956985 6634138: Source generated in last round not compiled Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! test/tools/javac/T6403466.java + test/tools/javac/processing/6634138/Dummy.java + test/tools/javac/processing/6634138/ExerciseDependency.java + test/tools/javac/processing/6634138/T6634138.java Changeset: fe17a9dbef03 Author: darcy Date: 2010-02-15 20:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/fe17a9dbef03 6926699: Annotation processing regression tests should typically return SourceVersion.latest Reviewed-by: jjg ! test/tools/javac/6341866/Anno.java ! test/tools/javac/T6406771.java ! test/tools/javac/T6411379.java ! test/tools/javac/T6423583.java ! test/tools/javac/T6855236.java ! test/tools/javac/api/6421111/T6421111.java ! test/tools/javac/api/6468404/T6468404.java ! test/tools/javac/api/T6412669.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/processing/6348499/A.java ! test/tools/javac/processing/6414633/A.java ! test/tools/javac/processing/6430209/T6430209.java ! test/tools/javac/processing/6430209/b6341534.java ! test/tools/javac/processing/T6439826.java ! test/tools/javac/processing/model/element/TypeParamBounds.java ! test/tools/javac/processing/model/type/MirroredTypeEx/OverEager.java ! test/tools/javac/processing/model/type/NoTypes.java ! test/tools/javac/processing/model/util/GetTypeElemBadArg.java ! test/tools/javac/processing/model/util/OverridesSpecEx.java Changeset: 631a273dac0f Author: darcy Date: 2010-02-15 20:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/631a273dac0f 6926703: apt tests should run with assertions enabled Reviewed-by: jjg ! src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java Changeset: 16b9b7f45933 Author: darcy Date: 2010-02-17 14:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/16b9b7f45933 6927061: Refactor apt implemenation to use code from JSR 269 Reviewed-by: jjg ! src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java Changeset: 67f0e05098fa Author: lana Date: 2010-02-17 10:25 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/67f0e05098fa Merge Changeset: 0fce6b64c258 Author: lana Date: 2010-02-17 16:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/0fce6b64c258 Merge Changeset: a3be81d385ee Author: jjg Date: 2010-02-18 15:41 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/a3be81d385ee 6927797: langtools/test/tools/javac/EarlyAssert.java fails when run with assertions enabled (-ea) Reviewed-by: darcy ! test/tools/javac/EarlyAssert.java + test/tools/javac/EarlyAssertWrapper.java Changeset: f25efdb55c99 Author: andrew Date: 2010-02-22 21:37 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/f25efdb55c99 6928623: Behaviour of VERBOSE=true on langtools build Summary: VERBOSE=true causes -diagnostics to be passed to ant rather than -debug Reviewed-by: jjg ! make/Makefile Changeset: 136bfc679462 Author: lana Date: 2010-02-23 10:17 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/136bfc679462 Merge Changeset: b816baf594e3 Author: mikejwre Date: 2010-03-04 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/b816baf594e3 Added tag jdk7-b85 for changeset 136bfc679462 ! .hgtags From Thomas.Rodriguez at Sun.COM Tue Mar 9 11:25:35 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 09 Mar 2010 11:25:35 -0800 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <1268134418.1823.63.camel@macbook> References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> Message-ID: <2623136E-FDBE-445A-ADA8-D545B3C63180@Sun.COM> Looks good. tom On Mar 9, 2010, at 3:33 AM, Christian Thalinger wrote: > On Tue, 2010-02-16 at 12:05 -0800, Tom Rodriguez wrote: >>> I can change it yes, but I'm really not sure yet if we need to preserve >>> the SP on SPARC. >> >> I don't think they are and I'd rather not have XXX comments lying >> around. If they are needed then I suspect you'll figure it out >> because of a new bug report, not because the comment is there. > > Since I've already started the SPARC C1 port I know that we need to > implement these methods. I removed the comment and put an > Unimplemented() there instead. > >>> No, RSI is an argument register on 64 bit and I didn't know which one to >>> use instead. I guess any callee saved might do it? >> >> Yep. > > I used R14. > > Here is an updated webrev and I will push that one: > > http://cr.openjdk.java.net/~twisti/6919934/webrev.02/ > > -- Christian > From thomas.rodriguez at sun.com Tue Mar 9 16:28:31 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Wed, 10 Mar 2010 00:28:31 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6932270: Allow Java's ELF symtab reader to use separate debuginfo files Message-ID: <20100310002834.CBAC3444EE@hg.openjdk.java.net> Changeset: 7de45b5044c3 Author: never Date: 2010-03-09 11:02 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7de45b5044c3 6932270: Allow Java's ELF symtab reader to use separate debuginfo files Reviewed-by: never Contributed-by: Andrew Haley ! agent/src/os/linux/libproc_impl.c ! agent/src/os/linux/symtab.c ! agent/src/os/linux/symtab.h + make/linux/makefiles/build_vm_def.sh ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/linux/makefiles/vm.make From Christian.Thalinger at Sun.COM Wed Mar 10 01:58:26 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 10 Mar 2010 09:58:26 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20100310095834.D060444575@hg.openjdk.java.net> Changeset: 3cf667df43ef Author: twisti Date: 2010-03-09 20:16 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3cf667df43ef 6919934: JSR 292 needs to support x86 C1 Summary: This implements JSR 292 support for C1 x86. Reviewed-by: never, jrose, kvn ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_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/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_IR.hpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/ci/ciCPCache.cpp ! src/share/vm/ci/ciCPCache.hpp ! src/share/vm/includeDB_compiler1 ! src/share/vm/includeDB_core ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/vframeArray.cpp Changeset: d8e270c4f609 Author: twisti Date: 2010-03-09 23:57 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d8e270c4f609 Merge From roland.westrelin at sun.com Wed Mar 10 10:25:49 2010 From: roland.westrelin at sun.com (roland.westrelin at sun.com) Date: Wed, 10 Mar 2010 18:25:49 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6932496: c1: deoptimization of jsr subroutine fails on sparcv9 Message-ID: <20100310182604.72C57445EF@hg.openjdk.java.net> Changeset: c466efa608d5 Author: roland Date: 2010-03-05 13:58 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c466efa608d5 6932496: c1: deoptimization of jsr subroutine fails on sparcv9 Summary: store jsr ret bci as intptr constant in c1 debug info Reviewed-by: never ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LinearScan.cpp + test/compiler/6932496/Test6932496.java From gbenson at redhat.com Thu Mar 11 04:47:10 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 11 Mar 2010 12:47:10 +0000 Subject: Review Request: Zero 32-bit/64kb page fix Message-ID: <20100311124710.GB3586@redhat.com> Hi all, My fix for 6927165 increased the number of shadow pages for 32-bit platforms. This causes a problem on systems with 64kb pages in that the VM will immediately run out of stack. This webrev fixes: http://cr.openjdk.java.net/~gbenson/zero-64kb-pages-fix/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Thu Mar 11 05:11:04 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 11 Mar 2010 14:11:04 +0100 Subject: Review Request: Zero 32-bit/64kb page fix In-Reply-To: <20100311124710.GB3586@redhat.com> References: <20100311124710.GB3586@redhat.com> Message-ID: <1268313064.2124.14.camel@macbook> On Thu, 2010-03-11 at 12:47 +0000, Gary Benson wrote: > Hi all, > > My fix for 6927165 increased the number of shadow pages for > 32-bit platforms. This causes a problem on systems with 64kb > pages in that the VM will immediately run out of stack. This > webrev fixes: > > http://cr.openjdk.java.net/~gbenson/zero-64kb-pages-fix/ > > I don't have a bug id for this. The changes look good and I will push it as: 6934089: Zero 32-bit/64kb page fix -- Christian From gbenson at redhat.com Thu Mar 11 06:43:46 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 11 Mar 2010 14:43:46 +0000 Subject: Review Request: Zero 32-bit/64kb page fix In-Reply-To: <1268313064.2124.14.camel@macbook> References: <20100311124710.GB3586@redhat.com> <1268313064.2124.14.camel@macbook> Message-ID: <20100311144345.GC3586@redhat.com> Christian Thalinger wrote: > On Thu, 2010-03-11 at 12:47 +0000, Gary Benson wrote: > > My fix for 6927165 increased the number of shadow pages for > > 32-bit platforms. This causes a problem on systems with 64kb > > pages in that the VM will immediately run out of stack. This > > webrev fixes: > > > > http://cr.openjdk.java.net/~gbenson/zero-64kb-pages-fix/ > > > > I don't have a bug id for this. > > The changes look good and I will push it as: > > 6934089: Zero 32-bit/64kb page fix Thanks twisti. Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Thu Mar 11 07:12:39 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 11 Mar 2010 15:12:39 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6934089: Zero 32-bit/64kb page fix Message-ID: <20100311151244.2EAF644724@hg.openjdk.java.net> Changeset: da06d1795d84 Author: twisti Date: 2010-03-11 05:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/da06d1795d84 6934089: Zero 32-bit/64kb page fix Summary: The fix for 6927165 increased the number of shadow pages for 32-bit platforms and this causes a problem on systems with 64kb pages. Reviewed-by: twisti Contributed-by: Gary Benson ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp From Thomas.Rodriguez at Sun.COM Fri Mar 12 10:37:53 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 12 Mar 2010 10:37:53 -0800 Subject: review (S) for 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I Message-ID: http://cr.openjdk.java.net/~never/6930043 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I Reviewed-by: The new loop predication code is missing logic to test that the initial value of the index is in range. In many cases will be eliminated statically. Tested with failing test. Also tested that this new test doesn't affect the performance improvement we were seeing with scimark. src/share/vm/opto/loopTransform.cpp test/compiler/6930043/Test6930043.java From Vladimir.Kozlov at Sun.COM Fri Mar 12 15:05:33 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 12 Mar 2010 15:05:33 -0800 Subject: review (S) for 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I In-Reply-To: References: Message-ID: <4B9AC8BD.70006@sun.com> Tom, You removed lines 2225,2226 but where ctrl node comes from for next line?: 2243 ld_rng = (LoadRangeNode*)invar.clone(ld_rng, ctrl); Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6930043 > > 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I > Reviewed-by: > > The new loop predication code is missing logic to test that the > initial value of the index is in range. In many cases will be > eliminated statically. Tested with failing test. Also tested that > this new test doesn't affect the performance improvement we were > seeing with scimark. > > src/share/vm/opto/loopTransform.cpp > test/compiler/6930043/Test6930043.java From Thomas.Rodriguez at Sun.COM Fri Mar 12 16:14:38 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 12 Mar 2010 16:14:38 -0800 Subject: review (S) for 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I In-Reply-To: <4B9AC8BD.70006@sun.com> References: <4B9AC8BD.70006@sun.com> Message-ID: That's what I get for doing edits just before generating the webrev. I'd originally deleted the clone since it seems useless. If it's invariant then cloning it doesn't change anything. I chickened out at the last minuted and restored but didn't recompile. I think I'll stick with deleting it. I've regenerated the webrev. tom On Mar 12, 2010, at 3:05 PM, Vladimir Kozlov wrote: > Tom, > > You removed lines 2225,2226 but where ctrl node comes from for next line?: > > 2243 ld_rng = (LoadRangeNode*)invar.clone(ld_rng, ctrl); > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6930043 >> 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I >> Reviewed-by: >> The new loop predication code is missing logic to test that the >> initial value of the index is in range. In many cases will be >> eliminated statically. Tested with failing test. Also tested that >> this new test doesn't affect the performance improvement we were >> seeing with scimark. >> src/share/vm/opto/loopTransform.cpp >> test/compiler/6930043/Test6930043.java From Vladimir.Kozlov at Sun.COM Fri Mar 12 16:34:01 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 12 Mar 2010 16:34:01 -0800 Subject: review (S) for 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I In-Reply-To: References: <4B9AC8BD.70006@sun.com> Message-ID: <4B9ADD79.3030801@sun.com> Fine. But as we discussed you need to verify that invar.clone() does not have any side effects. Thanks, Vladimir Tom Rodriguez wrote: > That's what I get for doing edits just before generating the webrev. I'd originally deleted the clone since it seems useless. If it's invariant then cloning it doesn't change anything. I chickened out at the last minuted and restored but didn't recompile. I think I'll stick with deleting it. I've regenerated the webrev. > > tom > > On Mar 12, 2010, at 3:05 PM, Vladimir Kozlov wrote: > >> Tom, >> >> You removed lines 2225,2226 but where ctrl node comes from for next line?: >> >> 2243 ld_rng = (LoadRangeNode*)invar.clone(ld_rng, ctrl); >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6930043 >>> 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I >>> Reviewed-by: >>> The new loop predication code is missing logic to test that the >>> initial value of the index is in range. In many cases will be >>> eliminated statically. Tested with failing test. Also tested that >>> this new test doesn't affect the performance improvement we were >>> seeing with scimark. >>> src/share/vm/opto/loopTransform.cpp >>> test/compiler/6930043/Test6930043.java > From Christian.Thalinger at Sun.COM Mon Mar 15 07:51:54 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 15 Mar 2010 15:51:54 +0100 Subject: Request for reviews (L): 6934494: JSR 292 MethodHandles adapters should be generated into their own CodeBlob Message-ID: <1268664714.9148.15.camel@macbook> http://cr.openjdk.java.net/~twisti/6934494/webrev.01/ Passing a null pointer to an InvokeDynamic function call, like: MethodHandle mh = null; InvokeDynamic.funcall(mh); should lead to a NullPointerException. But with current HotSpot we hit a guarantee: # Internal Error (sharedRuntime.cpp:586), pid=4116, tid=3072834448 # Error: guarantee(cb->is_adapter_blob(),"exception happened outside interpreter, nmethods and vtable stubs (1)") The reason for this is that the MethodHandles adapters are generated into the same CodeBlob as other code stubs which do not throw exceptions. The only blob that can throw exceptions is the C2I/I2C adapter blob, and this what the guarantee says. The fix is to generate MethodHandles adapters into their own CodeBlob and add a check into the guarantee for that blob. src/cpu/sparc/vm/stubRoutines_sparc.hpp src/cpu/x86/vm/stubGenerator_x86_32.cpp src/cpu/x86/vm/stubGenerator_x86_64.cpp src/cpu/x86/vm/stubRoutines_x86_32.hpp src/cpu/x86/vm/stubRoutines_x86_64.hpp src/share/vm/code/codeBlob.cpp src/share/vm/code/codeBlob.hpp src/share/vm/includeDB_core src/share/vm/prims/methodHandles.cpp src/share/vm/prims/methodHandles.hpp src/share/vm/runtime/init.cpp src/share/vm/runtime/sharedRuntime.cpp src/share/vm/runtime/sharedRuntime.hpp From Christian.Thalinger at Sun.COM Mon Mar 15 09:43:14 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 15 Mar 2010 17:43:14 +0100 Subject: Request for reviews (M): 6934966: JSR 292 add C1 logic for saved SP over MethodHandle calls Message-ID: <1268671394.9148.18.camel@macbook> http://cr.openjdk.java.net/~twisti/6934966/webrev.01/ The logic for x86 C1 to save the SP over MH calls is pretty straight forward which uses the always-callee-saved BP register. On SPARC, and maybe other architectures, we need to choose one of the callee-saved registers and kill it over MH calls. This CR adds some logic to support this. It should be pushed before SPARC C1 support is pushed since that would break x86 C1. src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp src/cpu/x86/vm/c1_LIRAssembler_x86.cpp src/cpu/x86/vm/c1_LIRGenerator_x86.cpp src/share/vm/c1/c1_LIR.cpp src/share/vm/c1/c1_LIR.hpp src/share/vm/c1/c1_LIRAssembler.cpp src/share/vm/c1/c1_LIRAssembler.hpp src/share/vm/c1/c1_LIRGenerator.hpp src/share/vm/includeDB_compiler1 From Vladimir.Kozlov at Sun.COM Mon Mar 15 10:19:18 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 15 Mar 2010 10:19:18 -0700 Subject: Request for reviews (L): 6934494: JSR 292 MethodHandles adapters should be generated into their own CodeBlob In-Reply-To: <1268664714.9148.15.camel@macbook> References: <1268664714.9148.15.camel@macbook> Message-ID: <4B9E6C16.7030702@sun.com> Looks good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6934494/webrev.01/ > > Passing a null pointer to an InvokeDynamic function call, like: > > MethodHandle mh = null; > InvokeDynamic.funcall(mh); > > should lead to a NullPointerException. But with current HotSpot we > hit a guarantee: > > # Internal Error (sharedRuntime.cpp:586), pid=4116, tid=3072834448 > # Error: guarantee(cb->is_adapter_blob(),"exception happened outside interpreter, nmethods and vtable stubs (1)") > > The reason for this is that the MethodHandles adapters are generated > into the same CodeBlob as other code stubs which do not throw > exceptions. The only blob that can throw exceptions is the C2I/I2C > adapter blob, and this what the guarantee says. > > The fix is to generate MethodHandles adapters into their own CodeBlob > and add a check into the guarantee for that blob. > > src/cpu/sparc/vm/stubRoutines_sparc.hpp > src/cpu/x86/vm/stubGenerator_x86_32.cpp > src/cpu/x86/vm/stubGenerator_x86_64.cpp > src/cpu/x86/vm/stubRoutines_x86_32.hpp > src/cpu/x86/vm/stubRoutines_x86_64.hpp > src/share/vm/code/codeBlob.cpp > src/share/vm/code/codeBlob.hpp > src/share/vm/includeDB_core > src/share/vm/prims/methodHandles.cpp > src/share/vm/prims/methodHandles.hpp > src/share/vm/runtime/init.cpp > src/share/vm/runtime/sharedRuntime.cpp > src/share/vm/runtime/sharedRuntime.hpp > From Thomas.Rodriguez at Sun.COM Mon Mar 15 10:37:38 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 15 Mar 2010 10:37:38 -0700 Subject: Request for reviews (M): 6934966: JSR 292 add C1 logic for saved SP over MethodHandle calls In-Reply-To: <1268671394.9148.18.camel@macbook> References: <1268671394.9148.18.camel@macbook> Message-ID: I think LIRGenerator::get_method_handle_invoke_SP_save_opr should really be declared in FrameMap instead of down in LIRGenerator since it's a platform invariant. Since it's invariant you don't really have to pass it down all the way through LIRGenerator so this change could be a lot smaller. You could simply do this in c1_LIR.cpp: + if (opJavaCall->is_method_handle_invoke()) do_temp(FrameMap::method_handle_saved_sp_opr()); I know we talked about doing it way you've done it but seeing the final webrev I think it can be done much more simply. preserve_SP can just use FrameMap::method_handle_saved_sp_opr() directly as well. If you want to keep what you have I'm not against that but it's more complicated than it really needs to be. tom On Mar 15, 2010, at 9:43 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6934966/webrev.01/ > > The logic for x86 C1 to save the SP over MH calls is pretty straight > forward which uses the always-callee-saved BP register. On SPARC, and > maybe other architectures, we need to choose one of the callee-saved > registers and kill it over MH calls. > > This CR adds some logic to support this. It should be pushed before > SPARC C1 support is pushed since that would break x86 C1. > > src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp > src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp > src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > src/cpu/x86/vm/c1_LIRGenerator_x86.cpp > src/share/vm/c1/c1_LIR.cpp > src/share/vm/c1/c1_LIR.hpp > src/share/vm/c1/c1_LIRAssembler.cpp > src/share/vm/c1/c1_LIRAssembler.hpp > src/share/vm/c1/c1_LIRGenerator.hpp > src/share/vm/includeDB_compiler1 > > From Christian.Thalinger at Sun.COM Mon Mar 15 10:44:13 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 15 Mar 2010 18:44:13 +0100 Subject: Request for reviews (M): 6934966: JSR 292 add C1 logic for saved SP over MethodHandle calls In-Reply-To: References: <1268671394.9148.18.camel@macbook> Message-ID: <1268675053.9148.22.camel@macbook> On Mon, 2010-03-15 at 10:37 -0700, Tom Rodriguez wrote: > I think LIRGenerator::get_method_handle_invoke_SP_save_opr should > really be declared in FrameMap instead of down in LIRGenerator since > it's a platform invariant. Since it's invariant you don't really have > to pass it down all the way through LIRGenerator so this change could > be a lot smaller. You could simply do this in c1_LIR.cpp: > > + if (opJavaCall->is_method_handle_invoke()) do_temp(FrameMap::method_handle_saved_sp_opr()); > > I know we talked about doing it way you've done it but seeing the > final webrev I think it can be done much more simply. preserve_SP can > just use FrameMap::method_handle_saved_sp_opr() directly as well. > > If you want to keep what you have I'm not against that but it's more > complicated than it really needs to be. Good point. I will do the suggested change. Btw. I tried to also do a do_input on the temporary register, as you said, but that triggered an assert (can't remember which one). -- Christian From Thomas.Rodriguez at Sun.COM Mon Mar 15 11:21:07 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 15 Mar 2010 11:21:07 -0700 Subject: Request for reviews (M): 6934966: JSR 292 add C1 logic for saved SP over MethodHandle calls In-Reply-To: <1268675053.9148.22.camel@macbook> References: <1268671394.9148.18.camel@macbook> <1268675053.9148.22.camel@macbook> Message-ID: <28F08437-5787-4580-A542-227A1123CCE4@Sun.COM> On Mar 15, 2010, at 10:44 AM, Christian Thalinger wrote: > On Mon, 2010-03-15 at 10:37 -0700, Tom Rodriguez wrote: >> I think LIRGenerator::get_method_handle_invoke_SP_save_opr should >> really be declared in FrameMap instead of down in LIRGenerator since >> it's a platform invariant. Since it's invariant you don't really have >> to pass it down all the way through LIRGenerator so this change could >> be a lot smaller. You could simply do this in c1_LIR.cpp: >> >> + if (opJavaCall->is_method_handle_invoke()) do_temp(FrameMap::method_handle_saved_sp_opr()); >> >> I know we talked about doing it way you've done it but seeing the >> final webrev I think it can be done much more simply. preserve_SP can >> just use FrameMap::method_handle_saved_sp_opr() directly as well. >> >> If you want to keep what you have I'm not against that but it's more >> complicated than it really needs to be. > > Good point. I will do the suggested change. > > Btw. I tried to also do a do_input on the temporary register, as you > said, but that triggered an assert (can't remember which one). Actually I don't think the do_input is necessary to protect the register from being used for debug info in C1. We may want to introduce an assert that the SP preserve register is never mentioned in debug info, though I'm not sure where we should place that. tom > > -- Christian > From Thomas.Rodriguez at Sun.COM Mon Mar 15 11:45:13 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 15 Mar 2010 11:45:13 -0700 Subject: Request for reviews (L): 6934494: JSR 292 MethodHandles adapters should be generated into their own CodeBlob In-Reply-To: <1268664714.9148.15.camel@macbook> References: <1268664714.9148.15.camel@macbook> Message-ID: Looks good. tom On Mar 15, 2010, at 7:51 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6934494/webrev.01/ > > Passing a null pointer to an InvokeDynamic function call, like: > > MethodHandle mh = null; > InvokeDynamic.funcall(mh); > > should lead to a NullPointerException. But with current HotSpot we > hit a guarantee: > > # Internal Error (sharedRuntime.cpp:586), pid=4116, tid=3072834448 > # Error: guarantee(cb->is_adapter_blob(),"exception happened outside interpreter, nmethods and vtable stubs (1)") > > The reason for this is that the MethodHandles adapters are generated > into the same CodeBlob as other code stubs which do not throw > exceptions. The only blob that can throw exceptions is the C2I/I2C > adapter blob, and this what the guarantee says. > > The fix is to generate MethodHandles adapters into their own CodeBlob > and add a check into the guarantee for that blob. > > src/cpu/sparc/vm/stubRoutines_sparc.hpp > src/cpu/x86/vm/stubGenerator_x86_32.cpp > src/cpu/x86/vm/stubGenerator_x86_64.cpp > src/cpu/x86/vm/stubRoutines_x86_32.hpp > src/cpu/x86/vm/stubRoutines_x86_64.hpp > src/share/vm/code/codeBlob.cpp > src/share/vm/code/codeBlob.hpp > src/share/vm/includeDB_core > src/share/vm/prims/methodHandles.cpp > src/share/vm/prims/methodHandles.hpp > src/share/vm/runtime/init.cpp > src/share/vm/runtime/sharedRuntime.cpp > src/share/vm/runtime/sharedRuntime.hpp > From Thomas.Rodriguez at Sun.COM Mon Mar 15 13:58:04 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Mon, 15 Mar 2010 13:58:04 -0700 Subject: review (S) for 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I In-Reply-To: <4B9ADD79.3030801@sun.com> References: <4B9AC8BD.70006@sun.com> <4B9ADD79.3030801@sun.com> Message-ID: <6FF17904-7A7B-4FC5-961B-618E46239449@Sun.COM> It can have side effects because of the order that PhaseIdealLoop schedules things. It performs a late schedule so invariant things can end up inside the loop body if they are only used in the loop. The makes identifying loop members simpler but the Invariance helper class is used by the predication code to make clones outside the loop so that truly invariant values will appear invariant. So I've rearranged the code a bit more so we any values we clone are create with the control of the higher if. I've also redistributed some code which was shared before since I think it obfuscated what was really happening, particular once we needed to have two new ifs in the range check case. I'm running CTW to make sure that some of the asserts I added don't fail but it works the same as before. I've updated the webrev. tom On Mar 12, 2010, at 4:34 PM, Vladimir Kozlov wrote: > Fine. But as we discussed you need to verify that invar.clone() does not have any side effects. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> That's what I get for doing edits just before generating the webrev. I'd originally deleted the clone since it seems useless. If it's invariant then cloning it doesn't change anything. I chickened out at the last minuted and restored but didn't recompile. I think I'll stick with deleting it. I've regenerated the webrev. >> tom >> On Mar 12, 2010, at 3:05 PM, Vladimir Kozlov wrote: >>> Tom, >>> >>> You removed lines 2225,2226 but where ctrl node comes from for next line?: >>> >>> 2243 ld_rng = (LoadRangeNode*)invar.clone(ld_rng, ctrl); >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6930043 >>>> 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I >>>> Reviewed-by: >>>> The new loop predication code is missing logic to test that the >>>> initial value of the index is in range. In many cases will be >>>> eliminated statically. Tested with failing test. Also tested that >>>> this new test doesn't affect the performance improvement we were >>>> seeing with scimark. >>>> src/share/vm/opto/loopTransform.cpp >>>> test/compiler/6930043/Test6930043.java From Paul.Hohensee at Sun.COM Mon Mar 15 15:57:14 2010 From: Paul.Hohensee at Sun.COM (Paul Hohensee) Date: Mon, 15 Mar 2010 18:57:14 -0400 Subject: A question on HotSpot's compilation triggering In-Reply-To: References: Message-ID: <4B9EBB4A.8000001@sun.com> Sorry to have taken so long to get back to you. The place to ask this question is on hotspot-compiler-dev at openjdk.java.net and/or hotpot-runtime-dev at openjdk.java.net, but I'll do my best to answer here. Hopefully the experts will correct me if I'm wrong. :) Short answer to first question, you're right, OSR compiles are done asynchronously and I'll have to change the slide. I have no idea why I had the idea they were synchronous. Detail below. Second question answer is yes, I believe that with the introduction of lazy deopt in 5.0, all deopts, including OSR, are synchronous. Third question answer is that there are no other thread suspension mechanisms in Hotspot except polling, _except_ for the implementation of Thread::stop, Thread::suspend and Thread::resume, all of which are deprecated. Hotspot doesn't use uncooperative thread suspension for the same reason these methods are deprecated, namely the possibility of deadlock. Also, solaris and linux have problems with delivering spurious signals, untimely signals (the target thread may not run for a long time after it's signaled), and even never-delivered signals. frequency_counter_overflow_inner() cranks up an asynch compile as you describe, but then immediately calls lookup_osr_nmethod_for(), which returns NULL if the OSR compile isn't finished yet, which causes frequency_counter_overflow_inner() to return NULL after resetting the back branch overflow counter to a smaller value. via reset_counter_for_back_branch_event(). If you go all the way back to the interpreter's call to frequency_counter_overflow in, e.g., interp_masm_sparc.cpp, you see that if the interpreter gets NULL back, it just keeps going in the interpreter with the newly reduced backbranch counter threshold. Hopefully by the time the counter overflows again, the compilation will be done. Regards, Paul Krystal Mok wrote: > Hello Paul, > > This is Kris Mok. I read the slides for your presentation in > Princeton, here: > http://www.cs.princeton.edu/picasso/mats/HotspotOverview.pdf > > I'd like to ask a few questions: > On page 8 of the slides, it says OSR is synchronous, but I seem to > find that compilations triggered by backedge counter overflow isn't > always synchronous -- it's controlled by BackgroundCompilation flag in > CompileBroker. I found in interpterRuntime.cpp, in > method InterpreterRuntime::frequency_counter_overflow(), the call that > triggers OSR compilation is: > CompilationPolicy::policy()->method_back_branch_event(method, > branch_bci, bci, CHECK_NULL); > and then all the way into CompileBroker::is_compile_blocking(), which > just returns !BackgroundCompilation. If BackgroundCompilation is true > (which is so by default) than the compilation would go asynchronous, > returning null to the interpreter, and carry on interpreting until the > next time there's a chance to switch to compiled code. > Did I miss anything? Is OSR actually synchronous when triggered by > backedge overflow? And is OSR synchronous in deoptimization? > > Another question would be: are there any other thread suspension > mechanisms used in HotSpot other than polling? Does it ever do thread > hijacking or hard suspension or the like? > > Thank you in advance. Hopefully this email isn't too much of a > trouble. ^_^ > > Sincerely, > Kris Mok From Christian.Thalinger at Sun.COM Tue Mar 16 05:50:49 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 16 Mar 2010 13:50:49 +0100 Subject: Request for reviews (M): 6934966: JSR 292 add C1 logic for saved SP over MethodHandle calls In-Reply-To: References: <1268671394.9148.18.camel@macbook> Message-ID: <1268743849.26240.2.camel@macbook> On Mon, 2010-03-15 at 10:37 -0700, Tom Rodriguez wrote: > If you want to keep what you have I'm not against that but it's more > complicated than it really needs to be. Here is the simplified version: http://cr.openjdk.java.net/~twisti/6934966/webrev.02/ -- Christian From Christian.Thalinger at Sun.COM Tue Mar 16 05:54:26 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 16 Mar 2010 12:54:26 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6934494: JSR 292 MethodHandles adapters should be generated into their own CodeBlob Message-ID: <20100316125429.8079044DAA@hg.openjdk.java.net> Changeset: 9eba43136cb5 Author: twisti Date: 2010-03-16 11:52 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9eba43136cb5 6934494: JSR 292 MethodHandles adapters should be generated into their own CodeBlob Summary: Passing a null pointer to an InvokeDynamic function call should lead to a NullPointerException. Reviewed-by: kvn, never ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/codeBlob.hpp ! src/share/vm/includeDB_core ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp From rednaxelafx at gmail.com Mon Mar 15 18:41:15 2010 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 16 Mar 2010 09:41:15 +0800 Subject: A question on HotSpot's compilation triggering In-Reply-To: <4B9EC59E.20904@oracle.com> References: <4B9EBB4A.8000001@sun.com> <4B9EC59E.20904@oracle.com> Message-ID: @Paul Hohensee @David Holmes Thank you both so much for taking the time to answer my question. It really helped. HotSpot is such a beast that it's so hard to be certain about details in a comprehensive way. Counting on you guys for further details. Thanks again! Sincerely, Kris Mok On Tue, Mar 16, 2010 at 7:41 AM, David Holmes wrote: > Paul Hohensee said the following on 03/16/10 08:57: > > Third question answer is that there are no other thread suspension >> mechanisms in Hotspot except polling, _except_ for the implementation >> of Thread::stop, Thread::suspend and Thread::resume, all of which are >> deprecated. >> > > Just to clarify, even the deprecated suspend/stop use polling based > mechanisms these days. A thread is only suspended, or throws an > async-exception, when it is safe to do so with regard to its execution in > the VM. > > The only place we use signals to mimic suspend/resume type functionality is > profiling the VMThread by the FlatProfiler. > > Cheers, > David Holmes > > > Hotspot doesn't use uncooperative thread suspension for > >> the same reason these methods are deprecated, namely the possibility >> of deadlock. Also, solaris and linux have problems with delivering >> spurious signals, untimely signals (the target thread may not run for >> a long time after it's signaled), and even never-delivered signals. >> >> frequency_counter_overflow_inner() cranks up an asynch compile as you >> describe, but then immediately calls lookup_osr_nmethod_for(), which >> returns NULL if the OSR compile isn't finished yet, which causes >> frequency_counter_overflow_inner() to return NULL after resetting the >> back branch overflow counter to a smaller value. via >> reset_counter_for_back_branch_event(). If you go all the way back to >> the interpreter's call to frequency_counter_overflow in, e.g., >> interp_masm_sparc.cpp, you see that if the interpreter gets NULL >> back, it just keeps going in the interpreter with the newly reduced >> backbranch counter threshold. Hopefully by the time the counter >> overflows again, the compilation will be done. >> >> Regards, >> >> Paul >> >> Krystal Mok wrote: >> >>> Hello Paul, >>> >>> This is Kris Mok. I read the slides for your presentation in Princeton, >>> here: http://www.cs.princeton.edu/picasso/mats/HotspotOverview.pdf >>> >>> I'd like to ask a few questions: On page 8 of the slides, it says >>> OSR is synchronous, but I seem to find that compilations triggered >>> by backedge counter overflow isn't always synchronous -- it's >>> controlled by BackgroundCompilation flag in CompileBroker. I found >>> in interpterRuntime.cpp, in method >>> InterpreterRuntime::frequency_counter_overflow(), the call that triggers OSR >>> compilation is: >>> CompilationPolicy::policy()->method_back_branch_event(method, branch_bci, >>> bci, CHECK_NULL); and then all the way into >>> CompileBroker::is_compile_blocking(), which just returns >>> !BackgroundCompilation. If BackgroundCompilation is true (which is >>> so by default) than the compilation would go asynchronous, returning null >>> to the interpreter, and carry on interpreting until >>> the next time there's a chance to switch to compiled code. Did I >>> miss anything? Is OSR actually synchronous when triggered by backedge >>> overflow? And is OSR synchronous in deoptimization? >>> >>> Another question would be: are there any other thread suspension >>> mechanisms used in HotSpot other than polling? Does it ever do >>> thread hijacking or hard suspension or the like? >>> >>> Thank you in advance. Hopefully this email isn't too much of a trouble. >>> ^_^ >>> >>> Sincerely, Kris Mok >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100316/c7a21bb2/attachment.html From John.Rose at Sun.COM Tue Mar 16 09:45:16 2010 From: John.Rose at Sun.COM (John Rose) Date: Tue, 16 Mar 2010 09:45:16 -0700 Subject: Request for reviews (M): 6934966: JSR 292 add C1 logic for saved SP over MethodHandle calls In-Reply-To: <1268743849.26240.2.camel@macbook> References: <1268671394.9148.18.camel@macbook> <1268743849.26240.2.camel@macbook> Message-ID: It looks good. -- John On Mar 16, 2010, at 5:50 AM, Christian Thalinger wrote: > On Mon, 2010-03-15 at 10:37 -0700, Tom Rodriguez wrote: >> If you want to keep what you have I'm not against that but it's more >> complicated than it really needs to be. > > Here is the simplified version: > > http://cr.openjdk.java.net/~twisti/6934966/webrev.02/ > > -- Christian > From Vladimir.Kozlov at Sun.COM Tue Mar 16 10:46:36 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Mar 2010 10:46:36 -0700 Subject: review (S) for 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I In-Reply-To: <6FF17904-7A7B-4FC5-961B-618E46239449@Sun.COM> References: <4B9AC8BD.70006@sun.com> <4B9ADD79.3030801@sun.com> <6FF17904-7A7B-4FC5-961B-618E46239449@Sun.COM> Message-ID: <4B9FC3FC.1080807@sun.com> I don't remember I responded on this. I think you should use lower_bound_proj as input for upper proj: ProjNode* upper_bound_proj = create_new_if_for_predicate(predicate_proj); Can you add to the next comment what you said in mail "late schedule may move invariant things inside the loop body"? To remember why we need this clone. // Perform cloning to keep Invariance state correct You should call _igvn.hash_delete() when you change boolean input for new_predicate_iff, upper_bound_iff and lower_bound_iff. Thanks, Vladimir Tom Rodriguez wrote: > It can have side effects because of the order that PhaseIdealLoop schedules things. It performs a late schedule so invariant things can end up inside the loop body if they are only used in the loop. The makes identifying loop members simpler but the Invariance helper class is used by the predication code to make clones outside the loop so that truly invariant values will appear invariant. So I've rearranged the code a bit more so we any values we clone are create with the control of the higher if. I've also redistributed some code which was shared before since I think it obfuscated what was really happening, particular once we needed to have two new ifs in the range check case. I'm running CTW to make sure that some of the asserts I added don't fail but it works the same as before. I've updated the webrev. > > tom > > On Mar 12, 2010, at 4:34 PM, Vladimir Kozlov wrote: > >> Fine. But as we discussed you need to verify that invar.clone() does not have any side effects. >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> That's what I get for doing edits just before generating the webrev. I'd originally deleted the clone since it seems useless. If it's invariant then cloning it doesn't change anything. I chickened out at the last minuted and restored but didn't recompile. I think I'll stick with deleting it. I've regenerated the webrev. >>> tom >>> On Mar 12, 2010, at 3:05 PM, Vladimir Kozlov wrote: >>>> Tom, >>>> >>>> You removed lines 2225,2226 but where ctrl node comes from for next line?: >>>> >>>> 2243 ld_rng = (LoadRangeNode*)invar.clone(ld_rng, ctrl); >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/6930043 >>>>> 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I >>>>> Reviewed-by: >>>>> The new loop predication code is missing logic to test that the >>>>> initial value of the index is in range. In many cases will be >>>>> eliminated statically. Tested with failing test. Also tested that >>>>> this new test doesn't affect the performance improvement we were >>>>> seeing with scimark. >>>>> src/share/vm/opto/loopTransform.cpp >>>>> test/compiler/6930043/Test6930043.java > From Thomas.Rodriguez at Sun.COM Tue Mar 16 11:09:55 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 16 Mar 2010 11:09:55 -0700 Subject: review (S) for 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I In-Reply-To: <4B9FC3FC.1080807@sun.com> References: <4B9AC8BD.70006@sun.com> <4B9ADD79.3030801@sun.com> <6FF17904-7A7B-4FC5-961B-618E46239449@Sun.COM> <4B9FC3FC.1080807@sun.com> Message-ID: On Mar 16, 2010, at 10:46 AM, Vladimir Kozlov wrote: > I don't remember I responded on this. > > I think you should use lower_bound_proj as input for upper proj: > > ProjNode* upper_bound_proj = create_new_if_for_predicate(predicate_proj); Why? That's not the usage model of create_new_if_for_predicate. ProjNode* PhaseIdealLoop::create_new_if_for_predicate(ProjNode* cont_proj) { assert(is_uncommon_trap_if_pattern(cont_proj, true), "must be a uct if pattern!"); I think it would assert if I passed something else and it wouldn't improve the code shape even if I did. > > Can you add to the next comment what you said in mail "late schedule may move invariant things inside the loop body"? > To remember why we need this clone. > > // Perform cloning to keep Invariance state correct ok. > You should call _igvn.hash_delete() when you change boolean input for new_predicate_iff, upper_bound_iff and lower_bound_iff. Calling hash_delete implies something which isn't true about the nodes since they are newly created and I found it confusing when I first read it which is why I removed it. I guess it would be more consistent with the other code in loop opts which pretty much always calls hash_delete. I'll restore it. tom > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> It can have side effects because of the order that PhaseIdealLoop schedules things. It performs a late schedule so invariant things can end up inside the loop body if they are only used in the loop. The makes identifying loop members simpler but the Invariance helper class is used by the predication code to make clones outside the loop so that truly invariant values will appear invariant. So I've rearranged the code a bit more so we any values we clone are create with the control of the higher if. I've also redistributed some code which was shared before since I think it obfuscated what was really happening, particular once we needed to have two new ifs in the range check case. I'm running CTW to make sure that some of the asserts I added don't fail but it works the same as before. I've updated the webrev. >> tom >> On Mar 12, 2010, at 4:34 PM, Vladimir Kozlov wrote: >>> Fine. But as we discussed you need to verify that invar.clone() does not have any side effects. >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> That's what I get for doing edits just before generating the webrev. I'd originally deleted the clone since it seems useless. If it's invariant then cloning it doesn't change anything. I chickened out at the last minuted and restored but didn't recompile. I think I'll stick with deleting it. I've regenerated the webrev. >>>> tom >>>> On Mar 12, 2010, at 3:05 PM, Vladimir Kozlov wrote: >>>>> Tom, >>>>> >>>>> You removed lines 2225,2226 but where ctrl node comes from for next line?: >>>>> >>>>> 2243 ld_rng = (LoadRangeNode*)invar.clone(ld_rng, ctrl); >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> http://cr.openjdk.java.net/~never/6930043 >>>>>> 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I >>>>>> Reviewed-by: >>>>>> The new loop predication code is missing logic to test that the >>>>>> initial value of the index is in range. In many cases will be >>>>>> eliminated statically. Tested with failing test. Also tested that >>>>>> this new test doesn't affect the performance improvement we were >>>>>> seeing with scimark. >>>>>> src/share/vm/opto/loopTransform.cpp >>>>>> test/compiler/6930043/Test6930043.java From Vladimir.Kozlov at Sun.COM Tue Mar 16 11:17:59 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Mar 2010 11:17:59 -0700 Subject: review (S) for 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I In-Reply-To: References: <4B9AC8BD.70006@sun.com> <4B9ADD79.3030801@sun.com> <6FF17904-7A7B-4FC5-961B-618E46239449@Sun.COM> <4B9FC3FC.1080807@sun.com> Message-ID: <4B9FCB57.5070306@sun.com> Tom Rodriguez wrote: > On Mar 16, 2010, at 10:46 AM, Vladimir Kozlov wrote: > >> I think you should use lower_bound_proj as input for upper proj: >> ProjNode* upper_bound_proj = create_new_if_for_predicate(predicate_proj); > > Why? That's not the usage model of create_new_if_for_predicate. Then you have to swap next lines, otherwise upper_bound will be generated above lower_bound 2267 ProjNode* lower_bound_proj = create_new_if_for_predicate(predicate_proj); 2268 ProjNode* upper_bound_proj = create_new_if_for_predicate(predicate_proj); Vladimir > > ProjNode* PhaseIdealLoop::create_new_if_for_predicate(ProjNode* cont_proj) { > assert(is_uncommon_trap_if_pattern(cont_proj, true), "must be a uct if pattern!"); > > I think it would assert if I passed something else and it wouldn't improve the code shape even if I did. > >> Can you add to the next comment what you said in mail "late schedule may move invariant things inside the loop body"? >> To remember why we need this clone. >> >> // Perform cloning to keep Invariance state correct > > ok. > > >> You should call _igvn.hash_delete() when you change boolean input for new_predicate_iff, upper_bound_iff and lower_bound_iff. > > Calling hash_delete implies something which isn't true about the nodes since they are newly created and I found it confusing when I first read it which is why I removed it. I guess it would be more consistent with the other code in loop opts which pretty much always calls hash_delete. I'll restore it. > > tom > >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> It can have side effects because of the order that PhaseIdealLoop schedules things. It performs a late schedule so invariant things can end up inside the loop body if they are only used in the loop. The makes identifying loop members simpler but the Invariance helper class is used by the predication code to make clones outside the loop so that truly invariant values will appear invariant. So I've rearranged the code a bit more so we any values we clone are create with the control of the higher if. I've also redistributed some code which was shared before since I think it obfuscated what was really happening, particular once we needed to have two new ifs in the range check case. I'm running CTW to make sure that some of the asserts I added don't fail but it works the same as before. I've updated the webrev. >>> tom >>> On Mar 12, 2010, at 4:34 PM, Vladimir Kozlov wrote: >>>> Fine. But as we discussed you need to verify that invar.clone() does not have any side effects. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> That's what I get for doing edits just before generating the webrev. I'd originally deleted the clone since it seems useless. If it's invariant then cloning it doesn't change anything. I chickened out at the last minuted and restored but didn't recompile. I think I'll stick with deleting it. I've regenerated the webrev. >>>>> tom >>>>> On Mar 12, 2010, at 3:05 PM, Vladimir Kozlov wrote: >>>>>> Tom, >>>>>> >>>>>> You removed lines 2225,2226 but where ctrl node comes from for next line?: >>>>>> >>>>>> 2243 ld_rng = (LoadRangeNode*)invar.clone(ld_rng, ctrl); >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> http://cr.openjdk.java.net/~never/6930043 >>>>>>> 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I >>>>>>> Reviewed-by: >>>>>>> The new loop predication code is missing logic to test that the >>>>>>> initial value of the index is in range. In many cases will be >>>>>>> eliminated statically. Tested with failing test. Also tested that >>>>>>> this new test doesn't affect the performance improvement we were >>>>>>> seeing with scimark. >>>>>>> src/share/vm/opto/loopTransform.cpp >>>>>>> test/compiler/6930043/Test6930043.java > From Thomas.Rodriguez at Sun.COM Tue Mar 16 11:39:06 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 16 Mar 2010 11:39:06 -0700 Subject: review (S) for 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I In-Reply-To: <4B9FCB57.5070306@sun.com> References: <4B9AC8BD.70006@sun.com> <4B9ADD79.3030801@sun.com> <6FF17904-7A7B-4FC5-961B-618E46239449@Sun.COM> <4B9FC3FC.1080807@sun.com> <4B9FCB57.5070306@sun.com> Message-ID: <3C46819B-6212-405D-8109-6C725F27CB35@Sun.COM> On Mar 16, 2010, at 11:17 AM, Vladimir Kozlov wrote: > > > Tom Rodriguez wrote: >> On Mar 16, 2010, at 10:46 AM, Vladimir Kozlov wrote: >>> I think you should use lower_bound_proj as input for upper proj: >>> ProjNode* upper_bound_proj = create_new_if_for_predicate(predicate_proj); >> Why? That's not the usage model of create_new_if_for_predicate. > > Then you have to swap next lines, otherwise upper_bound will be generated above lower_bound > > 2267 ProjNode* lower_bound_proj = create_new_if_for_predicate(predicate_proj); > 2268 ProjNode* upper_bound_proj = create_new_if_for_predicate(predicate_proj); create_new_if_for_predicate inserts a new if between the trap place holder if and the last created if. I'd added an assert that verified the ordering but I guess I never updated the webrev itself. It's there now and it looks like this: + assert(upper_bound_proj->in(0)->as_If()->in(0) == lower_bound_proj, "should dominate"); tom > > Vladimir > >> ProjNode* PhaseIdealLoop::create_new_if_for_predicate(ProjNode* cont_proj) { >> assert(is_uncommon_trap_if_pattern(cont_proj, true), "must be a uct if pattern!"); >> I think it would assert if I passed something else and it wouldn't improve the code shape even if I did. >>> Can you add to the next comment what you said in mail "late schedule may move invariant things inside the loop body"? >>> To remember why we need this clone. >>> >>> // Perform cloning to keep Invariance state correct >> ok. >>> You should call _igvn.hash_delete() when you change boolean input for new_predicate_iff, upper_bound_iff and lower_bound_iff. >> Calling hash_delete implies something which isn't true about the nodes since they are newly created and I found it confusing when I first read it which is why I removed it. I guess it would be more consistent with the other code in loop opts which pretty much always calls hash_delete. I'll restore it. >> tom >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> It can have side effects because of the order that PhaseIdealLoop schedules things. It performs a late schedule so invariant things can end up inside the loop body if they are only used in the loop. The makes identifying loop members simpler but the Invariance helper class is used by the predication code to make clones outside the loop so that truly invariant values will appear invariant. So I've rearranged the code a bit more so we any values we clone are create with the control of the higher if. I've also redistributed some code which was shared before since I think it obfuscated what was really happening, particular once we needed to have two new ifs in the range check case. I'm running CTW to make sure that some of the asserts I added don't fail but it works the same as before. I've updated the webrev. >>>> tom >>>> On Mar 12, 2010, at 4:34 PM, Vladimir Kozlov wrote: >>>>> Fine. But as we discussed you need to verify that invar.clone() does not have any side effects. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> That's what I get for doing edits just before generating the webrev. I'd originally deleted the clone since it seems useless. If it's invariant then cloning it doesn't change anything. I chickened out at the last minuted and restored but didn't recompile. I think I'll stick with deleting it. I've regenerated the webrev. >>>>>> tom >>>>>> On Mar 12, 2010, at 3:05 PM, Vladimir Kozlov wrote: >>>>>>> Tom, >>>>>>> >>>>>>> You removed lines 2225,2226 but where ctrl node comes from for next line?: >>>>>>> >>>>>>> 2243 ld_rng = (LoadRangeNode*)invar.clone(ld_rng, ctrl); >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> http://cr.openjdk.java.net/~never/6930043 >>>>>>>> 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I >>>>>>>> Reviewed-by: >>>>>>>> The new loop predication code is missing logic to test that the >>>>>>>> initial value of the index is in range. In many cases will be >>>>>>>> eliminated statically. Tested with failing test. Also tested that >>>>>>>> this new test doesn't affect the performance improvement we were >>>>>>>> seeing with scimark. >>>>>>>> src/share/vm/opto/loopTransform.cpp >>>>>>>> test/compiler/6930043/Test6930043.java From Vladimir.Kozlov at Sun.COM Tue Mar 16 13:59:01 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Mar 2010 13:59:01 -0700 Subject: review (S) for 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I In-Reply-To: <3C46819B-6212-405D-8109-6C725F27CB35@Sun.COM> References: <4B9AC8BD.70006@sun.com> <4B9ADD79.3030801@sun.com> <6FF17904-7A7B-4FC5-961B-618E46239449@Sun.COM> <4B9FC3FC.1080807@sun.com> <4B9FCB57.5070306@sun.com> <3C46819B-6212-405D-8109-6C725F27CB35@Sun.COM> Message-ID: <4B9FF115.4060105@sun.com> Yes, I was wrong, it is inserted in between. The assert is good. But I don't see updated comment and hash_delete() calls. Vladimir Tom Rodriguez wrote: > On Mar 16, 2010, at 11:17 AM, Vladimir Kozlov wrote: > >> >> Tom Rodriguez wrote: >>> On Mar 16, 2010, at 10:46 AM, Vladimir Kozlov wrote: >>>> I think you should use lower_bound_proj as input for upper proj: >>>> ProjNode* upper_bound_proj = create_new_if_for_predicate(predicate_proj); >>> Why? That's not the usage model of create_new_if_for_predicate. >> Then you have to swap next lines, otherwise upper_bound will be generated above lower_bound >> >> 2267 ProjNode* lower_bound_proj = create_new_if_for_predicate(predicate_proj); >> 2268 ProjNode* upper_bound_proj = create_new_if_for_predicate(predicate_proj); > > create_new_if_for_predicate inserts a new if between the trap place holder if and the last created if. I'd added an assert that verified the ordering but I guess I never updated the webrev itself. It's there now and it looks like this: > > + assert(upper_bound_proj->in(0)->as_If()->in(0) == lower_bound_proj, "should dominate"); > > tom > >> Vladimir >> >>> ProjNode* PhaseIdealLoop::create_new_if_for_predicate(ProjNode* cont_proj) { >>> assert(is_uncommon_trap_if_pattern(cont_proj, true), "must be a uct if pattern!"); >>> I think it would assert if I passed something else and it wouldn't improve the code shape even if I did. >>>> Can you add to the next comment what you said in mail "late schedule may move invariant things inside the loop body"? >>>> To remember why we need this clone. >>>> >>>> // Perform cloning to keep Invariance state correct >>> ok. >>>> You should call _igvn.hash_delete() when you change boolean input for new_predicate_iff, upper_bound_iff and lower_bound_iff. >>> Calling hash_delete implies something which isn't true about the nodes since they are newly created and I found it confusing when I first read it which is why I removed it. I guess it would be more consistent with the other code in loop opts which pretty much always calls hash_delete. I'll restore it. >>> tom >>>> Thanks, >>>> Vladimir >>>> >>>> Tom Rodriguez wrote: >>>>> It can have side effects because of the order that PhaseIdealLoop schedules things. It performs a late schedule so invariant things can end up inside the loop body if they are only used in the loop. The makes identifying loop members simpler but the Invariance helper class is used by the predication code to make clones outside the loop so that truly invariant values will appear invariant. So I've rearranged the code a bit more so we any values we clone are create with the control of the higher if. I've also redistributed some code which was shared before since I think it obfuscated what was really happening, particular once we needed to have two new ifs in the range check case. I'm running CTW to make sure that some of the asserts I added don't fail but it works the same as before. I've updated the webrev. >>>>> tom >>>>> On Mar 12, 2010, at 4:34 PM, Vladimir Kozlov wrote: >>>>>> Fine. But as we discussed you need to verify that invar.clone() does not have any side effects. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> That's what I get for doing edits just before generating the webrev. I'd originally deleted the clone since it seems useless. If it's invariant then cloning it doesn't change anything. I chickened out at the last minuted and restored but didn't recompile. I think I'll stick with deleting it. I've regenerated the webrev. >>>>>>> tom >>>>>>> On Mar 12, 2010, at 3:05 PM, Vladimir Kozlov wrote: >>>>>>>> Tom, >>>>>>>> >>>>>>>> You removed lines 2225,2226 but where ctrl node comes from for next line?: >>>>>>>> >>>>>>>> 2243 ld_rng = (LoadRangeNode*)invar.clone(ld_rng, ctrl); >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> Tom Rodriguez wrote: >>>>>>>>> http://cr.openjdk.java.net/~never/6930043 >>>>>>>>> 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I >>>>>>>>> Reviewed-by: >>>>>>>>> The new loop predication code is missing logic to test that the >>>>>>>>> initial value of the index is in range. In many cases will be >>>>>>>>> eliminated statically. Tested with failing test. Also tested that >>>>>>>>> this new test doesn't affect the performance improvement we were >>>>>>>>> seeing with scimark. >>>>>>>>> src/share/vm/opto/loopTransform.cpp >>>>>>>>> test/compiler/6930043/Test6930043.java > From Vladimir.Kozlov at Sun.COM Tue Mar 16 15:04:50 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Mar 2010 15:04:50 -0700 Subject: Request for reviews (XS): 6931465: Switch off by default optimization flags in HS17] Message-ID: <4BA00082.6060204@sun.com> http://cr.openjdk.java.net/~kvn/6935466/webrev Fixed 6935466: new CodeCache flushing code is not guarded by the flag Add missing guard. From Thomas.Rodriguez at Sun.COM Tue Mar 16 15:32:11 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Tue, 16 Mar 2010 15:32:11 -0700 Subject: Request for reviews (XS): 6931465: Switch off by default optimization flags in HS17] In-Reply-To: <4BA00082.6060204@sun.com> References: <4BA00082.6060204@sun.com> Message-ID: <0D75AB8C-B928-4F81-A041-B095865406B0@sun.com> Looks good. tom On Mar 16, 2010, at 3:04 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6935466/webrev > > Fixed 6935466: new CodeCache flushing code is not guarded by the flag > > Add missing guard. > From Vladimir.Kozlov at Sun.COM Tue Mar 16 15:34:48 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Mar 2010 15:34:48 -0700 Subject: Request for reviews (XS): 6931465: Switch off by default optimization flags in HS17] In-Reply-To: <0D75AB8C-B928-4F81-A041-B095865406B0@sun.com> References: <4BA00082.6060204@sun.com> <0D75AB8C-B928-4F81-A041-B095865406B0@sun.com> Message-ID: <4BA00788.8010607@sun.com> Thanks, Tom Vladimir Tom Rodriguez wrote: > Looks good. > > tom > > On Mar 16, 2010, at 3:04 PM, Vladimir Kozlov > wrote: > >> http://cr.openjdk.java.net/~kvn/6935466/webrev >> >> Fixed 6935466: new CodeCache flushing code is not guarded by the flag >> >> Add missing guard. >> From vladimir.kozlov at sun.com Tue Mar 16 18:08:52 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 17 Mar 2010 01:08:52 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6935466: new CodeCache flushing code is not guarded by the flag Message-ID: <20100317010855.B9B8044E61@hg.openjdk.java.net> Changeset: 428a9c451986 Author: kvn Date: 2010-03-16 15:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/428a9c451986 6935466: new CodeCache flushing code is not guarded by the flag Summary: Add missing guard. Reviewed-by: never ! src/share/vm/compiler/compileBroker.cpp From Vladimir.Kozlov at Sun.COM Tue Mar 16 19:15:29 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Tue, 16 Mar 2010 19:15:29 -0700 Subject: Request for reviews (XS): 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 Message-ID: <4BA03B41.3040103@sun.com> http://cr.openjdk.java.net/~kvn/6935535/webrev Fixed 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 Added missing counter decrement when substring search restarted. Added regression test. From Christian.Thalinger at Sun.COM Wed Mar 17 05:40:30 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 17 Mar 2010 13:40:30 +0100 Subject: Request for reviews (M): 6932091: JSR 292 x86 code cleanup Message-ID: <1268829630.26240.38.camel@macbook> http://cr.openjdk.java.net/~twisti/6932091/webrev.01/ Some code cleanups found during the JSR 292 SPARC port. Additionally TaggedStackInterpreter is disabled when MethodHandles are enabled as the MethodHandles code does not support TaggedStackInterpreter. src/cpu/x86/vm/methodHandles_x86.cpp src/cpu/x86/vm/templateTable_x86_32.cpp src/cpu/x86/vm/templateTable_x86_64.cpp src/share/vm/c1/c1_LIRGenerator.cpp src/share/vm/prims/methodHandles.hpp src/share/vm/runtime/arguments.cpp From Christian.Thalinger at Sun.COM Wed Mar 17 05:44:18 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 17 Mar 2010 13:44:18 +0100 Subject: Request for reviews (XS): 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 In-Reply-To: <4BA03B41.3040103@sun.com> References: <4BA03B41.3040103@sun.com> Message-ID: <1268829858.26240.39.camel@macbook> On Tue, 2010-03-16 at 19:15 -0700, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6935535/webrev > > Fixed 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 > > Added missing counter decrement when substring search restarted. > Added regression test. Looks good. -- Christian From Christian.Thalinger at Sun.COM Wed Mar 17 07:24:56 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 17 Mar 2010 14:24:56 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6934966: JSR 292 add C1 logic for saved SP over MethodHandle calls Message-ID: <20100317142502.0274744F20@hg.openjdk.java.net> Changeset: fc2c71045ada Author: twisti Date: 2010-03-17 10:22 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fc2c71045ada 6934966: JSR 292 add C1 logic for saved SP over MethodHandle calls Summary: The logic for x86 C1 to save the SP over MH calls is pretty straight forward but SPARC handles that differently. Reviewed-by: never, jrose ! src/cpu/sparc/vm/c1_FrameMap_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp From Vladimir.Kozlov at Sun.COM Wed Mar 17 09:32:44 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 17 Mar 2010 09:32:44 -0700 Subject: Request for reviews (XS): 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 In-Reply-To: <1268829858.26240.39.camel@macbook> References: <4BA03B41.3040103@sun.com> <1268829858.26240.39.camel@macbook> Message-ID: <4BA1042C.3060203@sun.com> Thank you, Christian Vladimir Christian Thalinger wrote: > On Tue, 2010-03-16 at 19:15 -0700, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/6935535/webrev >> >> Fixed 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 >> >> Added missing counter decrement when substring search restarted. >> Added regression test. > > Looks good. -- Christian > From Thomas.Rodriguez at Sun.COM Wed Mar 17 10:06:37 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 17 Mar 2010 10:06:37 -0700 Subject: review (S) for 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I In-Reply-To: <4B9FF115.4060105@sun.com> References: <4B9AC8BD.70006@sun.com> <4B9ADD79.3030801@sun.com> <6FF17904-7A7B-4FC5-961B-618E46239449@Sun.COM> <4B9FC3FC.1080807@sun.com> <4B9FCB57.5070306@sun.com> <3C46819B-6212-405D-8109-6C725F27CB35@Sun.COM> <4B9FF115.4060105@sun.com> Message-ID: It's updated now. tom On Mar 16, 2010, at 1:59 PM, Vladimir Kozlov wrote: > Yes, I was wrong, it is inserted in between. The assert is good. > But I don't see updated comment and hash_delete() calls. > > Vladimir > > Tom Rodriguez wrote: >> On Mar 16, 2010, at 11:17 AM, Vladimir Kozlov wrote: >>> >>> Tom Rodriguez wrote: >>>> On Mar 16, 2010, at 10:46 AM, Vladimir Kozlov wrote: >>>>> I think you should use lower_bound_proj as input for upper proj: >>>>> ProjNode* upper_bound_proj = create_new_if_for_predicate(predicate_proj); >>>> Why? That's not the usage model of create_new_if_for_predicate. >>> Then you have to swap next lines, otherwise upper_bound will be generated above lower_bound >>> >>> 2267 ProjNode* lower_bound_proj = create_new_if_for_predicate(predicate_proj); >>> 2268 ProjNode* upper_bound_proj = create_new_if_for_predicate(predicate_proj); >> create_new_if_for_predicate inserts a new if between the trap place holder if and the last created if. I'd added an assert that verified the ordering but I guess I never updated the webrev itself. It's there now and it looks like this: >> + assert(upper_bound_proj->in(0)->as_If()->in(0) == lower_bound_proj, "should dominate"); >> tom >>> Vladimir >>> >>>> ProjNode* PhaseIdealLoop::create_new_if_for_predicate(ProjNode* cont_proj) { >>>> assert(is_uncommon_trap_if_pattern(cont_proj, true), "must be a uct if pattern!"); >>>> I think it would assert if I passed something else and it wouldn't improve the code shape even if I did. >>>>> Can you add to the next comment what you said in mail "late schedule may move invariant things inside the loop body"? >>>>> To remember why we need this clone. >>>>> >>>>> // Perform cloning to keep Invariance state correct >>>> ok. >>>>> You should call _igvn.hash_delete() when you change boolean input for new_predicate_iff, upper_bound_iff and lower_bound_iff. >>>> Calling hash_delete implies something which isn't true about the nodes since they are newly created and I found it confusing when I first read it which is why I removed it. I guess it would be more consistent with the other code in loop opts which pretty much always calls hash_delete. I'll restore it. >>>> tom >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Tom Rodriguez wrote: >>>>>> It can have side effects because of the order that PhaseIdealLoop schedules things. It performs a late schedule so invariant things can end up inside the loop body if they are only used in the loop. The makes identifying loop members simpler but the Invariance helper class is used by the predication code to make clones outside the loop so that truly invariant values will appear invariant. So I've rearranged the code a bit more so we any values we clone are create with the control of the higher if. I've also redistributed some code which was shared before since I think it obfuscated what was really happening, particular once we needed to have two new ifs in the range check case. I'm running CTW to make sure that some of the asserts I added don't fail but it works the same as before. I've updated the webrev. >>>>>> tom >>>>>> On Mar 12, 2010, at 4:34 PM, Vladimir Kozlov wrote: >>>>>>> Fine. But as we discussed you need to verify that invar.clone() does not have any side effects. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> Tom Rodriguez wrote: >>>>>>>> That's what I get for doing edits just before generating the webrev. I'd originally deleted the clone since it seems useless. If it's invariant then cloning it doesn't change anything. I chickened out at the last minuted and restored but didn't recompile. I think I'll stick with deleting it. I've regenerated the webrev. >>>>>>>> tom >>>>>>>> On Mar 12, 2010, at 3:05 PM, Vladimir Kozlov wrote: >>>>>>>>> Tom, >>>>>>>>> >>>>>>>>> You removed lines 2225,2226 but where ctrl node comes from for next line?: >>>>>>>>> >>>>>>>>> 2243 ld_rng = (LoadRangeNode*)invar.clone(ld_rng, ctrl); >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>> http://cr.openjdk.java.net/~never/6930043 >>>>>>>>>> 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I >>>>>>>>>> Reviewed-by: >>>>>>>>>> The new loop predication code is missing logic to test that the >>>>>>>>>> initial value of the index is in range. In many cases will be >>>>>>>>>> eliminated statically. Tested with failing test. Also tested that >>>>>>>>>> this new test doesn't affect the performance improvement we were >>>>>>>>>> seeing with scimark. >>>>>>>>>> src/share/vm/opto/loopTransform.cpp >>>>>>>>>> test/compiler/6930043/Test6930043.java From Vladimir.Kozlov at Sun.COM Wed Mar 17 10:36:15 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 17 Mar 2010 10:36:15 -0700 Subject: review (S) for 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I In-Reply-To: References: <4B9AC8BD.70006@sun.com> <4B9ADD79.3030801@sun.com> <6FF17904-7A7B-4FC5-961B-618E46239449@Sun.COM> <4B9FC3FC.1080807@sun.com> <4B9FCB57.5070306@sun.com> <3C46819B-6212-405D-8109-6C725F27CB35@Sun.COM> <4B9FF115.4060105@sun.com> Message-ID: <4BA1130F.2050103@sun.com> Looks good. Vladimir Tom Rodriguez wrote: > It's updated now. > > tom > > On Mar 16, 2010, at 1:59 PM, Vladimir Kozlov wrote: > >> Yes, I was wrong, it is inserted in between. The assert is good. >> But I don't see updated comment and hash_delete() calls. >> >> Vladimir >> >> Tom Rodriguez wrote: >>> On Mar 16, 2010, at 11:17 AM, Vladimir Kozlov wrote: >>>> Tom Rodriguez wrote: >>>>> On Mar 16, 2010, at 10:46 AM, Vladimir Kozlov wrote: >>>>>> I think you should use lower_bound_proj as input for upper proj: >>>>>> ProjNode* upper_bound_proj = create_new_if_for_predicate(predicate_proj); >>>>> Why? That's not the usage model of create_new_if_for_predicate. >>>> Then you have to swap next lines, otherwise upper_bound will be generated above lower_bound >>>> >>>> 2267 ProjNode* lower_bound_proj = create_new_if_for_predicate(predicate_proj); >>>> 2268 ProjNode* upper_bound_proj = create_new_if_for_predicate(predicate_proj); >>> create_new_if_for_predicate inserts a new if between the trap place holder if and the last created if. I'd added an assert that verified the ordering but I guess I never updated the webrev itself. It's there now and it looks like this: >>> + assert(upper_bound_proj->in(0)->as_If()->in(0) == lower_bound_proj, "should dominate"); >>> tom >>>> Vladimir >>>> >>>>> ProjNode* PhaseIdealLoop::create_new_if_for_predicate(ProjNode* cont_proj) { >>>>> assert(is_uncommon_trap_if_pattern(cont_proj, true), "must be a uct if pattern!"); >>>>> I think it would assert if I passed something else and it wouldn't improve the code shape even if I did. >>>>>> Can you add to the next comment what you said in mail "late schedule may move invariant things inside the loop body"? >>>>>> To remember why we need this clone. >>>>>> >>>>>> // Perform cloning to keep Invariance state correct >>>>> ok. >>>>>> You should call _igvn.hash_delete() when you change boolean input for new_predicate_iff, upper_bound_iff and lower_bound_iff. >>>>> Calling hash_delete implies something which isn't true about the nodes since they are newly created and I found it confusing when I first read it which is why I removed it. I guess it would be more consistent with the other code in loop opts which pretty much always calls hash_delete. I'll restore it. >>>>> tom >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Tom Rodriguez wrote: >>>>>>> It can have side effects because of the order that PhaseIdealLoop schedules things. It performs a late schedule so invariant things can end up inside the loop body if they are only used in the loop. The makes identifying loop members simpler but the Invariance helper class is used by the predication code to make clones outside the loop so that truly invariant values will appear invariant. So I've rearranged the code a bit more so we any values we clone are create with the control of the higher if. I've also redistributed some code which was shared before since I think it obfuscated what was really happening, particular once we needed to have two new ifs in the range check case. I'm running CTW to make sure that some of the asserts I added don't fail but it works the same as before. I've updated the webrev. >>>>>>> tom >>>>>>> On Mar 12, 2010, at 4:34 PM, Vladimir Kozlov wrote: >>>>>>>> Fine. But as we discussed you need to verify that invar.clone() does not have any side effects. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> Tom Rodriguez wrote: >>>>>>>>> That's what I get for doing edits just before generating the webrev. I'd originally deleted the clone since it seems useless. If it's invariant then cloning it doesn't change anything. I chickened out at the last minuted and restored but didn't recompile. I think I'll stick with deleting it. I've regenerated the webrev. >>>>>>>>> tom >>>>>>>>> On Mar 12, 2010, at 3:05 PM, Vladimir Kozlov wrote: >>>>>>>>>> Tom, >>>>>>>>>> >>>>>>>>>> You removed lines 2225,2226 but where ctrl node comes from for next line?: >>>>>>>>>> >>>>>>>>>> 2243 ld_rng = (LoadRangeNode*)invar.clone(ld_rng, ctrl); >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> Tom Rodriguez wrote: >>>>>>>>>>> http://cr.openjdk.java.net/~never/6930043 >>>>>>>>>>> 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I >>>>>>>>>>> Reviewed-by: >>>>>>>>>>> The new loop predication code is missing logic to test that the >>>>>>>>>>> initial value of the index is in range. In many cases will be >>>>>>>>>>> eliminated statically. Tested with failing test. Also tested that >>>>>>>>>>> this new test doesn't affect the performance improvement we were >>>>>>>>>>> seeing with scimark. >>>>>>>>>>> src/share/vm/opto/loopTransform.cpp >>>>>>>>>>> test/compiler/6930043/Test6930043.java > From Vladimir.Kozlov at Sun.COM Wed Mar 17 10:43:48 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Wed, 17 Mar 2010 10:43:48 -0700 Subject: Request for reviews (M): 6932091: JSR 292 x86 code cleanup In-Reply-To: <1268829630.26240.38.camel@macbook> References: <1268829630.26240.38.camel@macbook> Message-ID: <4BA114D4.5070604@sun.com> Looks good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6932091/webrev.01/ > > Some code cleanups found during the JSR 292 SPARC port. > > Additionally TaggedStackInterpreter is disabled when MethodHandles are > enabled as the MethodHandles code does not support > TaggedStackInterpreter. > > src/cpu/x86/vm/methodHandles_x86.cpp > src/cpu/x86/vm/templateTable_x86_32.cpp > src/cpu/x86/vm/templateTable_x86_64.cpp > src/share/vm/c1/c1_LIRGenerator.cpp > src/share/vm/prims/methodHandles.hpp > src/share/vm/runtime/arguments.cpp > > From vladimir.kozlov at sun.com Wed Mar 17 13:22:53 2010 From: vladimir.kozlov at sun.com (vladimir.kozlov at sun.com) Date: Wed, 17 Mar 2010 20:22:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 Message-ID: <20100317202310.3248C44FAF@hg.openjdk.java.net> Changeset: 2484f4d6a54e Author: kvn Date: 2010-03-17 10:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2484f4d6a54e 6935535: String.indexOf() returns incorrect result on x86 with SSE4.2 Summary: Added missing counter decrement when substring search restarted. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp + test/compiler/6935535/Test.java From Thomas.Rodriguez at Sun.COM Wed Mar 17 14:11:38 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Wed, 17 Mar 2010 14:11:38 -0700 Subject: Request for reviews (M): 6932091: JSR 292 x86 code cleanup In-Reply-To: <1268829630.26240.38.camel@macbook> References: <1268829630.26240.38.camel@macbook> Message-ID: Looks good. tom On Mar 17, 2010, at 5:40 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6932091/webrev.01/ > > Some code cleanups found during the JSR 292 SPARC port. > > Additionally TaggedStackInterpreter is disabled when MethodHandles are > enabled as the MethodHandles code does not support > TaggedStackInterpreter. > > src/cpu/x86/vm/methodHandles_x86.cpp > src/cpu/x86/vm/templateTable_x86_32.cpp > src/cpu/x86/vm/templateTable_x86_64.cpp > src/share/vm/c1/c1_LIRGenerator.cpp > src/share/vm/prims/methodHandles.hpp > src/share/vm/runtime/arguments.cpp > > From thomas.rodriguez at sun.com Wed Mar 17 18:42:10 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 18 Mar 2010 01:42:10 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I Message-ID: <20100318014215.C28EC44FFD@hg.openjdk.java.net> Changeset: c047da02984c Author: never Date: 2010-03-17 16:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c047da02984c 6930043: C2: SIGSEGV in javasoft.sqe.tests.lang.arr017.arr01702.arr01702.loop_forw(II)I Reviewed-by: kvn ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.hpp + test/compiler/6930043/Test6930043.java From Christian.Thalinger at Sun.COM Thu Mar 18 06:27:25 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 18 Mar 2010 13:27:25 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6932091: JSR 292 x86 code cleanup Message-ID: <20100318132746.E1569440B3@hg.openjdk.java.net> Changeset: 76c1d7d13ec5 Author: twisti Date: 2010-03-18 09:56 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/76c1d7d13ec5 6932091: JSR 292 x86 code cleanup Summary: Some code cleanups found during the JSR 292 SPARC port. Reviewed-by: kvn, never ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/arguments.cpp From Christian.Thalinger at Sun.COM Thu Mar 18 10:56:05 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 18 Mar 2010 17:56:05 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 5 new changesets Message-ID: <20100318175621.A76FA44111@hg.openjdk.java.net> Changeset: d47555d7aca8 Author: jmasa Date: 2010-03-03 08:10 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d47555d7aca8 6910182: CMS: assert(_cursor[j] == _survivor_plab_array[j].end(),"Ctl pt invariant") Summary: Calculation of the slicing of survivor spaces for MT was incorrect. Reviewed-by: ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: c8a467bf56ad Author: coleenp Date: 2010-03-02 12:09 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c8a467bf56ad 6914050: jvm assertion "guard pages must be in use" in -Xcomp mode Summary: Move creating stack guard pages in jni attach thread before potential java call rather than after. Also cleanup stack guard pages when jni attach fails Reviewed-by: never, dholmes ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/thread.cpp Changeset: 4b0f2f4918ed Author: xlu Date: 2010-03-10 21:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4b0f2f4918ed 6933402: RFE: Improve PrintSafepointStatistics output to track cleanup time Summary: Improve the usability of safepoint statistics data. See bug evaluation for more details. Reviewed-by: ysr, dholmes ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/safepoint.hpp Changeset: 12d91eb0f579 Author: acorn Date: 2010-03-11 14:41 -0500 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/12d91eb0f579 Merge Changeset: 97fe2cc98b1d Author: twisti Date: 2010-03-18 06:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/97fe2cc98b1d Merge From thomas.rodriguez at sun.com Thu Mar 18 23:00:29 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Fri, 19 Mar 2010 06:00:29 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6926979: should simplify catch_inline_exception Message-ID: <20100319060047.70B64441D7@hg.openjdk.java.net> Changeset: fdd57634910e Author: never Date: 2010-03-18 14:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fdd57634910e 6926979: should simplify catch_inline_exception Reviewed-by: twisti ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/globals.hpp From john.coomes at sun.com Fri Mar 19 02:08:02 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Mar 2010 09:08:02 +0000 Subject: hg: jdk7/hotspot-comp: 4 new changesets Message-ID: <20100319090802.70D6A4420A@hg.openjdk.java.net> Changeset: 4d7419e4b759 Author: ohair Date: 2010-03-06 15:00 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/4d7419e4b759 6928700: Configure top repo for JPRT testing Reviewed-by: alanb, jjg ! make/jprt.properties + test/Makefile Changeset: f3664d6879ab Author: ohair Date: 2010-03-06 15:01 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/f3664d6879ab Merge Changeset: 433a60a9c0bf Author: lana Date: 2010-03-09 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/433a60a9c0bf Merge Changeset: 6b1069f53fbc Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/6b1069f53fbc Added tag jdk7-b86 for changeset 433a60a9c0bf ! .hgtags From john.coomes at sun.com Fri Mar 19 02:08:09 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Mar 2010 09:08:09 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b86 for changeset 6253e28826d1 Message-ID: <20100319090813.6CA144420B@hg.openjdk.java.net> Changeset: 09a41111a401 Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/09a41111a401 Added tag jdk7-b86 for changeset 6253e28826d1 ! .hgtags From john.coomes at sun.com Fri Mar 19 02:12:26 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Mar 2010 09:12:26 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b86 for changeset 81c0f115bbe5 Message-ID: <20100319091226.A28194420D@hg.openjdk.java.net> Changeset: 8b493f1aa136 Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/8b493f1aa136 Added tag jdk7-b86 for changeset 81c0f115bbe5 ! .hgtags From john.coomes at sun.com Fri Mar 19 02:12:34 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Mar 2010 09:12:34 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b86 for changeset 512b0e924a5a Message-ID: <20100319091234.8F59C4420E@hg.openjdk.java.net> Changeset: 3febd6fab2ac Author: mikejwre Date: 2010-03-18 13:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/3febd6fab2ac Added tag jdk7-b86 for changeset 512b0e924a5a ! .hgtags From john.coomes at sun.com Fri Mar 19 02:13:39 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Mar 2010 09:13:39 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 40 new changesets Message-ID: <20100319092656.1753444212@hg.openjdk.java.net> Changeset: 840601ac5ab7 Author: rkennke Date: 2010-03-03 15:50 +0100 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/840601ac5ab7 6892485: Deadlock in SunGraphicsEnvironment / FontManager Summary: Synchronize on correct monitor in SunFontManager. Reviewed-by: igor, prr ! src/share/classes/sun/font/SunFontManager.java Changeset: 1d7db2d5c4c5 Author: minqi Date: 2010-03-08 11:35 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/1d7db2d5c4c5 6918065: Crash in Java2D blit loop (IntArgbToIntArgbPreSrcOverMaskBlit) in 64bit mode Reviewed-by: igor, bae ! src/share/classes/java/awt/AlphaComposite.java + test/java/awt/AlphaComposite/TestAlphaCompositeForNaN.java Changeset: 494f5e4f24da Author: lana Date: 2010-03-09 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/494f5e4f24da Merge Changeset: e64331144648 Author: rupashka Date: 2010-02-10 15:15 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e64331144648 6848475: JSlider does not display the correct value of its BoundedRangeModel Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6848475/bug6848475.java Changeset: f81c8041ccf4 Author: peytoia Date: 2010-02-11 15:58 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f81c8041ccf4 6909002: Remove indicim.jar and thaiim.jar from JRE and move to samples if needed Reviewed-by: okutsu ! make/com/sun/Makefile Changeset: e2b58a45a426 Author: peytoia Date: 2010-02-12 14:38 +0900 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e2b58a45a426 6921289: (tz) Support tzdata2010b Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: e8340332745e Author: malenkov Date: 2010-02-18 17:46 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e8340332745e 4498236: RFE: Provide a toString method for PropertyChangeEvent and other classes Reviewed-by: peterz ! src/share/classes/java/beans/BeanDescriptor.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/FeatureDescriptor.java ! src/share/classes/java/beans/IndexedPropertyChangeEvent.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/PropertyChangeEvent.java ! src/share/classes/java/beans/PropertyDescriptor.java + test/java/beans/Introspector/Test4498236.java Changeset: 5c03237838e1 Author: rupashka Date: 2010-02-27 14:26 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5c03237838e1 6913758: Specification for SynthViewportUI.paintBorder(...) should mention that this method is never called Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java Changeset: 96205ed1b196 Author: rupashka Date: 2010-02-27 14:47 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/96205ed1b196 6918447: SynthToolBarUI.setBorderToXXXX() methods don't correspond inherited spec. They do nothing. Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java Changeset: 621e921a14cd Author: rupashka Date: 2010-02-27 15:09 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/621e921a14cd 6918861: SynthSliderUI.uninstallDefaults() is not called when UI is uninstalled Reviewed-by: malenkov ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java + test/javax/swing/JSlider/6918861/bug6918861.java Changeset: 28741de0bb4a Author: rupashka Date: 2010-02-27 16:03 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/28741de0bb4a 6923305: SynthSliderUI paints the slider track when the slider's "paintTrack" property is set to false Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java + test/javax/swing/JSlider/6923305/bug6923305.java Changeset: 2bf137beb9bd Author: rupashka Date: 2010-02-27 16:14 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2bf137beb9bd 6929298: The SynthSliderUI#calculateTickRect method should be removed Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java Changeset: d6b3a07c8752 Author: rupashka Date: 2010-03-03 17:57 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/d6b3a07c8752 6924059: SynthScrollBarUI.configureScrollBarColors() should have spec different from the overridden method Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java + test/javax/swing/JScrollBar/6924059/bug6924059.java Changeset: 30c520bd148f Author: rupashka Date: 2010-03-03 20:08 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/30c520bd148f 6913768: With default SynthLookAndFeel instance installed new JTable creation leads to throwing NPE Reviewed-by: peterz ! src/share/classes/javax/swing/JTable.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java + test/javax/swing/JTable/6913768/bug6913768.java Changeset: f13fc955be62 Author: rupashka Date: 2010-03-03 20:53 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f13fc955be62 6917744: JScrollPane Page Up/Down keys do not handle correctly html tables with different cells contents Reviewed-by: peterz, alexp ! src/share/classes/javax/swing/text/DefaultEditorKit.java + test/javax/swing/JEditorPane/6917744/bug6917744.java + test/javax/swing/JEditorPane/6917744/test.html Changeset: 0622086d82ac Author: malenkov Date: 2010-03-04 21:17 +0300 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0622086d82ac 6921644: XMLEncoder generates invalid XML Reviewed-by: peterz ! src/share/classes/java/beans/XMLEncoder.java + test/java/beans/XMLEncoder/Test5023550.java + test/java/beans/XMLEncoder/Test5023557.java + test/java/beans/XMLEncoder/Test6921644.java Changeset: 79a509ac8f35 Author: lana Date: 2010-03-01 18:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/79a509ac8f35 Merge ! make/com/sun/Makefile - make/java/text/FILES_java.gmk Changeset: 90248595ec35 Author: lana Date: 2010-03-04 13:07 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/90248595ec35 Merge Changeset: 2fe4e72288ce Author: lana Date: 2010-03-09 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2fe4e72288ce Merge Changeset: 38fbb2353a6a Author: alanb Date: 2010-02-23 17:56 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/38fbb2353a6a 6925977: (file) test/java/nio/file/Path/CheckPermissions.java fails if test.src on read-only file system Reviewed-by: chegar ! test/java/nio/file/Path/CheckPermissions.java Changeset: 00abf8c232be Author: alanb Date: 2010-02-23 17:58 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/00abf8c232be 6925932: (file) Path.endsWith can throw ArrayIndexOutOfBoundsException (unx) Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/UnixPath.java ! test/java/nio/file/Path/PathOps.java Changeset: be5db597f3be Author: alanb Date: 2010-02-23 18:19 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/be5db597f3be 6928960: make modules fails to build class analyzer Reviewed-by: mchung ! make/modules/tools/Makefile Changeset: e94b296b53b4 Author: alanb Date: 2010-02-23 18:21 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e94b296b53b4 6926800: TEST_BUG: java/nio/file/Files/walk_file_tree.sh fails with newer versions of find(1) Reviewed-by: forax ! test/java/nio/file/Files/PrintFileTree.java ! test/java/nio/file/Files/walk_file_tree.sh Changeset: e842e99b514a Author: darcy Date: 2010-02-24 10:48 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/e842e99b514a 6929382: Various core classes in util and elsewhere are missing @param tags Reviewed-by: dholmes, martin ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Iterator.java ! src/share/classes/java/util/List.java Changeset: 9929203a8b98 Author: xuelei Date: 2010-02-25 13:32 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/9929203a8b98 6916202: More cases of invalid ldap filters accepted and processed Reviewed-by: vinnie, weijun ! src/share/classes/com/sun/jndi/ldap/Filter.java + test/com/sun/jndi/ldap/InvalidLdapFilters.java Changeset: 77beb60b39c6 Author: alanb Date: 2010-02-27 18:18 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/77beb60b39c6 6929532: (file) WatchService should avoid queuing new modify events when lots of files are changing Reviewed-by: alanb Contributed-by: sebastian.sickelmann at gmx.de ! src/share/classes/sun/nio/fs/AbstractWatchKey.java + test/java/nio/file/WatchService/LotsOfEvents.java - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: b77e94f5a601 Author: alanb Date: 2010-02-27 19:15 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b77e94f5a601 6929259: Remove double spaces from Dual-pivot quicksort Reviewed-by: alanb Contributed-by: vladimir.yaroslavskiy at sun.com ! src/share/classes/java/util/DualPivotQuicksort.java Changeset: 529d2da0aee2 Author: alanb Date: 2010-02-27 19:26 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/529d2da0aee2 6815768: File.getxxxSpace() methods fail for very large file systems under 32bit Java Reviewed-by: ohair ! src/solaris/native/java/io/UnixFileSystem_md.c Changeset: f7a6eae6e1eb Author: alanb Date: 2010-02-27 19:29 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/f7a6eae6e1eb 6921374: java.lang.String::hashCode() should check for count == 0 to avoid repeated stores hash = 0 Reviewed-by: darcy, ohair ! src/share/classes/java/lang/String.java Changeset: 78d91c4223cb Author: vinnie Date: 2010-03-01 17:54 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/78d91c4223cb 6921001: api/java_security/IdentityScope/IdentityScopeTests.html#getSystemScope fails starting from b78 JDK7 Reviewed-by: mullan ! src/share/classes/java/security/IdentityScope.java ! src/share/lib/security/java.security + test/java/security/IdentityScope/NoDefaultSystemScope.java Changeset: 893034df4ec2 Author: vinnie Date: 2010-03-01 18:00 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/893034df4ec2 Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: cddb43b12d28 Author: alanb Date: 2010-03-03 16:09 +0000 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/cddb43b12d28 6931216: TEST_BUG: test/java/nio/file/WatchService/LotsOfEvents.java failed with NPE Reviewed-by: chegar ! test/java/nio/file/WatchService/LotsOfEvents.java Changeset: 507159d8d143 Author: ohair Date: 2010-03-03 11:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/507159d8d143 6931763: sanity checks broken with latest cygwin, newer egrep -i option problems Reviewed-by: jjg ! make/common/shared/Sanity.gmk Changeset: 61c298558549 Author: weijun Date: 2010-03-04 10:37 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/61c298558549 6844909: support allow_weak_crypto in krb5.conf Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/internal/crypto/EType.java + test/sun/security/krb5/etype/WeakCrypto.java + test/sun/security/krb5/etype/weakcrypto.conf Changeset: 0f383673ce31 Author: weijun Date: 2010-03-04 10:38 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/0f383673ce31 6923681: Jarsigner crashes during timestamping Reviewed-by: vinnie ! src/share/classes/sun/security/tools/TimestampedSigner.java Changeset: 5e15b70e6d27 Author: weijun Date: 2010-03-04 10:38 +0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/5e15b70e6d27 6880321: sun.security.provider.JavaKeyStore abuse of OOM Exception handling Reviewed-by: xuelei ! src/share/classes/sun/security/provider/JavaKeyStore.java Changeset: c2d29e5695c2 Author: lana Date: 2010-03-04 13:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/c2d29e5695c2 Merge Changeset: 58b44ac0b10d Author: ohair Date: 2010-03-06 14:59 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/58b44ac0b10d 6915983: testing problems, adjusting list of tests, needs some investigation Reviewed-by: alanb ! test/Makefile ! test/ProblemList.txt Changeset: eae6e9ab2606 Author: lana Date: 2010-03-09 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/eae6e9ab2606 Merge - test/java/nio/file/WatchService/OverflowEventIsLoner.java Changeset: 2cafbbe9825e Author: mikejwre Date: 2010-03-18 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/2cafbbe9825e Added tag jdk7-b86 for changeset eae6e9ab2606 ! .hgtags From john.coomes at sun.com Fri Mar 19 02:36:01 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 19 Mar 2010 09:36:01 +0000 Subject: hg: jdk7/hotspot-comp/langtools: 19 new changesets Message-ID: <20100319093703.7171A44216@hg.openjdk.java.net> Changeset: 6eca0895a644 Author: jjg Date: 2010-02-23 18:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6eca0895a644 6511613: javac unexpectedly doesn't fail in some cases if an annotation processor specified Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java + test/tools/javac/processing/6511613/DummyProcessor.java + test/tools/javac/processing/6511613/clss41701.java Changeset: 87eb6edd4f21 Author: jjg Date: 2010-02-25 09:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/87eb6edd4f21 4880220: Add a warning when accessing a static method via an reference Reviewed-by: darcy ! make/build.properties ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/4880220/T4880220.empty.out + test/tools/javac/4880220/T4880220.error.out + test/tools/javac/4880220/T4880220.java + test/tools/javac/4880220/T4880220.warn.out Changeset: 85242c273d31 Author: darcy Date: 2010-02-25 11:04 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/85242c273d31 6929645: Address various findbugs warnings in langtools Reviewed-by: jjg ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: dbcba45123cd Author: jjg Date: 2010-02-25 12:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/dbcba45123cd 6929544: langtools source code uses statics qualified by instance variables Reviewed-by: darcy ! make/build.properties ! src/share/classes/com/sun/tools/apt/main/CommandLine.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java ! src/share/classes/com/sun/tools/doclets/standard/Standard.java ! src/share/classes/com/sun/tools/javac/Launcher.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/main/CommandLine.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: af75fd6155de Author: jjg Date: 2010-02-25 13:32 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/af75fd6155de 6893943: exit code from javah with no args is 0 Reviewed-by: darcy ! src/share/classes/com/sun/tools/javah/JavahTask.java + test/tools/javah/T6893943.java Changeset: b030706da5b4 Author: jjg Date: 2010-02-26 08:42 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/b030706da5b4 6881645: Unchecked method call on a method declared inside anonymous inner causes javac to crash Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java + test/tools/javac/T6881645.java Changeset: 72833a8a6086 Author: jjg Date: 2010-02-26 15:26 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/72833a8a6086 6930076: "null" can incorrectly appear in error message compiler.err.error.reading.file Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java Changeset: 7b69c7083a97 Author: jjg Date: 2010-02-26 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/7b69c7083a97 6930032: fix findbugs errors in com.sun.tools.javac.comp Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java Changeset: 7c23bbbe0dbd Author: darcy Date: 2010-03-02 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/7c23bbbe0dbd 6931130: Remove unused AnnotationCollector code from JavacProcessingEnvironment Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Changeset: 6e1e2738c530 Author: jjg Date: 2010-03-02 16:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/6e1e2738c530 6931482: minor findbugs fixes Reviewed-by: darcy ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java Changeset: 235135d61974 Author: jjg Date: 2010-03-02 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/235135d61974 6931127: strange test class files Reviewed-by: darcy ! test/tools/javac/annotations/neg/Constant.java ! test/tools/javac/generics/Casting.java ! test/tools/javac/generics/Casting3.java ! test/tools/javac/generics/Casting4.java ! test/tools/javac/generics/InnerInterface1.java ! test/tools/javac/generics/InnerInterface2.java ! test/tools/javac/generics/Multibound1.java ! test/tools/javac/generics/MultipleInheritance.java ! test/tools/javac/generics/NameOrder.java ! test/tools/javac/generics/PermuteBound.java ! test/tools/javac/generics/PrimitiveVariant.java Changeset: fc7132746501 Author: darcy Date: 2010-03-03 16:05 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/fc7132746501 6449781: TypeElement.getQualifiedName for anonymous classes returns null instead of an empty name Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/processing/model/element/TestAnonClassNames.java + test/tools/javac/processing/model/element/TestAnonSourceNames.java Changeset: 7f5db2e8b423 Author: jjg Date: 2010-03-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/7f5db2e8b423 6931927: position issues with synthesized anonymous class Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/tree/TestAnnotatedAnonClass.java + test/tools/javac/tree/TreePosTest.java - test/tools/javac/treepostests/TreePosTest.java Changeset: 117c95448ab9 Author: jjg Date: 2010-03-03 19:34 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/117c95448ab9 6931126: jtreg tests not Windows friendly Reviewed-by: darcy ! test/tools/javac/ThrowsIntersection_1.java ! test/tools/javac/ThrowsIntersection_2.java ! test/tools/javac/ThrowsIntersection_3.java ! test/tools/javac/ThrowsIntersection_4.java ! test/tools/javac/generics/NameOrder.java Changeset: c55733ceed61 Author: lana Date: 2010-03-04 13:40 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/c55733ceed61 Merge Changeset: a23282f17d0b Author: jjg Date: 2010-03-05 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/a23282f17d0b 6930108: IllegalArgumentException in AbstractDiagnosticFormatter for tools/javac/api/TestJavacTaskScanner.jav Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! test/tools/javac/api/TestJavacTaskScanner.java + test/tools/javac/api/TestResolveError.java Changeset: a4f3b97c8028 Author: jjg Date: 2010-03-05 16:13 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/a4f3b97c8028 Merge Changeset: ef07347428f2 Author: lana Date: 2010-03-09 15:29 -0800 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/ef07347428f2 Merge - test/tools/javac/treepostests/TreePosTest.java Changeset: 409db93d19c0 Author: mikejwre Date: 2010-03-18 13:53 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/409db93d19c0 Added tag jdk7-b86 for changeset ef07347428f2 ! .hgtags From Ulf.Zibis at gmx.de Fri Mar 19 11:21:32 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 19 Mar 2010 19:21:32 +0100 Subject: C2 optimization bug ? Message-ID: <4BA3C0AC.4040409@gmx.de> Below you see 2 code snippets, im exactly doing the same if boolean validateNonSurrogates is set to false by constant value. In the 1. example, I'm wondering, why register values are copied around and from/to the stack on each loop: 0x00b88930: mov %ebx,0x4(%esp) 0x00b88934: mov %eax,0x34(%esp) ;*aload_0 ... 0x00b88940: mov %ecx,%eax ... 0x00b88952: mov $0x2,%ecx 0x00b88957: mov 0x34(%esp),%eax ;*invokestatic charCount ; - java.lang.Character::charCount at 26 (line 2946) 0x00b8895b: add %ecx,%esi ;*iadd ... Even in the 2nd example it is not comprehensible, why the base address of int[] codePoints is repetitively loaded from the stack on each loop: 0x00b84e0e: mov 0x4(%esp),%edi ========================== Example 1: n += Character.charCount(codePoints, 0, codePoints.length, false); public static int charCount(int codePoint, boolean validateNonSurrogates) { if (isBMPCodePoint(codePoint)) { if (!validateNonSurrogates || !isSurrogate((char)codePoint)) return 1; } else if (isSupplementaryCodePoint(codePoint)) return 2; return 0; } public static int charCount(int[] codePoints, int offset, int count, boolean validateNonSurrogates) { checkBoundsOnCount(codePoints.length, offset, count); int n = 0; for (int i = offset; i < offset + count; i++) { int m = charCount(codePoints[i], validateNonSurrogates); if (m == 0) throw new IllegalArgumentException("At position "+i); n += m; } return n; } 0x00b88930: mov %ebx,0x4(%esp) 0x00b88934: mov %eax,0x34(%esp) ;*aload_0 ; - java.lang.Character::charCount at 21 (line 2946) 0x00b88938: mov 0x4(%esp),%ebx 0x00b8893c: mov 0xc(%ebx,%ebp,4),%ecx ;*iaload ; - java.lang.Character::charCount at 24 (line 2946) 0x00b88940: mov %ecx,%eax 0x00b88942: shr $0x10,%eax ;*iushr ; - java.lang.Character::isBMPCodePoint at 3 (line 2737) ; - java.lang.Character::charCount at 1 (line 2907) ; - java.lang.Character::charCount at 26 (line 2946) 0x00b88945: test %eax,%eax 0x00b88947: je 0x00b88973 ;*ifeq ; - java.lang.Character::charCount at 4 (line 2907) ; - java.lang.Character::charCount at 26 (line 2946) 0x00b88949: cmp $0x11,%eax 0x00b8894c: jge 0x00b889bf ;*if_icmpge ; - java.lang.Character::isValidCodePoint at 6 (line 2713) ; - java.lang.Character::isSupplementaryCodePoint at 8 (line 2768) ; - java.lang.Character::charCount at 22 (line 2910) ; - java.lang.Character::charCount at 26 (line 2946) 0x00b88952: mov $0x2,%ecx 0x00b88957: mov 0x34(%esp),%eax ;*invokestatic charCount ; - java.lang.Character::charCount at 26 (line 2946) 0x00b8895b: add %ecx,%esi ;*iadd ; - java.lang.Character::charCount at 68 (line 2949) 0x00b8895d: inc %ebp ;*iinc ; - java.lang.Character::charCount at 71 (line 2945) 0x00b8895e: cmp %edx,%ebp 0x00b88960: jl 0x00b88930 ;*if_icmpge ; - java.lang.Character::charCount at 18 (line 2945) ========================== Example 2: n += Character.charCount(codePoints, 0, codePoints.length); public static int charCount(int[] codePoints, int offset, int count) { checkBoundsOnCount(codePoints.length, offset, count); int n = 0; for (int i = offset; i < offset + count; i++) { int c = codePoints[i]; if (Character.isBMPCodePoint(c)) n += 1; else if (Character.isSupplementaryCodePoint(c)) n += 2; else throw new IllegalArgumentException("At position "+i); } return n; } 0x00b84e0e: mov 0x4(%esp),%edi 0x00b84e12: mov 0xc(%edi,%edx,4),%ebp 0x00b84e16: shr $0x10,%ebp ;*iushr ; - java.lang.Character::isBMPCodePoint at 3 (line 2737) ; - java.lang.Character::charCount at 28 (line 2958) 0x00b84e19: test %ebp,%ebp 0x00b84e1b: je 0x00b84f21 ;*ifeq ; - java.lang.Character::charCount at 31 (line 2958) 0x00b84e21: cmp $0x11,%ebp 0x00b84e24: jge 0x00b84eee ;*if_icmpge ; - java.lang.Character::isValidCodePoint at 6 (line 2713) ; - java.lang.Character::isSupplementaryCodePoint at 8 (line 2768) ; - java.lang.Character::charCount at 42 (line 2960) 0x00b84e2a: add $0x2,%eax ;*goto ; - java.lang.Character::charCount at 51 (line 2961) 0x00b84e2d: inc %edx ;*iinc ; - java.lang.Character::charCount at 82 (line 2956) 0x00b84e2e: cmp %ecx,%edx 0x00b84e30: jl 0x00b84e0e -Ulf From Ulf.Zibis at gmx.de Fri Mar 19 11:27:37 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 19 Mar 2010 19:27:37 +0100 Subject: superfluous TEST instruction Message-ID: <4BA3C219.60000@gmx.de> If I understand the Intel manual right, the zero flag is already set from the SHR instruction, so newly testing on 0 by TEST instruction seems superfluous. Am I wrong ? 0x00b88942: shr $0x10,%eax ;*iushr ; - java.lang.Character::isBMPCodePoint at 3 (line 2737) ; - java.lang.Character::charCount at 1 (line 2907) ; - java.lang.Character::charCount at 26 (line 2946) 0x00b88945: test %eax,%eax 0x00b88947: je 0x00b88973 ;*ifeq ; - java.lang.Character::charCount at 4 (line 2907) ; - java.lang.Character::charCount at 26 (line 2946) -Ulf From Vladimir.Kozlov at Sun.COM Fri Mar 19 11:43:38 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 19 Mar 2010 11:43:38 -0700 Subject: superfluous TEST instruction In-Reply-To: <4BA3C219.60000@gmx.de> References: <4BA3C219.60000@gmx.de> Message-ID: <4BA3C5DA.6060205@sun.com> RFE: 5044093 Vladimir Ulf Zibis wrote: > If I understand the Intel manual right, the zero flag is already set > from the SHR instruction, so newly testing on 0 by TEST instruction > seems superfluous. > > Am I wrong ? > > > 0x00b88942: shr $0x10,%eax ;*iushr > ; - > java.lang.Character::isBMPCodePoint at 3 (line 2737) > ; - > java.lang.Character::charCount at 1 (line 2907) > ; - > java.lang.Character::charCount at 26 (line 2946) > 0x00b88945: test %eax,%eax > 0x00b88947: je 0x00b88973 ;*ifeq > ; - > java.lang.Character::charCount at 4 (line 2907) > ; - > java.lang.Character::charCount at 26 (line 2946) > > > -Ulf > > From Ulf.Zibis at gmx.de Fri Mar 19 11:51:35 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 19 Mar 2010 19:51:35 +0100 Subject: superfluous TEST instruction In-Reply-To: <4BA3C5DA.6060205@sun.com> References: <4BA3C219.60000@gmx.de> <4BA3C5DA.6060205@sun.com> Message-ID: <4BA3C7B7.8050705@gmx.de> Much thanks, but not visible on the web. :-( http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5044093 -Ulf Am 19.03.2010 19:43, schrieb Vladimir Kozlov: > RFE: 5044093 > > Vladimir > > Ulf Zibis wrote: >> If I understand the Intel manual right, the zero flag is already set >> from the SHR instruction, so newly testing on 0 by TEST instruction >> seems superfluous. >> >> Am I wrong ? >> >> >> 0x00b88942: shr $0x10,%eax ;*iushr >> ; - >> java.lang.Character::isBMPCodePoint at 3 (line 2737) >> ; - >> java.lang.Character::charCount at 1 (line 2907) >> ; - >> java.lang.Character::charCount at 26 (line 2946) >> 0x00b88945: test %eax,%eax >> 0x00b88947: je 0x00b88973 ;*ifeq >> ; - >> java.lang.Character::charCount at 4 (line 2907) >> ; - >> java.lang.Character::charCount at 26 (line 2946) >> >> >> -Ulf >> >> > > From Vladimir.Kozlov at Sun.COM Fri Mar 19 12:18:28 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Fri, 19 Mar 2010 12:18:28 -0700 Subject: superfluous TEST instruction In-Reply-To: <4BA3C7B7.8050705@gmx.de> References: <4BA3C219.60000@gmx.de> <4BA3C5DA.6060205@sun.com> <4BA3C7B7.8050705@gmx.de> Message-ID: <4BA3CE04.7030202@sun.com> It was filed before we start work in open. Anyway, currently it is not the problem since new x86 cpus fuse test+jcc instructions into one so there is no performance loss, only code size is affected. To implement 5044093 requires a lot of work so, most like, we will not do it soon. Vladimir Ulf Zibis wrote: > Much thanks, but not visible on the web. :-( > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5044093 > > -Ulf > > > Am 19.03.2010 19:43, schrieb Vladimir Kozlov: >> RFE: 5044093 >> >> Vladimir >> >> Ulf Zibis wrote: >>> If I understand the Intel manual right, the zero flag is already set >>> from the SHR instruction, so newly testing on 0 by TEST instruction >>> seems superfluous. >>> >>> Am I wrong ? >>> >>> >>> 0x00b88942: shr $0x10,%eax ;*iushr >>> ; - >>> java.lang.Character::isBMPCodePoint at 3 (line 2737) >>> ; - >>> java.lang.Character::charCount at 1 (line 2907) >>> ; - >>> java.lang.Character::charCount at 26 (line 2946) >>> 0x00b88945: test %eax,%eax >>> 0x00b88947: je 0x00b88973 ;*ifeq >>> ; - >>> java.lang.Character::charCount at 4 (line 2907) >>> ; - >>> java.lang.Character::charCount at 26 (line 2946) >>> >>> >>> -Ulf >>> >>> >> >> > From Christian.Thalinger at Sun.COM Fri Mar 19 12:35:18 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 19 Mar 2010 20:35:18 +0100 Subject: Request for reviews (XL): 6829193: JSR 292 needs to support SPARC Message-ID: <1269027319.2224.10.camel@macbook> http://cr.openjdk.java.net/~twisti/6829193/webrev.01/ There are unimplemented portions of the hotspot code for method handles and invokedynamic specific to SPARC. They need to be filled in. This change adds SPARC interpreter support. src/cpu/sparc/vm/assembler_sparc.cpp src/cpu/sparc/vm/assembler_sparc.hpp src/cpu/sparc/vm/interp_masm_sparc.cpp src/cpu/sparc/vm/interp_masm_sparc.hpp src/cpu/sparc/vm/interpreter_sparc.cpp src/cpu/sparc/vm/methodHandles_sparc.cpp src/cpu/sparc/vm/stubGenerator_sparc.cpp src/cpu/sparc/vm/templateInterpreter_sparc.cpp src/cpu/sparc/vm/templateTable_sparc.cpp src/share/vm/prims/methodHandles.hpp From Thomas.Rodriguez at Sun.COM Fri Mar 19 16:23:45 2010 From: Thomas.Rodriguez at Sun.COM (Tom Rodriguez) Date: Fri, 19 Mar 2010 16:23:45 -0700 Subject: PcDesc/ScopeDesc vs jvmtiAddrLocationMap Message-ID: I've been looking more closely at the information we pass out the JVMTI to agents for profiling and I just realized we have a mismatch between how we record and use PcDescs and how JVMTI presents that to agents. We place our ScopeDescs after the instruction they are associated with, so given an instruction at pc the proper way to lookup the associated PcDesc is to searching at pc+1. This is handled transparently in our internal interfaces. jvmtiAddrLocationMap and the new jvmtiCompiledMethodLoadInlineRecord both present a model that starts from pc to the instruction that has debug info. This means that any external user asking questions using the data we provide will get answers that are off by a bit since the ranges are all effectively shifted by the instruction length. I don't see any easy way to paper over this. Everything I come up with requires recording more information when we're building the ScopeDescs. Alternatively we could process and store the extra debug info recorded by DebugNonSafepoints differently so that it was suitable for use by JVMTI. Any good ideas? tom From fweimer at bfk.de Mon Mar 22 10:19:29 2010 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 22 Mar 2010 17:19:29 +0000 Subject: superfluous TEST instruction In-Reply-To: <4BA3CE04.7030202@sun.com> (Vladimir Kozlov's message of "Fri\, 19 Mar 2010 12\:18\:28 -0700") References: <4BA3C219.60000@gmx.de> <4BA3C5DA.6060205@sun.com> <4BA3C7B7.8050705@gmx.de> <4BA3CE04.7030202@sun.com> Message-ID: <82ljdkb7fi.fsf@mid.bfk.de> * Vladimir Kozlov: > It was filed before we start work in open. > Anyway, currently it is not the problem since new x86 cpus fuse > test+jcc instructions into one so there is no performance loss, > only code size is affected. I don't think Core 2s/pre-Nehalem Xeons perform this type of fusion in 64 bit mode, only in 32 bit mode. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Vladimir.Kozlov at Sun.COM Mon Mar 22 11:01:15 2010 From: Vladimir.Kozlov at Sun.COM (Vladimir Kozlov) Date: Mon, 22 Mar 2010 11:01:15 -0700 Subject: superfluous TEST instruction In-Reply-To: <82ljdkb7fi.fsf@mid.bfk.de> References: <4BA3C219.60000@gmx.de> <4BA3C5DA.6060205@sun.com> <4BA3C7B7.8050705@gmx.de> <4BA3CE04.7030202@sun.com> <82ljdkb7fi.fsf@mid.bfk.de> Message-ID: <4BA7B06B.3080503@sun.com> You are right, but I talked about "new" cpus :) Vladimir Florian Weimer wrote: > * Vladimir Kozlov: > >> It was filed before we start work in open. >> Anyway, currently it is not the problem since new x86 cpus fuse >> test+jcc instructions into one so there is no performance loss, >> only code size is affected. > > I don't think Core 2s/pre-Nehalem Xeons perform this type of fusion in > 64 bit mode, only in 32 bit mode. > From cwimmer at uci.edu Wed Mar 24 13:57:32 2010 From: cwimmer at uci.edu (Christian Wimmer) Date: Wed, 24 Mar 2010 13:57:32 -0700 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <1268134418.1823.63.camel@macbook> References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> Message-ID: <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> Hi Christian, Tom, This changeset modifies the GraphBuilder such that now every method has a synthetic exception handler that covers the whole method. Previously, it was only necessary for synchronized methods (and with dtrace). I added the relevant diff below - note that the "if" is remoed by the patch. I think this affects the speed of C1 negatively, and perhaps also the generated code (it might slow down the exception dispatch). Why is this change necessary? Christian @@ -2862,20 +2867,18 @@ GraphBuilder::GraphBuilder(Compilation* _initial_state = state_at_entry(); start_block->merge(_initial_state); - BlockBegin* sync_handler = NULL; - if (method()->is_synchronized() || _compilation->env()- >dtrace_method_probes()) { - // setup an exception handler to do the unlocking and/or notification - sync_handler = new BlockBegin(-1); - sync_handler->set(BlockBegin::exception_entry_flag); - sync_handler->set(BlockBegin::is_on_work_list_flag); - sync_handler->set(BlockBegin::default_exception_handler_flag); - - ciExceptionHandler* desc = new ciExceptionHandler(method()- >holder(), 0, method()->code_size(), -1, 0); - XHandler* h = new XHandler(desc); - h->set_entry_block(sync_handler); - scope_data()->xhandlers()->append(h); - scope_data()->set_has_handler(); - } + // setup an exception handler to do the unlocking and/or + // notification and unwind the frame. + BlockBegin* sync_handler = new BlockBegin(-1); + sync_handler->set(BlockBegin::exception_entry_flag); + sync_handler->set(BlockBegin::is_on_work_list_flag); + sync_handler->set(BlockBegin::default_exception_handler_flag); + + ciExceptionHandler* desc = new ciExceptionHandler(method()- >holder(), 0, method()->code_size(), -1, 0); + XHandler* h = new XHandler(desc); + h->set_entry_block(sync_handler); + scope_data()->xhandlers()->append(h); + scope_data()->set_has_handler(); From gbenson at redhat.com Thu Mar 25 07:32:10 2010 From: gbenson at redhat.com (Gary Benson) Date: Thu, 25 Mar 2010 14:32:10 +0000 Subject: Review Request: Zero locking fix Message-ID: <20100325143210.GA5681@redhat.com> Hi all, When Zero is running with Shark enabled threads can be left with their _do_not_unlock_if_synchronized flag incorrectly set. This flag is unnecessary in Zero, and should have been removed as part of the fix for 6908267 but sadly I missed it! http://cr.openjdk.java.net/~gbenson/zero-locking-fix/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From john.coomes at sun.com Fri Mar 26 01:55:09 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Mar 2010 08:55:09 +0000 Subject: hg: jdk7/hotspot-comp: Added tag jdk7-b87 for changeset 6b1069f53fbc Message-ID: <20100326085509.1E60D44403@hg.openjdk.java.net> Changeset: 82135c848d5f Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/rev/82135c848d5f Added tag jdk7-b87 for changeset 6b1069f53fbc ! .hgtags From john.coomes at sun.com Fri Mar 26 01:55:12 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Mar 2010 08:55:12 +0000 Subject: hg: jdk7/hotspot-comp/corba: Added tag jdk7-b87 for changeset 09a41111a401 Message-ID: <20100326085516.C744E44404@hg.openjdk.java.net> Changeset: 39e14d2da687 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/corba/rev/39e14d2da687 Added tag jdk7-b87 for changeset 09a41111a401 ! .hgtags From john.coomes at sun.com Fri Mar 26 01:58:38 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Mar 2010 08:58:38 +0000 Subject: hg: jdk7/hotspot-comp/jaxp: Added tag jdk7-b87 for changeset 8b493f1aa136 Message-ID: <20100326085839.05AB744406@hg.openjdk.java.net> Changeset: d8ebd1591003 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxp/rev/d8ebd1591003 Added tag jdk7-b87 for changeset 8b493f1aa136 ! .hgtags From john.coomes at sun.com Fri Mar 26 01:58:43 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Mar 2010 08:58:43 +0000 Subject: hg: jdk7/hotspot-comp/jaxws: Added tag jdk7-b87 for changeset 3febd6fab2ac Message-ID: <20100326085845.0C69D44407@hg.openjdk.java.net> Changeset: 8c666f8f3565 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jaxws/rev/8c666f8f3565 Added tag jdk7-b87 for changeset 3febd6fab2ac ! .hgtags From john.coomes at sun.com Fri Mar 26 01:58:51 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Mar 2010 08:58:51 +0000 Subject: hg: jdk7/hotspot-comp/jdk: Added tag jdk7-b87 for changeset 2cafbbe9825e Message-ID: <20100326085934.A8D8A44408@hg.openjdk.java.net> Changeset: b3c69282f6d3 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/b3c69282f6d3 Added tag jdk7-b87 for changeset 2cafbbe9825e ! .hgtags From john.coomes at sun.com Fri Mar 26 02:04:35 2010 From: john.coomes at sun.com (john.coomes at sun.com) Date: Fri, 26 Mar 2010 09:04:35 +0000 Subject: hg: jdk7/hotspot-comp/langtools: Added tag jdk7-b87 for changeset 409db93d19c0 Message-ID: <20100326090441.50FAA4440A@hg.openjdk.java.net> Changeset: f9b5d4867a26 Author: mikejwre Date: 2010-03-25 15:05 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/langtools/rev/f9b5d4867a26 Added tag jdk7-b87 for changeset 409db93d19c0 ! .hgtags From Christian.Thalinger at Sun.COM Mon Mar 29 05:46:06 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 29 Mar 2010 14:46:06 +0200 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> Message-ID: <1269866766.10926.11.camel@macbook> On Wed, 2010-03-24 at 13:57 -0700, Christian Wimmer wrote: > Hi Christian, Tom, > > This changeset modifies the GraphBuilder such that now every method > has a synthetic exception handler that covers the whole method. > Previously, it was only necessary for synchronized methods (and with > dtrace). I added the relevant diff below - note that the "if" is > remoed by the patch. > I think this affects the speed of C1 negatively, and perhaps also the > generated code (it might slow down the exception dispatch). Why is > this change necessary? Tom would know better as he did the changes, but we changed the code so that C1 has the same unwinding mechanism as C2 does. This makes the C1 code a bit simpler. Regarding performance, why do you think it affects performance negatively? -- Christian From Christian.Thalinger at Sun.COM Mon Mar 29 06:17:43 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 29 Mar 2010 15:17:43 +0200 Subject: Review Request: Zero locking fix In-Reply-To: <20100325143210.GA5681@redhat.com> References: <20100325143210.GA5681@redhat.com> Message-ID: <1269868663.10926.12.camel@macbook> On Thu, 2010-03-25 at 14:32 +0000, Gary Benson wrote: > Hi all, > > When Zero is running with Shark enabled threads can be left with > their _do_not_unlock_if_synchronized flag incorrectly set. This > flag is unnecessary in Zero, and should have been removed as part > of the fix for 6908267 but sadly I missed it! > > http://cr.openjdk.java.net/~gbenson/zero-locking-fix/ > > I don't have a bug id for this. I currently have problems accessing Bugster but I'll take care of this one. -- Christian From gbenson at redhat.com Mon Mar 29 06:37:22 2010 From: gbenson at redhat.com (Gary Benson) Date: Mon, 29 Mar 2010 14:37:22 +0100 Subject: Review Request: Zero locking fix In-Reply-To: <1269868663.10926.12.camel@macbook> References: <20100325143210.GA5681@redhat.com> <1269868663.10926.12.camel@macbook> Message-ID: <20100329133722.GA3421@redhat.com> Christian Thalinger wrote: > On Thu, 2010-03-25 at 14:32 +0000, Gary Benson wrote: > > Hi all, > > > > When Zero is running with Shark enabled threads can be left with > > their _do_not_unlock_if_synchronized flag incorrectly set. This > > flag is unnecessary in Zero, and should have been removed as part > > of the fix for 6908267 but sadly I missed it! > > > > http://cr.openjdk.java.net/~gbenson/zero-locking-fix/ > > > > I don't have a bug id for this. > > I currently have problems accessing Bugster but I'll take care of > this one. Thank you. Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Mon Mar 29 08:24:53 2010 From: gbenson at redhat.com (Gary Benson) Date: Mon, 29 Mar 2010 16:24:53 +0100 Subject: Review Request: Zero JNI handles fix Message-ID: <20100329152453.GB3421@redhat.com> Hi all, Zero will exit with an error when invoked with -Xcheck:jni. This webrev fixes: http://cr.openjdk.java.net/~gbenson/zero-jnihandles-fix/ Note that this is actually a pretty old issue, but the fix for it got lost from the IcedTea repositories. There's more information here: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=323 I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From tom.rodriguez at oracle.com Mon Mar 29 11:28:12 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 29 Mar 2010 11:28:12 -0700 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <1269866766.10926.11.camel@macbook> References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> <1269866766.10926.11.camel@macbook> Message-ID: <3A38A1DE-7EF5-4F87-952B-12DC09B75D80@oracle.com> On Mar 29, 2010, at 5:46 AM, Christian Thalinger wrote: > On Wed, 2010-03-24 at 13:57 -0700, Christian Wimmer wrote: >> Hi Christian, Tom, >> >> This changeset modifies the GraphBuilder such that now every method >> has a synthetic exception handler that covers the whole method. >> Previously, it was only necessary for synchronized methods (and with >> dtrace). I added the relevant diff below - note that the "if" is >> remoed by the patch. >> I think this affects the speed of C1 negatively, and perhaps also the >> generated code (it might slow down the exception dispatch). Why is >> this change necessary? > > Tom would know better as he did the changes, but we changed the code so > that C1 has the same unwinding mechanism as C2 does. This makes the C1 > code a bit simpler. Otherwise the unwind code has to do a call into the runtime to find out the nmethod frame_size so that it can take the frame off the stack properly. I just didn't like doing that and never liked that C1 and C2 did these differently for no good reason so it seemed easiest to make it work the same. > > Regarding performance, why do you think it affects performance > negatively? I don't see any reason that this should hurt performance, at least enough to matter. The unwind path is changed to a jump to a tiny trampoline in the nmethod that adjusts sp and jumps to the unwind handler, so you don't go directly to the unwind handler but it's pretty minimal. Are there are other code generation effects that would be expected? tom > > -- Christian > From John.Rose at Sun.COM Mon Mar 29 18:53:40 2010 From: John.Rose at Sun.COM (John Rose) Date: Mon, 29 Mar 2010 18:53:40 -0700 Subject: Request for reviews (XL): 6939134: JSR 292 adjustments to method handle invocation Message-ID: <750A1A4D-3584-484C-88FA-88FE514E61C1@sun.com> http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ This review request is specifically for JVM changes. They will be coordinated with the following JDK and javac changes: http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ http://cr.openjdk.java.net/~jrose/6939134/lt-webrev.00/ Details: 6939134: JSR 292 adjustments to method handle invocation Summary: split MethodHandle.invoke into invokeExact and invokeGeneric; also clean up JVM-to-Java interfaces Reviewed-by: ? The JSR 292 EG has decided to split MethodHandle.invoke into two methods, invokeExact and invokeGeneric. The EG has also decided to simplify the process of CallSite bootstrapping. These changes require updates to the toolchain and JVM. This bug is the first part of a two part change. This change updates the CallSite API. It renames MH.invoke to invokeExact and introduces invokeGeneric as a separately recognized operation, but does not give the two operations distinct semantics. A following bug will give invokeGeneric its distinct semantics. Changes to be done in this part include: - Recognize signature-polymorphic methods MH.invoke* and InDy.* via special IDs vmIntrinsics::_invoke*. - Make the vmSymbols::SID visible through the ciSymbol API. - Adding some mode bits to the key of SymbolPropertyTable (to distinguish invokeExact/invokeGeneric). - Improve the debug printing code for methodOop (notably, to show intrinsic ID). - Remove unused arguments and dead code. Specific changes to the private interface between the JVM and Java code: - Move misc. upcalls to a single implementation-private interface class, MethodHandleNatives. - Reduce the VM's entanglement with CallSite by removing some hardwired fields from CS. - Pass more information to the Java code when bootstrapping a CallSite. - Obtain MethodHandleNatives.CONV_OP_IMPLEMENTED_MASK from the JVM, which knows the correct mask. - Use only the JVM to store bootstrap methods, not a Java-level hash table. - Adjust access checks (under VerifyMethodHandles) for Direct MHs and MemberNames, to reduce test failures in debug mode. -- John P.S. I know the index pages are formatted awkwardly. Will fix tomorrow. From wimmer at ssw.jku.at Mon Mar 29 23:03:24 2010 From: wimmer at ssw.jku.at (Christian Wimmer) Date: Mon, 29 Mar 2010 23:03:24 -0700 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <3A38A1DE-7EF5-4F87-952B-12DC09B75D80@oracle.com> References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> <1269866766.10926.11.camel@macbook> <3A38A1DE-7EF5-4F87-952B-12DC09B75D80@oracle.com> Message-ID: On Mar 29, 2010, at 11:28 AM, Tom Rodriguez wrote: > > On Mar 29, 2010, at 5:46 AM, Christian Thalinger wrote: > >> On Wed, 2010-03-24 at 13:57 -0700, Christian Wimmer wrote: >>> Hi Christian, Tom, >>> >>> This changeset modifies the GraphBuilder such that now every method >>> has a synthetic exception handler that covers the whole method. >>> Previously, it was only necessary for synchronized methods (and with >>> dtrace). I added the relevant diff below - note that the "if" is >>> remoed by the patch. >>> I think this affects the speed of C1 negatively, and perhaps also >>> the >>> generated code (it might slow down the exception dispatch). Why is >>> this change necessary? >> >> Tom would know better as he did the changes, but we changed the >> code so >> that C1 has the same unwinding mechanism as C2 does. This makes >> the C1 >> code a bit simpler. > > Otherwise the unwind code has to do a call into the runtime to find > out the nmethod frame_size so that it can take the frame off the > stack properly. I just didn't like doing that and never liked that > C1 and C2 did these differently for no good reason so it seemed > easiest to make it work the same. That sounds reasonable, at first I thought that is a change that is related to invokedynamic. When every exception dispatch goes through this exception handler, then this means that all of the "unwind" code (especially the unwind stub in the C1 runtime) can also go away? > >> >> Regarding performance, why do you think it affects performance >> negatively? > > I don't see any reason that this should hurt performance, at least > enough to matter. The unwind path is changed to a jump to a tiny > trampoline in the nmethod that adjusts sp and jumps to the unwind > handler, so you don't go directly to the unwind handler but it's > pretty minimal. Are there are other code generation effects that > would be expected? Exception stack unwinding will be a bit slower, but I guess that doesn't matter at all. I'm more concerned about the compilation speed of C1. Back in the days, I optimized under the assumption that most of the blocks don't have exception edges. This is now no longer true, since nearly every block now has an exception edge to the synthetic exception handler. Did you see an impact on the compilation time? Christian From Christian.Thalinger at Sun.COM Tue Mar 30 01:05:34 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 30 Mar 2010 10:05:34 +0200 Subject: Review Request: Zero locking fix In-Reply-To: <20100329133722.GA3421@redhat.com> References: <20100325143210.GA5681@redhat.com> <1269868663.10926.12.camel@macbook> <20100329133722.GA3421@redhat.com> Message-ID: <1269936334.982.17.camel@macbook> On Mon, 2010-03-29 at 14:37 +0100, Gary Benson wrote: > Christian Thalinger wrote: > > On Thu, 2010-03-25 at 14:32 +0000, Gary Benson wrote: > > > Hi all, > > > > > > When Zero is running with Shark enabled threads can be left with > > > their _do_not_unlock_if_synchronized flag incorrectly set. This > > > flag is unnecessary in Zero, and should have been removed as part > > > of the fix for 6908267 but sadly I missed it! > > > > > > http://cr.openjdk.java.net/~gbenson/zero-locking-fix/ > > > > > > I don't have a bug id for this. > > > > I currently have problems accessing Bugster but I'll take care of > > this one. > > Thank you. 6939180: Zero locking fix Changes look good and it's in the JPRT queue. -- Christian From Christian.Thalinger at Sun.COM Tue Mar 30 02:20:21 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 30 Mar 2010 11:20:21 +0200 Subject: Request for reviews (XL): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: <750A1A4D-3584-484C-88FA-88FE514E61C1@sun.com> References: <750A1A4D-3584-484C-88FA-88FE514E61C1@sun.com> Message-ID: <1269940821.982.87.camel@macbook> On Mon, 2010-03-29 at 18:53 -0700, John Rose wrote: > http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ > > This review request is specifically for JVM changes. They will be coordinated with the following JDK and javac changes: > http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ http://cr.openjdk.java.net/~jrose/6939134/jdk-webrev.00/ > http://cr.openjdk.java.net/~jrose/6939134/lt-webrev.00/ From Christian.Thalinger at Sun.COM Tue Mar 30 02:49:21 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 30 Mar 2010 11:49:21 +0200 Subject: Request for reviews (XL): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: <750A1A4D-3584-484C-88FA-88FE514E61C1@sun.com> References: <750A1A4D-3584-484C-88FA-88FE514E61C1@sun.com> Message-ID: <1269942561.982.126.camel@macbook> On Mon, 2010-03-29 at 18:53 -0700, John Rose wrote: > http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ src/share/vm/prims/methodHandles.cpp: 2103 // happens, when we call resolve_NemberName. Typo. src/share/vm/prims/methodHandles.hpp: 273 //|(1< References: <20100329152453.GB3421@redhat.com> Message-ID: <1269942726.982.129.camel@macbook> On Mon, 2010-03-29 at 16:24 +0100, Gary Benson wrote: > Hi all, > > Zero will exit with an error when invoked with -Xcheck:jni. > This webrev fixes: > > http://cr.openjdk.java.net/~gbenson/zero-jnihandles-fix/ > > Note that this is actually a pretty old issue, but the fix > for it got lost from the IcedTea repositories. There's more > information here: > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=323 > > I don't have a bug id for this. 6939182: Zero JNI handles fix I guess the changes are good since it uses an #ifdef. Maybe one of the runtime guys could also comment on this one. -- Christian From gbenson at redhat.com Tue Mar 30 03:07:11 2010 From: gbenson at redhat.com (Gary Benson) Date: Tue, 30 Mar 2010 11:07:11 +0100 Subject: Review Request: Add fast bytecode support to C++ interpreter Message-ID: <20100330100711.GA3617@redhat.com> Hi all, HotSpot has the capability to rewrite the bytecode stream, for example to combine common instruction pairs, but the C++ interpreter has no support for this. This webrev adds support for backing out over rewritten bytecodes to the C++ interpreter, in much the same way as I believe the template interpreter does. http://cr.openjdk.java.net/~gbenson/cc_interp-rewrites/ This was contributed by Edward Nevill, who has signed the SCA. His original mail is here: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-March/008818.html I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From John.Rose at Sun.COM Tue Mar 30 04:06:31 2010 From: John.Rose at Sun.COM (John Rose) Date: Tue, 30 Mar 2010 04:06:31 -0700 Subject: Request for reviews (M): 6939196: method handle signatures off the boot class path get linkage errors Message-ID: 6939196: method handle signatures off the boot class path get linkage errors http://cr.openjdk.java.net/~jrose/6939196/hs-webrev.00/ http://cr.openjdk.java.net/~jrose/6939196/jdk-webrev.00/ The bugtraq description is copied below. - Adjust MethodType lookup logic to search off the BCP, but not to cache those results. - Pass accessing class where it needs to be seen. - A SignatureStream idiom "as_klass" for class lookup has been refactored. Please review the JDK changes along with the JVM changes. They are very simple: - Remove workaround from MethodHandleImpl lookup code - Add JUnit regression test to MethodHandlesTest -- John P.S. Here is the description from bugtraq. The following test program throws an error on the marked line. The problem is a weakness in the current JSR 292 Reference Implementation logic for resolving MethodTypes that mention types not on the boot class path. The workaround, therefore, is to load your entire JSR 292 application using -Xbootclasspath/a:myapp.jar. import java.dyn.*; import static java.dyn.MethodHandles.*; import static java.dyn.MethodType.*; public class BCPBug { // Local class which appears in method signature; static class Example { } static void bcpTypesOnly(Object x) { System.out.println("bcpTypesOnly"); } static void hasUserType(Example x) { System.out.println("hasUserType"); } public static void main(String... av) throws Throwable { Lookup lookup = lookup(); MethodHandle bcpTypesOnly = lookup.findStatic(lookup.lookupClass(), "bcpTypesOnly", methodType(void.class, Object.class)); MethodHandle hasUserType = lookup.findStatic(lookup.lookupClass(), "hasUserType", methodType(void.class, Example.class)); bcpTypesOnly.invokeExact((Object)null); hasUserType.invokeExact((Example)null); // throws NoClassDefFoundError on BCPBug$Example } } /* Run: $ $JAVA7X_HOME/bin/javac -d . BCPBug.java $ $JAVA7X_HOME/bin/java -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles -cp . BCPBug bcpTypesOnly Exception in thread "main" java.lang.NoClassDefFoundError: BCPBug$Example at BCPBug.main(BCPBug.java:17) */ From John.Rose at Sun.COM Tue Mar 30 04:24:47 2010 From: John.Rose at Sun.COM (John Rose) Date: Tue, 30 Mar 2010 04:24:47 -0700 Subject: Request for reviews (L): 6939203: JSR 292 needs method handle constants Message-ID: 6939203: JSR 292 needs method handle constants Summary: Add new CP types CONSTANT_MethodHandle, CONSTANT_MethodType; extend 'ldc' bytecode. http://cr.openjdk.java.net/~jrose/6939203/hs-webrev.00 Please review this small JDK change along with it: http://cr.openjdk.java.net/~jrose/6939203/jdk-webrev.00 In order to compile constant references to method handles and method types, the constant pool structure needs to be able to represent method handle references, and the ldc instruction updated (as it was for Class constants). This feature completes the role of method handle as a lightweight but dynamic access point to any bytecode operation. Without the ability to perform 'ldc', building a handle to a proposed bytecode level member access is 1-2 orders of magnitude more expensive, requiring a reflective lookup. -- John P.S. There is an experimental javac change which allows such constants to be written from within Java programs. Here is the change set for reference: http://cr.openjdk.java.net/~jrose/6939203/lt-webrev.00 The test file for this change shows the sorts of method handle constants that can be formed: http://cr.openjdk.java.net/~jrose/6939203/lt-webrev.00/raw_files/new/test/tools/javac/meth/MHLiterals.java From Christian.Thalinger at Sun.COM Tue Mar 30 05:09:09 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 30 Mar 2010 12:09:09 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6939180: Zero locking fix Message-ID: <20100330120926.C6CF4449E6@hg.openjdk.java.net> Changeset: 747d26efc5fa Author: twisti Date: 2010-03-30 00:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/747d26efc5fa 6939180: Zero locking fix Summary: When Zero is running with Shark enabled threads can be left with their _do_not_unlock_if_synchronized flag incorrectly set. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/cppInterpreter_zero.cpp From gbenson at redhat.com Tue Mar 30 06:06:06 2010 From: gbenson at redhat.com (Gary Benson) Date: Tue, 30 Mar 2010 14:06:06 +0100 Subject: Review Request: Zero locking fix In-Reply-To: <1269936334.982.17.camel@macbook> References: <20100325143210.GA5681@redhat.com> <1269868663.10926.12.camel@macbook> <20100329133722.GA3421@redhat.com> <1269936334.982.17.camel@macbook> Message-ID: <20100330130606.GC3617@redhat.com> Christian Thalinger wrote: > On Mon, 2010-03-29 at 14:37 +0100, Gary Benson wrote: > > Christian Thalinger wrote: > > > On Thu, 2010-03-25 at 14:32 +0000, Gary Benson wrote: > > > > Hi all, > > > > > > > > When Zero is running with Shark enabled threads can be left with > > > > their _do_not_unlock_if_synchronized flag incorrectly set. This > > > > flag is unnecessary in Zero, and should have been removed as part > > > > of the fix for 6908267 but sadly I missed it! > > > > > > > > http://cr.openjdk.java.net/~gbenson/zero-locking-fix/ > > > > > > > > I don't have a bug id for this. > > > > > > I currently have problems accessing Bugster but I'll take care of > > > this one. > > > > Thank you. > > 6939180: Zero locking fix > > Changes look good and it's in the JPRT queue. Saw it go it, thank you :) Cheers, Gary -- http://gbenson.net/ From keith.mcguigan at oracle.com Tue Mar 30 06:55:22 2010 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Tue, 30 Mar 2010 09:55:22 -0400 Subject: Review Request: Zero JNI handles fix In-Reply-To: <1269942726.982.129.camel@macbook> References: <20100329152453.GB3421@redhat.com> <1269942726.982.129.camel@macbook> Message-ID: <4BB202CA.9040202@oracle.com> On 03/30/10 05:52, Christian Thalinger wrote: > On Mon, 2010-03-29 at 16:24 +0100, Gary Benson wrote: >> Hi all, >> >> Zero will exit with an error when invoked with -Xcheck:jni. >> This webrev fixes: >> >> http://cr.openjdk.java.net/~gbenson/zero-jnihandles-fix/ >> >> Note that this is actually a pretty old issue, but the fix >> for it got lost from the IcedTea repositories. There's more >> information here: >> >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=323 >> >> I don't have a bug id for this. > > 6939182: Zero JNI handles fix > > I guess the changes are good since it uses an #ifdef. Maybe one of the > runtime guys could also comment on this one. It would be better to put this in zero-specific code somewhere instead of polluting common code with #ifdef, but if that's not possible... Also, instead of this point-fix in jniHandles, why not fix last_Java_sp() to return zero_stack()->sp() in the zero case? This is not the only place last_Java_sp() is called. Might want to fix it for last_Java_pc() (and related) too. -- - Keith From john.r.rose at oracle.com Tue Mar 30 04:18:28 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 30 Mar 2010 04:18:28 -0700 Subject: Request for reviews (L): 6939207: refactor constant pool index processing Message-ID: 6939207: refactor constant pool index processing Summary: Factored cleanup which prepares for enhanced ldc semantics. http://cr.openjdk.java.net/~jrose/6939207/webrev.00 Bug 6939203 (JSR 292 needs method handle constants) requires an extension to the construct pool structure and the ldc bytecode. In particular, it needs to use the CP cache to manage method references, and therefore the ldc bytecode (when used by the new functionality) need to refer to a CP cache index. To do this safely, the JVM's bytecode parsing modules must make a more rigorous distinction between types of bytecode indexes. This change makes clear the difference between (a) a CP index and (b) a CP cache index, and also (1) a network-byte-order index and (2) a native-byte-order index. With clarified distinctions, enforced mechanically, we can safely make the needed modifications. This change may be incomplete. I'd like advice on whether to push the change farther. Specifically, we should push all byte swapping to the point where data is loaded, because the byte order is known most accurately at that point. Currently, we swap it in the CP accessors. See the temporary function 'get_index_native_swap' and the FIXME comments nearby. -- John From gbenson at redhat.com Tue Mar 30 07:59:20 2010 From: gbenson at redhat.com (Gary Benson) Date: Tue, 30 Mar 2010 15:59:20 +0100 Subject: Review Request: Zero JNI handles fix In-Reply-To: <4BB202CA.9040202@oracle.com> References: <20100329152453.GB3421@redhat.com> <1269942726.982.129.camel@macbook> <4BB202CA.9040202@oracle.com> Message-ID: <20100330145920.GD3617@redhat.com> Keith McGuigan wrote: > On 03/30/10 05:52, Christian Thalinger wrote: > > On Mon, 2010-03-29 at 16:24 +0100, Gary Benson wrote: > > > Zero will exit with an error when invoked with -Xcheck:jni. > > > This webrev fixes: > > > > > > http://cr.openjdk.java.net/~gbenson/zero-jnihandles-fix/ > > > > > > Note that this is actually a pretty old issue, but the fix > > > for it got lost from the IcedTea repositories. There's more > > > information here: > > > > > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=323 > > > > > > I don't have a bug id for this. > > > > 6939182: Zero JNI handles fix > > > > I guess the changes are good since it uses an #ifdef. Maybe one > > of the runtime guys could also comment on this one. > > It would be better to put this in zero-specific code somewhere > instead of polluting common code with #ifdef, but if that's not > possible... > > Also, instead of this point-fix in jniHandles, why not fix > last_Java_sp() to return zero_stack()->sp() in the zero case? This > is not the only place last_Java_sp() is called. Might want to fix > it for last_Java_pc() (and related) too. The difficulty is that what last_Java_sp is returning in Zero is the Zero frame pointer, which is not the highest thing on the stack. It probably isn't the best thing to #ifdef this here though, I agree. I'll have a think about it... Cheers, Gary -- http://gbenson.net/ From tom.rodriguez at oracle.com Tue Mar 30 09:26:18 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 30 Mar 2010 09:26:18 -0700 Subject: Review Request: Add fast bytecode support to C++ interpreter In-Reply-To: <20100330100711.GA3617@redhat.com> References: <20100330100711.GA3617@redhat.com> Message-ID: I don't understand this. Zero sets both RewriteFrequentPairs and RewriteBytecodes to true but it doesn't appear to have the logic to convert normal bytecodes into their fast variants so how does it run afoul of the fast bytecodes? Is there some code somewhere that I'm not seeing that injects the _fast variants? Strictly speaking RewriteFrequentPairs and RewriteBytecodes should be false if the C++ interpreter is being used but since it's all the responsibility of the interpreter itself having wrong settings for those flags doesn't really matter. If you really wanted to support RewriteFrequentPairs and RewriteBytecodes then you'd need to add the rewriting logic to inject the _fast variants and then add cases to handle them. The template interpreter has special implementations for each of the fast variants, including the pairs, so it doesn't convert them back to the normal version and redispatch. Redispatching will make the _fast variants slower than the normal variant which doesn't seem like a very good optimization. tom On Mar 30, 2010, at 3:07 AM, Gary Benson wrote: > Hi all, > > HotSpot has the capability to rewrite the bytecode stream, for example > to combine common instruction pairs, but the C++ interpreter has no > support for this. This webrev adds support for backing out over > rewritten bytecodes to the C++ interpreter, in much the same way as I > believe the template interpreter does. > > http://cr.openjdk.java.net/~gbenson/cc_interp-rewrites/ > > This was contributed by Edward Nevill, who has signed the SCA. His > original mail is here: > > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-March/008818.html > > I don't have a bug id for this. > > Cheers, > Gary > > -- > http://gbenson.net/ From John.Rose at Sun.COM Tue Mar 30 15:06:14 2010 From: John.Rose at Sun.COM (John Rose) Date: Tue, 30 Mar 2010 15:06:14 -0700 Subject: Request for reviews (XL): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: <1269942561.982.126.camel@macbook> References: <750A1A4D-3584-484C-88FA-88FE514E61C1@sun.com> <1269942561.982.126.camel@macbook> Message-ID: On Mar 30, 2010, at 2:49 AM, Christian Thalinger wrote: > On Mon, 2010-03-29 at 18:53 -0700, John Rose wrote: >> http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.00/ > > src/share/vm/prims/methodHandles.cpp: > > 2103 // happens, when we call resolve_NemberName. > > Typo. Thanks. > src/share/vm/prims/methodHandles.hpp: > > 273 //|(1< Otherwise looks good. When will the MH.invoke name be removed? When or before we remove the experimental status of the JSR 292 stuff. Which means before JDK7 feature-complete. -- John From John.Rose at Sun.COM Tue Mar 30 15:12:41 2010 From: John.Rose at Sun.COM (John Rose) Date: Tue, 30 Mar 2010 15:12:41 -0700 Subject: Request for reviews (XL): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: <1269942561.982.126.camel@macbook> References: <750A1A4D-3584-484C-88FA-88FE514E61C1@sun.com> <1269942561.982.126.camel@macbook> Message-ID: On Mar 30, 2010, at 2:49 AM, Christian Thalinger wrote: > src/share/vm/prims/methodHandles.hpp: > > 273 //|(1< > What bug do we have here? I'm going to move that constant into the platform-specific assembly code where it belongs. AFAIK, the bug is only with the x86 code. -- John From ed at camswl.com Wed Mar 31 03:18:19 2010 From: ed at camswl.com (Edward Nevill) Date: Wed, 31 Mar 2010 11:18:19 +0100 Subject: Review Request: Add fast bytecode support to C++ interpreter In-Reply-To: 20100330100711.GA3617@redhat.com Message-ID: <1270030699.30313.40.camel@mint> Hi Tom, The rewriting is done in icedtea6/ports/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S The following fast/rewritten bytecodes are supported #define opc_bgetfield 0xcc #define opc_cgetfield 0xcd #define opc_igetfield 0xd0 #define opc_lgetfield 0xd1 #define opc_sgetfield 0xd2 #define opc_aputfield 0xd3 #define opc_bputfield 0xd4 #define opc_cputfield 0xd5 #define opc_iputfield 0xd8 #define opc_lputfield 0xd9 #define opc_iaccess_0 0xdb #define opc_iaccess_1 0xdc #define opc_iaccess_2 0xdd #define opc_iaccess_3 0xde #define opc_invokeresolved 0xdf #define opc_invokespecialresolved 0xe0 #define opc_invokestaticresolved 0xe1 #define opc_invokevfinal 0xe2 #define opc_iload_iload 0xe3 #define opc_iload_iload_N 0xe4 #define opc_dmac 0xe6 #define opc_iload_0_iconst_N 0xe7 #define opc_iload_1_iconst_N 0xe8 #define opc_iload_2_iconst_N 0xe9 #define opc_iload_3_iconst_N 0xea #define opc_iload_iconst_N 0xeb #define opc_iadd_istore_N 0xec #define opc_isub_istore_N 0xed #define opc_iand_istore_N 0xee #define opc_ior_istore_N 0xef #define opc_ixor_istore_N 0xf0 #define opc_iadd_u4store 0xf1 #define opc_isub_u4store 0xf2 #define opc_iand_u4store 0xf3 #define opc_ior_u4store 0xf4 #define opc_ixor_u4store 0xf5 #define opc_iload_0_iload 0xf6 #define opc_iload_1_iload 0xf7 #define opc_iload_2_iload 0xf8 #define opc_iload_3_iload 0xf9 #define opc_iload_0_iload_N 0xfa #define opc_iload_1_iload_N 0xfb #define opc_iload_2_iload_N 0xfc #define opc_iload_3_iload_N 0xfd Under normal execution these bytecodes will be handled by cppInterpreter_arm.s. However, there are a number of cases where it backs out to the C++ interpreter. - If JvmtiExport::can_post_interpreter_events is true - If the ARM interpreter is built in conjunction with the Shark JIT and the Shark JIT marks a method as non entrant. I agree with you that it would be possible / desirable for the C++ interpreter to support these bytecodes directly, however... - Performance is not a particular issue in either of the above cases so the fact that the rewritten bytecodes are now slower than the non rewritten variants does not matter. - There are a large number of bytecodes which are rewritten. This would involve a large change to bytecodeInterpreter.cpp which would have to be debugged, supported etc. - The rewritten bytecodes are architecture dependant. Well, at least, some of them are, and some of them are not. The file hotspot/src/share/vm/interpreter/bytecodes.cpp contains the definitions of a number of the fast bytecodes (see Bytecodes::initialize()) where a set of fast bytecodes is defined between _fast_aputfield and _fast_binary_switch. Bytecodes::initialize() then calls // platform specific JVM bytecodes pd_initialize(); To allow the platform to define its own specific bytecodes. In the case of Zero / ARM this is done in icedtea6/ports/hotspot/src/cpu/zero/vm/bytecodes_zero.cpp where the rest of the fast bytecodes used by the ARM interpreter are defined. Given that the fast bytecodes can be defined in a platform dependant area of code like this it would seem wrong to add support for them to bytecodeInterpreter.cpp which is in shared code because the set of fast bytecodes may vary between platforms. What might be possible is for bytecodeInterpreter.cpp to #include say "bytecodeInterpreter_pd.cpp". This would then allow rewritten bytecodes to be added in a platform specific fashion. However, the fix I proposed is that in the default case, before throwing a fatal error, the bytecode interpreter should perform a quick check to see if the bytecode is defined, and in this case replace the bytecode with the original bytecode and re-execute it. This would seem to be a fairly safe change to bytecodeInterpreter.cpp since it only affects the case where a fatal error was to be thrown in any case. Regards, Ed. >I don't understand this. Zero sets both RewriteFrequentPairs and >RewriteBytecodes to true but it doesn't appear to have the logic to >convert normal bytecodes into their fast variants so how does it run >afoul of the fast bytecodes? Is there some code somewhere that I'm not >seeing that injects the _fast variants? Strictly speaking >RewriteFrequentPairs and RewriteBytecodes should be false if the C++ >interpreter is being used but since it's all the responsibility of the >interpreter itself having wrong settings for those flags doesn't really >matter. > >If you really wanted to support RewriteFrequentPairs and RewriteBytecodes then you'd need to add the rewriting logic to inject the _fast variants and then add cases to handle them. The template interpreter has special implementations for each of the fast variants, including the pairs, so it doesn't convert them back to the normal version and redispatch. Redispatching will make the _fast variants slower than the normal variant which doesn't seem like a very good optimization. > >tom > >On Mar 30, 2010, at 3:07 AM, Gary Benson wrote: > >> Hi all, >> >> HotSpot has the capability to rewrite the bytecode stream, for example >> to combine common instruction pairs, but the C++ interpreter has no >> support for this. This webrev adds support for backing out over >> rewritten bytecodes to the C++ interpreter, in much the same way as I >> believe the template interpreter does. From gbenson at redhat.com Wed Mar 31 06:50:31 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 31 Mar 2010 14:50:31 +0100 Subject: Review Request: Zero build fix Message-ID: <20100331135031.GC3856@redhat.com> Hi all, Some recent method handles changes have broken the Zero build. This webrev fixes: http://cr.openjdk.java.net/~gbenson/zero-build-fix/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Wed Mar 31 08:05:38 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 31 Mar 2010 17:05:38 +0200 Subject: Review Request: Zero build fix In-Reply-To: <20100331135031.GC3856@redhat.com> References: <20100331135031.GC3856@redhat.com> Message-ID: <1270047938.982.234.camel@macbook> On Wed, 2010-03-31 at 14:50 +0100, Gary Benson wrote: > Hi all, > > Some recent method handles changes have broken the Zero build. > This webrev fixes: > > http://cr.openjdk.java.net/~gbenson/zero-build-fix/ > > I don't have a bug id for this. Ahh, yeah, that is because of: 6934494: JSR 292 MethodHandles adapters should be generated into their own CodeBlob I created: 6939731: JSR 292 Zero build fix after 6934494 The changes look good and it's in the JPRT queue. -- Christian From gbenson at redhat.com Wed Mar 31 08:23:23 2010 From: gbenson at redhat.com (Gary Benson) Date: Wed, 31 Mar 2010 16:23:23 +0100 Subject: Review Request: Zero build fix In-Reply-To: <1270047938.982.234.camel@macbook> References: <20100331135031.GC3856@redhat.com> <1270047938.982.234.camel@macbook> Message-ID: <20100331152323.GD3856@redhat.com> Christian Thalinger wrote: > On Wed, 2010-03-31 at 14:50 +0100, Gary Benson wrote: > > Some recent method handles changes have broken the Zero build. > > This webrev fixes: > > > > http://cr.openjdk.java.net/~gbenson/zero-build-fix/ > > > > I don't have a bug id for this. > > Ahh, yeah, that is because of: > > 6934494: JSR 292 MethodHandles adapters should be generated into > their own CodeBlob > > I created: > > 6939731: JSR 292 Zero build fix after 6934494 > > The changes look good and it's in the JPRT queue. Thank you. Cheers, Gary -- http://gbenson.net/ From tom.rodriguez at oracle.com Wed Mar 31 11:01:44 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 31 Mar 2010 11:01:44 -0700 Subject: Review Request: Add fast bytecode support to C++ interpreter In-Reply-To: <1270030699.30313.40.camel@mint> References: <1270030699.30313.40.camel@mint> Message-ID: <3584518B-7FCF-456A-92F8-C93EBA16926A@oracle.com> I think that makes sense. So this isn't really adding support for fast bytecodes but providing a fallback path for a system with two different interpreters, one which supports fast bytecodes and one which doesn't. I think it would be best to keep this ifdef ZERO. What about this: diff -r c047da02984c src/share/vm/interpreter/bytecodeInterpreter.cpp --- a/src/share/vm/interpreter/bytecodeInterpreter.cpp Wed Mar 17 16:40:25 2010 -0700 +++ b/src/share/vm/interpreter/bytecodeInterpreter.cpp Wed Mar 31 11:01:02 2010 -0700 @@ -2328,6 +2328,17 @@ run: } DEFAULT: +#ifdef ZERO + // Some zero configurations use the C++ interpreter as a + // fallback interpreter and have support for platform + // specific fast bytecodes which aren't supported here, so + // redispatch to the equivalent non-fast bytecode when they + // are encountered. + if (Bytecodes::is_defined((Bytecodes::Code)opcode)) { + opcode = (jubyte)Bytecodes::java_code((Bytecodes::Code)opcode); + goto opcode_switch; + } +#endif fatal2("\t*** Unimplemented opcode: %d = %s\n", opcode, Bytecodes::name((Bytecodes::Code)opcode)); goto finish; tom On Mar 31, 2010, at 3:18 AM, Edward Nevill wrote: > Hi Tom, > > The rewriting is done in > icedtea6/ports/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S > > The following fast/rewritten bytecodes are supported > > #define opc_bgetfield 0xcc > #define opc_cgetfield 0xcd > #define opc_igetfield 0xd0 > #define opc_lgetfield 0xd1 > #define opc_sgetfield 0xd2 > #define opc_aputfield 0xd3 > #define opc_bputfield 0xd4 > #define opc_cputfield 0xd5 > #define opc_iputfield 0xd8 > #define opc_lputfield 0xd9 > #define opc_iaccess_0 0xdb > #define opc_iaccess_1 0xdc > #define opc_iaccess_2 0xdd > #define opc_iaccess_3 0xde > #define opc_invokeresolved 0xdf > #define opc_invokespecialresolved 0xe0 > #define opc_invokestaticresolved 0xe1 > #define opc_invokevfinal 0xe2 > #define opc_iload_iload 0xe3 > #define opc_iload_iload_N 0xe4 > #define opc_dmac 0xe6 > #define opc_iload_0_iconst_N 0xe7 > #define opc_iload_1_iconst_N 0xe8 > #define opc_iload_2_iconst_N 0xe9 > #define opc_iload_3_iconst_N 0xea > #define opc_iload_iconst_N 0xeb > #define opc_iadd_istore_N 0xec > #define opc_isub_istore_N 0xed > #define opc_iand_istore_N 0xee > #define opc_ior_istore_N 0xef > #define opc_ixor_istore_N 0xf0 > #define opc_iadd_u4store 0xf1 > #define opc_isub_u4store 0xf2 > #define opc_iand_u4store 0xf3 > #define opc_ior_u4store 0xf4 > #define opc_ixor_u4store 0xf5 > #define opc_iload_0_iload 0xf6 > #define opc_iload_1_iload 0xf7 > #define opc_iload_2_iload 0xf8 > #define opc_iload_3_iload 0xf9 > #define opc_iload_0_iload_N 0xfa > #define opc_iload_1_iload_N 0xfb > #define opc_iload_2_iload_N 0xfc > #define opc_iload_3_iload_N 0xfd > > Under normal execution these bytecodes will be handled by > cppInterpreter_arm.s. > > However, there are a number of cases where it backs out to the C++ > interpreter. > > - If JvmtiExport::can_post_interpreter_events is true > > - If the ARM interpreter is built in conjunction with the Shark JIT and > the Shark JIT marks a method as non entrant. > > I agree with you that it would be possible / desirable for the C++ > interpreter to support these bytecodes directly, however... > > - Performance is not a particular issue in either of the above cases so > the fact that the rewritten bytecodes are now slower than the non > rewritten variants does not matter. > > - There are a large number of bytecodes which are rewritten. This would > involve a large change to bytecodeInterpreter.cpp which would have to be > debugged, supported etc. > > - The rewritten bytecodes are architecture dependant. Well, at least, > some of them are, and some of them are not. > > The file hotspot/src/share/vm/interpreter/bytecodes.cpp contains the > definitions of a number of the fast bytecodes (see > Bytecodes::initialize()) where a set of fast bytecodes is defined > between _fast_aputfield and _fast_binary_switch. > > Bytecodes::initialize() then calls > > // platform specific JVM bytecodes > pd_initialize(); > > To allow the platform to define its own specific bytecodes. In the case > of Zero / ARM this is done in > > icedtea6/ports/hotspot/src/cpu/zero/vm/bytecodes_zero.cpp > > where the rest of the fast bytecodes used by the ARM interpreter are > defined. > > Given that the fast bytecodes can be defined in a platform dependant > area of code like this it would seem wrong to add support for them to > bytecodeInterpreter.cpp which is in shared code because the set of fast > bytecodes may vary between platforms. > > What might be possible is for bytecodeInterpreter.cpp to #include say > "bytecodeInterpreter_pd.cpp". This would then allow rewritten bytecodes > to be added in a platform specific fashion. > > However, the fix I proposed is that in the default case, before throwing > a fatal error, the bytecode interpreter should perform a quick check to > see if the bytecode is defined, and in this case replace the bytecode > with the original bytecode and re-execute it. > > This would seem to be a fairly safe change to bytecodeInterpreter.cpp > since it only affects the case where a fatal error was to be thrown in > any case. > > Regards, > Ed. > > >> I don't understand this. Zero sets both RewriteFrequentPairs and >> RewriteBytecodes to true but it doesn't appear to have the logic to >> convert normal bytecodes into their fast variants so how does it run >> afoul of the fast bytecodes? Is there some code somewhere that I'm not >> seeing that injects the _fast variants? Strictly speaking >> RewriteFrequentPairs and RewriteBytecodes should be false if the C++ >> interpreter is being used but since it's all the responsibility of the >> interpreter itself having wrong settings for those flags doesn't really >> matter. >> >> If you really wanted to support RewriteFrequentPairs and RewriteBytecodes then you'd need to add the rewriting logic to inject the _fast variants and then add cases to handle them. The template interpreter has special implementations for each of the fast variants, including the pairs, so it doesn't convert them back to the normal version and redispatch. Redispatching will make the _fast variants slower than the normal variant which doesn't seem like a very good optimization. >> >> tom >> >> On Mar 30, 2010, at 3:07 AM, Gary Benson wrote: >> >>> Hi all, >>> >>> HotSpot has the capability to rewrite the bytecode stream, for example >>> to combine common instruction pairs, but the C++ interpreter has no >>> support for this. This webrev adds support for backing out over >>> rewritten bytecodes to the C++ interpreter, in much the same way as I >>> believe the template interpreter does. > From ed at camswl.com Wed Mar 31 11:32:23 2010 From: ed at camswl.com (Edward Nevill) Date: Wed, 31 Mar 2010 19:32:23 +0100 Subject: Review Request: Add fast bytecode support to C++ interpreter In-Reply-To: <3584518B-7FCF-456A-92F8-C93EBA16926A@oracle.com> References: <1270030699.30313.40.camel@mint> <3584518B-7FCF-456A-92F8-C93EBA16926A@oracle.com> Message-ID: <1270060343.2468.8.camel@mint> On Wed, 2010-03-31 at 11:01 -0700, Tom Rodriguez wrote: > I think that makes sense. So this isn't really adding support for fast bytecodes but providing a fallback path for a system with two different interpreters, one which supports fast bytecodes and one which doesn't. I think it would be best to keep this ifdef ZERO. What about this: > Correct. I am happy with your proposed modifications. Regards, Ed. From tom.rodriguez at oracle.com Wed Mar 31 11:56:06 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 31 Mar 2010 11:56:06 -0700 Subject: Review Request: Add fast bytecode support to C++ interpreter In-Reply-To: <1270060343.2468.8.camel@mint> References: <1270030699.30313.40.camel@mint> <3584518B-7FCF-456A-92F8-C93EBA16926A@oracle.com> <1270060343.2468.8.camel@mint> Message-ID: <52F3FB1C-7E3E-4786-ADB7-6F7E37BD618D@oracle.com> This will go in as 6939845. http://cr.openjdk.java.net/~never/6939845 tom On Mar 31, 2010, at 11:32 AM, Edward Nevill wrote: > On Wed, 2010-03-31 at 11:01 -0700, Tom Rodriguez wrote: >> I think that makes sense. So this isn't really adding support for fast bytecodes but providing a fallback path for a system with two different interpreters, one which supports fast bytecodes and one which doesn't. I think it would be best to keep this ifdef ZERO. What about this: >> > > Correct. I am happy with your proposed modifications. > > Regards, > Ed. > > From Christian.Thalinger at Sun.COM Wed Mar 31 12:03:40 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 31 Mar 2010 19:03:40 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6939731: JSR 292 Zero build fix after 6934494 Message-ID: <20100331190350.1886244BB0@hg.openjdk.java.net> Changeset: 47742b654fcb Author: twisti Date: 2010-03-31 08:03 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/47742b654fcb 6939731: JSR 292 Zero build fix after 6934494 Summary: The changes of 6934494 have broken the Zero build. Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/methodHandles_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.hpp From tom.rodriguez at oracle.com Wed Mar 31 12:34:27 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 31 Mar 2010 12:34:27 -0700 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> <1269866766.10926.11.camel@macbook> <3A38A1DE-7EF5-4F87-952B-12DC09B75D80@oracle.com> Message-ID: <89FF071D-4819-432C-A844-C8DE41C215AC@oracle.com> >>> Tom would know better as he did the changes, but we changed the code so >>> that C1 has the same unwinding mechanism as C2 does. This makes the C1 >>> code a bit simpler. >> >> Otherwise the unwind code has to do a call into the runtime to find out the nmethod frame_size so that it can take the frame off the stack properly. I just didn't like doing that and never liked that C1 and C2 did these differently for no good reason so it seemed easiest to make it work the same. > > That sounds reasonable, at first I thought that is a change that is related to invokedynamic. > When every exception dispatch goes through this exception handler, then this means that all of the "unwind" code (especially the unwind stub in the C1 runtime) can also go away? Not without rewriting our exception path. The unwind call is responsible for finding the pc in the caller to dispatch to and there's no way to eliminate that unless we find some way to perform both the lookup and unwind in one call. It's also used on it's own when we are throwing from a frame that we know doesn't have any exception handlers. >> >>> >>> Regarding performance, why do you think it affects performance >>> negatively? >> >> I don't see any reason that this should hurt performance, at least enough to matter. The unwind path is changed to a jump to a tiny trampoline in the nmethod that adjusts sp and jumps to the unwind handler, so you don't go directly to the unwind handler but it's pretty minimal. Are there are other code generation effects that would be expected? > > Exception stack unwinding will be a bit slower, but I guess that doesn't matter at all. > > I'm more concerned about the compilation speed of C1. Back in the days, I optimized under the assumption that most of the blocks don't have exception edges. This is now no longer true, since nearly every block now has an exception edge to the synthetic exception handler. Did you see an impact on the compilation time? To be honest I didn't expect any so I didn't look. I just ran some ad hoc tests and it seems like it's a 10% compile speed hit, which is pretty brutal. I guess our choices are to back it out and go with the extra call in the unwind path or to try to find some way to make the unwind handler operate differently. Could we make the default exception handler special in some way. The default exception handler block could be invisible to the rest of the system if it doesn't need to perform any unlocking since there are no values live into it, at least none that aren't bound. We could simply inject the default exception handler into the exception table when we are building it in Compilation::generate_exception_handler_table. Basically any table that doesn't end with a catch_all should dispatch to the default exception block. It's a little ugly but I think it would work. What do you think? tom > > Christian From john.r.rose at oracle.com Wed Mar 31 12:46:04 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 31 Mar 2010 12:46:04 -0700 Subject: Request for reviews (XL): 6939134: JSR 292 adjustments to method handle invocation In-Reply-To: References: <750A1A4D-3584-484C-88FA-88FE514E61C1@sun.com> <1269942561.982.126.camel@macbook> Message-ID: <5166E91B-B858-404F-BAB5-D34E42B8C91C@oracle.com> Christian's comments, plus the move mentioned below, are incorporated in the updated webrev: http://cr.openjdk.java.net/~jrose/6939134/hs-webrev.01 On Mar 30, 2010, at 3:12 PM, John Rose wrote: > On Mar 30, 2010, at 2:49 AM, Christian Thalinger wrote: > >> src/share/vm/prims/methodHandles.hpp: >> >> 273 //|(1<> >> What bug do we have here? > > I'm going to move that constant into the platform-specific assembly code where it belongs. AFAIK, the bug is only with the x86 code. -- John P.S. I pushed a draft fix to the OP_SPREAD_ARGS bug, as a separate patch, to the mlvm repo. Part of the bug involved getting the spread arguments backwards, since JVM arguments are stored in stack memory in reverse order from their appearance in varargs arrays. Perhaps that bug is in the sparc version also. From tom.rodriguez at oracle.com Wed Mar 31 15:43:41 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 31 Mar 2010 15:43:41 -0700 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <89FF071D-4819-432C-A844-C8DE41C215AC@oracle.com> References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> <1269866766.10926.11.camel@macbook> <3A38A1DE-7EF5-4F87-952B-12DC09B75D80@oracle.com> <89FF071D-4819-432C-A844-C8DE41C215AC@oracle.com> Message-ID: >> I'm more concerned about the compilation speed of C1. Back in the days, I optimized under the assumption that most of the blocks don't have exception edges. This is now no longer true, since nearly every block now has an exception edge to the synthetic exception handler. Did you see an impact on the compilation time? > > To be honest I didn't expect any so I didn't look. I just ran some ad hoc tests and it seems like it's a 10% compile speed hit, which is pretty brutal. I guess our choices are to back it out and go with the extra call in the unwind path or to try to find some way to make the unwind handler operate differently. Could we make the default exception handler special in some way. The default exception handler block could be invisible to the rest of the system if it doesn't need to perform any unlocking since there are no values live into it, at least none that aren't bound. We could simply inject the default exception handler into the exception table when we are building it in Compilation::generate_exception_handler_table. Basically any table that doesn't end with a catch_all should dispatch to the default exception block. It's a little ugly but I think it would work. What do you think? http://cr.openjdk.java.net/~never/6939930 is version which hides the unwind handler from the IR at the cost of a little extra hand written assembly. It fixes the compile speed loss. tom > > tom > >> >> Christian > From wimmer at ssw.jku.at Wed Mar 31 15:59:28 2010 From: wimmer at ssw.jku.at (Christian Wimmer) Date: Wed, 31 Mar 2010 15:59:28 -0700 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <89FF071D-4819-432C-A844-C8DE41C215AC@oracle.com> References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> <1269866766.10926.11.camel@macbook> <3A38A1DE-7EF5-4F87-952B-12DC09B75D80@oracle.com> <89FF071D-4819-432C-A844-C8DE41C215AC@oracle.com> Message-ID: <94A3DE52-E9C4-4735-AD73-96D1236CB662@ssw.jku.at> >> That sounds reasonable, at first I thought that is a change that is >> related to invokedynamic. >> When every exception dispatch goes through this exception handler, >> then this means that all of the "unwind" code (especially the >> unwind stub in the C1 runtime) can also go away? > > Not without rewriting our exception path. The unwind call is > responsible for finding the pc in the caller to dispatch to and > there's no way to eliminate that unless we find some way to perform > both the lookup and unwind in one call. It's also used on it's own > when we are throwing from a frame that we know doesn't have any > exception handlers. OK, I get it now. >> I'm more concerned about the compilation speed of C1. Back in the >> days, I optimized under the assumption that most of the blocks >> don't have exception edges. This is now no longer true, since >> nearly every block now has an exception edge to the synthetic >> exception handler. Did you see an impact on the compilation time? > > To be honest I didn't expect any so I didn't look. I just ran some > ad hoc tests and it seems like it's a 10% compile speed hit, which > is pretty brutal. I see a 6% to 12% compilation speed slowdown. > I guess our choices are to back it out and go with the extra call in > the unwind path or to try to find some way to make the unwind > handler operate differently. Could we make the default exception > handler special in some way. The default exception handler block > could be invisible to the rest of the system if it doesn't need to > perform any unlocking since there are no values live into it, at > least none that aren't bound. I would prefer that the default exception handler of normal and synchronized methods are handled in the same way. The only difference is the unlock for synchronized methods, but still the exception handler has no values flowing into it (because the unlock has not an instruction as the parameter, but always operates at lock 0). So the code you just sent should work. But if the method already has a catch-all handler (such as the one for synchronized methods), then the re-throw of this is handled again by the new default handler, basically leading to another round of exception-dispatch in the same method. A unified solution could be to always keep the synthetic exception handler, but don't generate all the unnecessary exception edges. Instead, it should be enough to just link it once from the the entry block (so that the exception handler is considered reachable). The entry point of this handler is then again remembered and faked into all exception handler tables. Christian From tom.rodriguez at oracle.com Wed Mar 31 16:23:56 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 31 Mar 2010 16:23:56 -0700 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: <94A3DE52-E9C4-4735-AD73-96D1236CB662@ssw.jku.at> References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> <1269866766.10926.11.camel@macbook> <3A38A1DE-7EF5-4F87-952B-12DC09B75D80@oracle.com> <89FF071D-4819-432C-A844-C8DE41C215AC@oracle.com> <94A3DE52-E9C4-4735-AD73-96D1236CB662@ssw.jku.at> Message-ID: >> I guess our choices are to back it out and go with the extra call in the unwind path or to try to find some way to make the unwind handler operate differently. Could we make the default exception handler special in some way. The default exception handler block could be invisible to the rest of the system if it doesn't need to perform any unlocking since there are no values live into it, at least none that aren't bound. > > I would prefer that the default exception handler of normal and synchronized methods are handled in the same way. The only difference is the unlock for synchronized methods, but still the exception handler has no values flowing into it (because the unlock has not an instruction as the parameter, but always operates at lock 0). It's true that in the final generated code we don't actually use the passed in object and instead retrieve it from the BasicObjectLock but the IR shows it as being used which is kind of misleading. I might be tempted to remove it though it is helpful when reading the printed IR. > > So the code you just sent should work. But if the method already has a catch-all handler (such as the one for synchronized methods), then the re-throw of this is handled again by the new default handler, basically leading to another round of exception-dispatch in the same method. Any catch_all handler that terminates with a throw should trigger this logic in LIRGenerator::do_Throw: // check if the instruction has an xhandler in any of the nested scopes bool unwind = false; if (info->exception_handlers()->length() == 0) { // this throw is not inside an xhandler unwind = true; } else { which will convert the throw into an unwind. We will have an exception handler table entry that would dispatch it to the default handler but we will never perform the lookup so I think it's ok. > A unified solution could be to always keep the synthetic exception handler, but don't generate all the unnecessary exception edges. Instead, it should be enough to just link it once from the the entry block (so that the exception handler is considered reachable). The entry point of this handler is then again remembered and faked into all exception handler tables. I played a little bit with something like that but getting it properly hooked up seemed problematic. I didn't try simply hooking it off the . I do like the idea of a unified solution. That's really what I was trying to get with the original changes. Where do you think I would hook that up? I'd have to do it at after parsing all the blocks wouldn't I? Otherwise I assume that xhandler would propagate to following blocks. Maybe hook it up just before the fill_sync_handler? tom > > Christian > From wimmer at ssw.jku.at Wed Mar 31 16:56:50 2010 From: wimmer at ssw.jku.at (Christian Wimmer) Date: Wed, 31 Mar 2010 16:56:50 -0700 Subject: Request for reviews (XL): 6919934: JSR 292 needs to support x86 C1 In-Reply-To: References: <4B799495.5030605@Sun.COM> <55E9F9FF-3977-4029-BEF0-1BE0BAADB0C6@sun.com> <4B7AF2C6.70207@Sun.COM> <10866CCA-D198-4471-9BCB-75D88BB764F4@Sun.COM> <1268134418.1823.63.camel@macbook> <6F157268-845B-436B-B2A7-2DC1C39E5892@uci.edu> <1269866766.10926.11.camel@macbook> <3A38A1DE-7EF5-4F87-952B-12DC09B75D80@oracle.com> <89FF071D-4819-432C-A844-C8DE41C215AC@oracle.com> <94A3DE52-E9C4-4735-AD73-96D1236CB662@ssw.jku.at> Message-ID: <0A302787-F390-40D1-A4EF-D3952E437808@ssw.jku.at> >> A unified solution could be to always keep the synthetic exception >> handler, but don't generate all the unnecessary exception edges. >> Instead, it should be enough to just link it once from the the >> entry block (so that the exception handler is considered >> reachable). The entry point of this handler is then again >> remembered and faked into all exception handler tables. > > I played a little bit with something like that but getting it > properly hooked up seemed problematic. I didn't try simply hooking > it off the . I do like the idea of a unified solution. That's > really what I was trying to get with the original changes. Where do > you think I would hook that up? I'd have to do it at after parsing > all the blocks wouldn't I? Otherwise I assume that xhandler would > propagate to following blocks. Maybe hook it up just before the > fill_sync_handler? Yes, after IR construction would be the best place to hook it up. The only tricky thing is to not register the default exception handler as an exception handler of itself. Another idea: put the unlocking code for synchronized methods also in the special exception handling code that you sent. That way, we have no synthetic exception handler at all in the IR. In some sense, that is going back to the state before we introduced the synthetic exception handler, but this time the locking and unlocking for normal method entries and exits of course remains explicit in the IR. In any case, it is no longer legal to unwind directly at a throw instruction where exception_handlers()->length() == 0 Christian From thomas.rodriguez at sun.com Wed Mar 31 18:33:05 2010 From: thomas.rodriguez at sun.com (thomas.rodriguez at sun.com) Date: Thu, 01 Apr 2010 01:33:05 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20100401013323.B73F344C17@hg.openjdk.java.net> Changeset: f61d795ce6de Author: never Date: 2010-03-31 11:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f61d795ce6de 6939845: zero needs fallback path in C++ interpreter for platform dependent fast bytecodes Reviewed-by: never Contributed-by: ed at camswl.com ! src/share/vm/interpreter/bytecodeInterpreter.cpp Changeset: 7f4deda46b04 Author: never Date: 2010-03-31 16:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7f4deda46b04 Merge