From vladimir.kozlov at oracle.com Fri Oct 1 06:46:11 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 01 Oct 2010 13:46:11 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6916062: assert(_inserts <= _insert_limit, "hash table overflow") in NodeHash::hash_insert Message-ID: <20101001134619.AB8B047E1D@hg.openjdk.java.net> Changeset: 56601ef83436 Author: kvn Date: 2010-09-30 18:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/56601ef83436 6916062: assert(_inserts <= _insert_limit,"hash table overflow") in NodeHash::hash_insert Summary: Missing check for not empty worklist when puting memory node back on worklist and expecting address type update. Reviewed-by: never ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/phaseX.cpp From Ulf.Zibis at gmx.de Fri Oct 1 07:06:09 2010 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 01 Oct 2010 16:06:09 +0200 Subject: review (S) for 6968348: Byteswapped memory access can point to wrong location after JIT In-Reply-To: References: <4CA46A90.2010401@gmx.de> <823F148D-87F1-40EB-81F0-DD9E65E4BB3D@oracle.com> <4CA506D0.6070503@gmx.de> Message-ID: <4CA5EAD1.7010109@gmx.de> Am 01.10.2010 00:10, schrieb Tom Rodriguez: > On Sep 30, 2010, at 2:53 PM, Ulf Zibis wrote: > >> Ah, ok, I'm running on Intel 32-bit architecture. >> Is it ensured, that this test is always running on 64-bit architectures, but never on 32-bits? > No. Why should it be? It's valid code whereever it runs and we run our tests on all architectures. > Tom, thanks for clarification. Yes, I was little confused. -Ulf From mark.g.j.christiaens at gmail.com Mon Oct 4 02:02:17 2010 From: mark.g.j.christiaens at gmail.com (Mark Christiaens) Date: Mon, 4 Oct 2010 11:02:17 +0200 Subject: Speed regression? Message-ID: I suspect that there may be a speed regression. See the "Monte Carlo" entry of the scimark benchmark: On build 110: /usr/java/latest/bin/java -XX:+AggressiveOpts -XX:+UseFPUForSpilling -cp scimark2lib.jar jnt/scimark2/commandline SciMark 2.0a Composite Score: 1141.003846727709 FFT (1024): 710.19567440319 SOR (100x100): 1275.7066629070716 Monte Carlo : 620.660007029971 Sparse matmult (N=1000, nz=5000): 1237.695921732067 LU (100x100): 1860.760967566245 On build 112: /usr/java/latest/bin/java -XX:+AggressiveOpts -cp scimark2lib.jar jnt/scimark2/commandline SciMark 2.0a Composite Score: 1042.2369328772832 FFT (1024): 713.0991697764947 SOR (100x100): 1276.9747697972227 Monte Carlo : 212.3698130107359 Sparse matmult (N=1000, nz=5000): 1061.7415523163634 LU (100x100): 1946.9993594855982 My CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz My OS: Fedora 13, 64 bit Kind regards, Mark -- Mark Christiaens Ganzeplas 23 9880 Aalter 09 / 325 07 40 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101004/8f2fbff2/attachment.html From vladimir.kozlov at oracle.com Mon Oct 4 11:59:04 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Oct 2010 11:59:04 -0700 Subject: Speed regression? In-Reply-To: References: Message-ID: <4CAA23F8.7080402@oracle.com> Thank you, Mark I reproduced it on our Linux box and filed bug: 6989368: Regression in scimark2.MonteCarlo in jdk7_b112 on Linux Thanks, Vladimir Mark Christiaens wrote: > I suspect that there may be a speed regression. See the "Monte Carlo" > entry of the scimark benchmark: > > On build 110: > > /usr/java/latest/bin/java -XX:+AggressiveOpts -XX:+UseFPUForSpilling -cp > scimark2lib.jar jnt/scimark2/commandline > > SciMark 2.0a > > Composite Score: 1141.003846727709 > FFT (1024): 710.19567440319 > SOR (100x100): 1275.7066629070716 > Monte Carlo : 620.660007029971 > Sparse matmult (N=1000, nz=5000): 1237.695921732067 > LU (100x100): 1860.760967566245 > > On build 112: > > /usr/java/latest/bin/java -XX:+AggressiveOpts -cp scimark2lib.jar > jnt/scimark2/commandline > > SciMark 2.0a > > Composite Score: 1042.2369328772832 > FFT (1024): 713.0991697764947 > SOR (100x100): 1276.9747697972227 > Monte Carlo : 212.3698130107359 > Sparse matmult (N=1000, nz=5000): 1061.7415523163634 > LU (100x100): 1946.9993594855982 > > My CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz > My OS: Fedora 13, 64 bit > > Kind regards, > > Mark > > > > > -- > Mark Christiaens > Ganzeplas 23 > 9880 Aalter > 09 / 325 07 40 From igor.veresov at oracle.com Mon Oct 4 14:03:39 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 04 Oct 2010 14:03:39 -0700 Subject: Request for review(XXS): 6989368: Regression in scimark2.MonteCarlo in jdk7_b112 on Linux Message-ID: <4CAA412B.5000103@oracle.com> Thanks to Mark Christiaens for noticing it. And Vladimir for analysis! ciMethod::instructions_size() returns incorrect value after "6953144: Tiered compilation" changes. The method code was merged incorrectly with changes for "6978355: renaming for 6961697". code->insts_end() should be used instead of code->code_end(). Webrev: http://cr.openjdk.java.net/~iveresov/6989368/webrev.00 Verified with scimark. Thanks, igor From vladimir.kozlov at oracle.com Mon Oct 4 14:33:30 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Oct 2010 14:33:30 -0700 Subject: Request for review(XXS): 6989368: Regression in scimark2.MonteCarlo in jdk7_b112 on Linux In-Reply-To: <4CAA412B.5000103@oracle.com> References: <4CAA412B.5000103@oracle.com> Message-ID: <4CAA482A.8070403@oracle.com> Thank you, Igor Looks good. Vladimir Igor Veresov wrote: > Thanks to Mark Christiaens for noticing it. And Vladimir for analysis! > > ciMethod::instructions_size() returns incorrect value after "6953144: > Tiered compilation" changes. The method code was merged incorrectly with > changes for "6978355: renaming for 6961697". code->insts_end() should be > used instead of code->code_end(). > > > Webrev: http://cr.openjdk.java.net/~iveresov/6989368/webrev.00 > > > Verified with scimark. > > Thanks, > igor From puzzlesdj at gmail.com Mon Oct 4 17:42:17 2010 From: puzzlesdj at gmail.com (ddmetro) Date: Mon, 4 Oct 2010 17:42:17 -0700 (PDT) Subject: help on starting point of hotspot jvm In-Reply-To: <1285227489.14822.4030.camel@macbook> References: <29785128.post@talk.nabble.com> <1285227489.14822.4030.camel@macbook> Message-ID: <29883454.post@talk.nabble.com> Thanks Christian. 1. I have added printfs in all the java.c files under the /hotspot folder. I then ran >make hotspot. Now I am trying to launch a class file HelloWorld.class from location: "/home/dhiraj/Desktop/PP-2/hotspot/icedtea/icedtea6-1.8/openjdk/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product" by the command: >./gamma HelloWorld However, it gives the following error: error while loading shared libraries: libjvm.so: cannot open shared object file: No such file or directory Quesiton: I am trying to test the changes made in the hotspot code after building it. Kindly point out what am I missing out in here. I am doing this to get to the starting point of code, when >java HelloWorld is executed. Thanking You, Dhiraj Padnani. -- View this message in context: http://old.nabble.com/help-on-starting-point-of-hotspot-jvm-tp29785128p29883454.html Sent from the OpenJDK Hotspot Compiler Development List mailing list archive at Nabble.com. From vladimir.kozlov at oracle.com Mon Oct 4 17:48:28 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Oct 2010 17:48:28 -0700 Subject: Request for reviews (S): 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big Message-ID: <4CAA75DC.1030302@oracle.com> http://cr.openjdk.java.net/~kvn/6979458/webrev Fixed 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big ObjectAlignmentInBytes should not be larger then default page size used by VM. Set upper limit 256 for ObjectAlignmentInBytes value. From tom.rodriguez at oracle.com Mon Oct 4 18:39:49 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 4 Oct 2010 18:39:49 -0700 Subject: Request for reviews (S): 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big In-Reply-To: <4CAA75DC.1030302@oracle.com> References: <4CAA75DC.1030302@oracle.com> Message-ID: must be not greater -> must not be greater Looks good. tom On Oct 4, 2010, at 5:48 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6979458/webrev > > Fixed 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big > > ObjectAlignmentInBytes should not be larger then > default page size used by VM. Set upper limit 256 > for ObjectAlignmentInBytes value. From igor.veresov at oracle.com Mon Oct 4 19:02:28 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 04 Oct 2010 19:02:28 -0700 Subject: Request for reviews (S): 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big In-Reply-To: <4CAA75DC.1030302@oracle.com> References: <4CAA75DC.1030302@oracle.com> Message-ID: <4CAA8734.6030500@oracle.com> I don't think there are <= 256 byte pages in nature. Looks good anyways. igor On 10/4/10 5:48 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/6979458/webrev > > Fixed 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big > > ObjectAlignmentInBytes should not be larger then > default page size used by VM. Set upper limit 256 > for ObjectAlignmentInBytes value. From vladimir.kozlov at oracle.com Mon Oct 4 19:06:37 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 04 Oct 2010 19:06:37 -0700 Subject: Request for reviews (S): 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big In-Reply-To: References: <4CAA75DC.1030302@oracle.com> Message-ID: <4CAA882D.9030901@oracle.com> Thank you, Tom Vladimir On 10/4/10 6:39 PM, Tom Rodriguez wrote: > must be not greater -> must not be greater > > Looks good. > > tom > > On Oct 4, 2010, at 5:48 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6979458/webrev >> >> Fixed 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big >> >> ObjectAlignmentInBytes should not be larger then >> default page size used by VM. Set upper limit 256 >> for ObjectAlignmentInBytes value. > From igor.veresov at oracle.com Mon Oct 4 19:27:19 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 04 Oct 2010 19:27:19 -0700 Subject: Request for review(XXS): 6989368: Regression in scimark2.MonteCarlo in jdk7_b112 on Linux In-Reply-To: <4CAA482A.8070403@oracle.com> References: <4CAA412B.5000103@oracle.com> <4CAA482A.8070403@oracle.com> Message-ID: <4CAA8D07.6060507@oracle.com> Thanks, Vladimir! igor On 10/4/10 2:33 PM, Vladimir Kozlov wrote: > Thank you, Igor > > Looks good. > > Vladimir > > Igor Veresov wrote: >> Thanks to Mark Christiaens for noticing it. And Vladimir for analysis! >> >> ciMethod::instructions_size() returns incorrect value after "6953144: >> Tiered compilation" changes. The method code was merged incorrectly >> with changes for "6978355: renaming for 6961697". code->insts_end() >> should be used instead of code->code_end(). >> >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6989368/webrev.00 >> >> >> Verified with scimark. >> >> Thanks, >> igor From tom.rodriguez at oracle.com Mon Oct 4 22:51:11 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 05 Oct 2010 05:51:11 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6968348: Byteswapped memory access can point to wrong location after JIT Message-ID: <20101005055115.A17AE47EF5@hg.openjdk.java.net> Changeset: 52e82a6bedaf Author: never Date: 2010-10-04 17:09 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/52e82a6bedaf 6968348: Byteswapped memory access can point to wrong location after JIT Reviewed-by: twisti, kvn, iveresov ! src/cpu/x86/vm/x86_64.ad + test/compiler/6968348/Test6968348.java From christian.thalinger at oracle.com Mon Oct 4 23:49:05 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 05 Oct 2010 08:49:05 +0200 Subject: Request for review(XXS): 6989368: Regression in scimark2.MonteCarlo in jdk7_b112 on Linux In-Reply-To: <4CAA412B.5000103@oracle.com> References: <4CAA412B.5000103@oracle.com> Message-ID: <1286261345.9946.647.camel@macbook> On Mon, 2010-10-04 at 14:03 -0700, Igor Veresov wrote: > Thanks to Mark Christiaens for noticing it. And Vladimir for analysis! > > ciMethod::instructions_size() returns incorrect value after "6953144: > Tiered compilation" changes. The method code was merged incorrectly with > changes for "6978355: renaming for 6961697". code->insts_end() should be > used instead of code->code_end(). > > > Webrev: http://cr.openjdk.java.net/~iveresov/6989368/webrev.00 > > > Verified with scimark. Looks good. -- Christian From christian.thalinger at oracle.com Mon Oct 4 23:54:51 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 05 Oct 2010 08:54:51 +0200 Subject: help on starting point of hotspot jvm In-Reply-To: <29883454.post@talk.nabble.com> References: <29785128.post@talk.nabble.com> <1285227489.14822.4030.camel@macbook> <29883454.post@talk.nabble.com> Message-ID: <1286261691.9946.654.camel@macbook> On Mon, 2010-10-04 at 17:42 -0700, ddmetro wrote: > >./gamma HelloWorld > > However, it gives the following error: > error while loading shared libraries: libjvm.so: cannot open shared object > file: No such file or directory source env.sh before running gamma. -- Christian From igor.veresov at oracle.com Tue Oct 5 00:12:39 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 05 Oct 2010 00:12:39 -0700 Subject: Request for review(XXS): 6989368: Regression in scimark2.MonteCarlo in jdk7_b112 on Linux In-Reply-To: <1286261345.9946.647.camel@macbook> References: <4CAA412B.5000103@oracle.com> <1286261345.9946.647.camel@macbook> Message-ID: <4CAACFE7.8080108@oracle.com> Thanks, Christian! igor On 10/4/10 11:49 PM, Christian Thalinger wrote: > On Mon, 2010-10-04 at 14:03 -0700, Igor Veresov wrote: >> Thanks to Mark Christiaens for noticing it. And Vladimir for analysis! >> >> ciMethod::instructions_size() returns incorrect value after "6953144: >> Tiered compilation" changes. The method code was merged incorrectly with >> changes for "6978355: renaming for 6961697". code->insts_end() should be >> used instead of code->code_end(). >> >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6989368/webrev.00 >> >> >> Verified with scimark. > > Looks good. -- Christian > From igor.veresov at oracle.com Tue Oct 5 03:12:26 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Tue, 05 Oct 2010 10:12:26 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6989368: Regression in scimark2.MonteCarlo in jdk7_b112 on Linux Message-ID: <20101005101233.0466E47F00@hg.openjdk.java.net> Changeset: 3f9a70eb8b1f Author: iveresov Date: 2010-10-05 00:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3f9a70eb8b1f 6989368: Regression in scimark2.MonteCarlo in jdk7_b112 on Linux Summary: Fix ciMethod::instructions_size() to return correct value Reviewed-by: kvn, twisti ! src/share/vm/ci/ciMethod.cpp From vladimir.kozlov at oracle.com Tue Oct 5 11:07:17 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 05 Oct 2010 18:07:17 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big Message-ID: <20101005180720.890D347F14@hg.openjdk.java.net> Changeset: fe08403130db Author: kvn Date: 2010-10-05 08:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fe08403130db 6979458: VM crashes when -XX:ObjectAlignmentInBytes is too big Summary: Set upper limit 256 for ObjectAlignmentInBytes value. Reviewed-by: never, iveresov ! src/share/vm/runtime/arguments.cpp From tom.rodriguez at oracle.com Tue Oct 5 13:23:25 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 05 Oct 2010 20:23:25 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler Message-ID: <20101005202330.409B147F1B@hg.openjdk.java.net> Changeset: a3f7f95b0165 Author: never Date: 2010-10-05 11:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a3f7f95b0165 6988018: dtrace/hotspot/MethodInvocation/MethodInvocation002 crashes with client compiler Reviewed-by: iveresov, kvn, kamg ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp From tom.rodriguez at oracle.com Tue Oct 5 15:40:29 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 5 Oct 2010 15:40:29 -0700 Subject: review (S) for 6989736: fix mapfile warnings on solaris Message-ID: <54651CD5-5C14-42CA-9BD8-93DD5779A3E4@oracle.com> http://cr.openjdk.java.net/~never/6989736 6989736: fix mapfile warnings on solaris Reviewed-by: The map files are getting out of date resulting in a bunch of warnings for product builds so it's time to clean them again. The 64 bit tiered reorder files have only recently started being used and those have a lot of entries out of date. I also fixed a minor build issue where the first build of the adlc didn't run the fix_lines portion of the adlc_updater which caused the next incremental build to regenerate some files because the #line directives had changed. Tested by building each target. I attached the automated script I used for this to the bug report. From igor.veresov at oracle.com Tue Oct 5 15:57:48 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 05 Oct 2010 15:57:48 -0700 Subject: review (S) for 6989736: fix mapfile warnings on solaris In-Reply-To: <54651CD5-5C14-42CA-9BD8-93DD5779A3E4@oracle.com> References: <54651CD5-5C14-42CA-9BD8-93DD5779A3E4@oracle.com> Message-ID: <4CABAD6C.9050508@oracle.com> Looks good. igor On 10/5/10 3:40 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6989736 > > 6989736: fix mapfile warnings on solaris > Reviewed-by: > > The map files are getting out of date resulting in a bunch of warnings > for product builds so it's time to clean them again. The 64 bit > tiered reorder files have only recently started being used and those > have a lot of entries out of date. I also fixed a minor build issue > where the first build of the adlc didn't run the fix_lines portion of > the adlc_updater which caused the next incremental build to regenerate > some files because the #line directives had changed. Tested by > building each target. I attached the automated script I used for this > to the bug report. From vladimir.kozlov at oracle.com Tue Oct 5 16:15:30 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 05 Oct 2010 16:15:30 -0700 Subject: review (S) for 6989736: fix mapfile warnings on solaris In-Reply-To: <54651CD5-5C14-42CA-9BD8-93DD5779A3E4@oracle.com> References: <54651CD5-5C14-42CA-9BD8-93DD5779A3E4@oracle.com> Message-ID: <4CABB192.60604@oracle.com> Tom, It seems, nobody want to spend time to regenerate reorder files for several years already. What we only do is removing lines from these files which produce warnings. May be we should add your script into sources and use it more frequently: make/solaris/clear_mapfile_warnings.sh Otherwise looks good. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6989736 > > 6989736: fix mapfile warnings on solaris > Reviewed-by: > > The map files are getting out of date resulting in a bunch of warnings > for product builds so it's time to clean them again. The 64 bit > tiered reorder files have only recently started being used and those > have a lot of entries out of date. I also fixed a minor build issue > where the first build of the adlc didn't run the fix_lines portion of > the adlc_updater which caused the next incremental build to regenerate > some files because the #line directives had changed. Tested by > building each target. I attached the automated script I used for this > to the bug report. From tom.rodriguez at oracle.com Tue Oct 5 16:33:16 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 5 Oct 2010 16:33:16 -0700 Subject: review (S) for 6989736: fix mapfile warnings on solaris In-Reply-To: <4CABB192.60604@oracle.com> References: <54651CD5-5C14-42CA-9BD8-93DD5779A3E4@oracle.com> <4CABB192.60604@oracle.com> Message-ID: <2E64B682-5D54-4968-99DB-661C4F282580@oracle.com> On Oct 5, 2010, at 4:15 PM, Vladimir Kozlov wrote: > Tom, > > It seems, nobody want to spend time to regenerate reorder files > for several years already. What we only do is removing lines > from these files which produce warnings. May be we should add > your script into sources and use it more frequently: Yes they are dying a death of a thousand cuts. If I remember correct, removing their use seemed to hurt startup but regenerating them didn't seem to help. I'd rather not put the script in the repo though. tom > > make/solaris/clear_mapfile_warnings.sh > > Otherwise looks good. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6989736 >> 6989736: fix mapfile warnings on solaris >> Reviewed-by: >> The map files are getting out of date resulting in a bunch of warnings >> for product builds so it's time to clean them again. The 64 bit >> tiered reorder files have only recently started being used and those >> have a lot of entries out of date. I also fixed a minor build issue >> where the first build of the adlc didn't run the fix_lines portion of >> the adlc_updater which caused the next incremental build to regenerate >> some files because the #line directives had changed. Tested by >> building each target. I attached the automated script I used for this >> to the bug report. From John.Coomes at oracle.com Tue Oct 5 16:49:08 2010 From: John.Coomes at oracle.com (John Coomes) Date: Tue, 5 Oct 2010 16:49:08 -0700 Subject: review (S) for 6989736: fix mapfile warnings on solaris In-Reply-To: <4CABB192.60604@oracle.com> References: <54651CD5-5C14-42CA-9BD8-93DD5779A3E4@oracle.com> <4CABB192.60604@oracle.com> Message-ID: <19627.47476.156296.534946@oracle.com> Vladimir Kozlov (vladimir.kozlov at oracle.com) wrote: > Tom, > > It seems, nobody want to spend time to regenerate reorder files > for several years already. What we only do is removing lines > from these files which produce warnings. ... Right. The files are so out of date they may not be improving performance, and for all we know could be hurting it. I'd vote to just get rid of it all until someone automates it or commits to keeping it up to date. I filed 6989819. > Otherwise looks good. Yes, the changes look fine to me, too. -John > Tom Rodriguez wrote: > > http://cr.openjdk.java.net/~never/6989736 > > > > 6989736: fix mapfile warnings on solaris > > Reviewed-by: > > > > The map files are getting out of date resulting in a bunch of warnings > > for product builds so it's time to clean them again. The 64 bit > > tiered reorder files have only recently started being used and those > > have a lot of entries out of date. I also fixed a minor build issue > > where the first build of the adlc didn't run the fix_lines portion of > > the adlc_updater which caused the next incremental build to regenerate > > some files because the #line directives had changed. Tested by > > building each target. I attached the automated script I used for this > > to the bug report. From john.pampuch at oracle.com Tue Oct 5 17:07:31 2010 From: john.pampuch at oracle.com (John Pampuch) Date: Tue, 05 Oct 2010 17:07:31 -0700 Subject: review (S) for 6989736: fix mapfile warnings on solaris In-Reply-To: <2E64B682-5D54-4968-99DB-661C4F282580@oracle.com> References: <54651CD5-5C14-42CA-9BD8-93DD5779A3E4@oracle.com> <4CABB192.60604@oracle.com> <2E64B682-5D54-4968-99DB-661C4F282580@oracle.com> Message-ID: <4CABBDC3.3080409@oracle.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101005/5f9bf4c0/attachment.html From vladimir.kozlov at Oracle.com Tue Oct 5 17:19:14 2010 From: vladimir.kozlov at Oracle.com (Vladimir Kozlov) Date: Tue, 05 Oct 2010 17:19:14 -0700 Subject: review (S) for 6989736: fix mapfile warnings on solaris In-Reply-To: <2E64B682-5D54-4968-99DB-661C4F282580@oracle.com> References: <54651CD5-5C14-42CA-9BD8-93DD5779A3E4@oracle.com> <4CABB192.60604@oracle.com> <2E64B682-5D54-4968-99DB-661C4F282580@oracle.com> Message-ID: <4CABC082.3040703@oracle.com> Tom Rodriguez wrote: > On Oct 5, 2010, at 4:15 PM, Vladimir Kozlov wrote: > >> Tom, >> >> It seems, nobody want to spend time to regenerate reorder files >> for several years already. What we only do is removing lines >> from these files which produce warnings. May be we should add >> your script into sources and use it more frequently: > > Yes they are dying a death of a thousand cuts. If I remember correct, removing their use seemed to hurt startup but regenerating them didn't seem to help. I'd rather not put the script in the repo though. It was true several years ago when I tried to regenerate them using collector/analyzer tool which can produce map files. I got regression so I dropped the project. I agree with John Coomes that we should see how they affect performance in current state and remove them. But for now I want this cleanup since we don't know when 6989819 will be processed. Tom, you can go with current change (without script in sources). Thanks, Vladimir > > tom > >> make/solaris/clear_mapfile_warnings.sh >> >> Otherwise looks good. >> >> Thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6989736 >>> 6989736: fix mapfile warnings on solaris >>> Reviewed-by: >>> The map files are getting out of date resulting in a bunch of warnings >>> for product builds so it's time to clean them again. The 64 bit >>> tiered reorder files have only recently started being used and those >>> have a lot of entries out of date. I also fixed a minor build issue >>> where the first build of the adlc didn't run the fix_lines portion of >>> the adlc_updater which caused the next incremental build to regenerate >>> some files because the #line directives had changed. Tested by >>> building each target. I attached the automated script I used for this >>> to the bug report. > From tom.rodriguez at oracle.com Tue Oct 5 17:35:02 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 5 Oct 2010 17:35:02 -0700 Subject: review (S) for 6989736: fix mapfile warnings on solaris In-Reply-To: <4CABC082.3040703@oracle.com> References: <54651CD5-5C14-42CA-9BD8-93DD5779A3E4@oracle.com> <4CABB192.60604@oracle.com> <2E64B682-5D54-4968-99DB-661C4F282580@oracle.com> <4CABC082.3040703@oracle.com> Message-ID: <209A7F15-DDF6-468A-936A-6EDFB8F07177@oracle.com> Sounds good to me. Thanks for the reviews. tom On Oct 5, 2010, at 5:19 PM, Vladimir Kozlov wrote: > Tom Rodriguez wrote: >> On Oct 5, 2010, at 4:15 PM, Vladimir Kozlov wrote: >>> Tom, >>> >>> It seems, nobody want to spend time to regenerate reorder files >>> for several years already. What we only do is removing lines >>> from these files which produce warnings. May be we should add >>> your script into sources and use it more frequently: >> Yes they are dying a death of a thousand cuts. If I remember correct, removing their use seemed to hurt startup but regenerating them didn't seem to help. I'd rather not put the script in the repo though. > > It was true several years ago when I tried to regenerate > them using collector/analyzer tool which can produce map files. > I got regression so I dropped the project. > > I agree with John Coomes that we should see how they > affect performance in current state and remove them. > > But for now I want this cleanup since we don't know when > 6989819 will be processed. > Tom, you can go with current change (without script in sources). > > Thanks, > Vladimir > >> tom >>> make/solaris/clear_mapfile_warnings.sh >>> >>> Otherwise looks good. >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6989736 >>>> 6989736: fix mapfile warnings on solaris >>>> Reviewed-by: >>>> The map files are getting out of date resulting in a bunch of warnings >>>> for product builds so it's time to clean them again. The 64 bit >>>> tiered reorder files have only recently started being used and those >>>> have a lot of entries out of date. I also fixed a minor build issue >>>> where the first build of the adlc didn't run the fix_lines portion of >>>> the adlc_updater which caused the next incremental build to regenerate >>>> some files because the #line directives had changed. Tested by >>>> building each target. I attached the automated script I used for this >>>> to the bug report. From tom.rodriguez at oracle.com Tue Oct 5 22:47:53 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 06 Oct 2010 05:47:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6989736: fix mapfile warnings on solaris Message-ID: <20101006054758.4168A47F35@hg.openjdk.java.net> Changeset: a50abfc67f31 Author: never Date: 2010-10-05 17:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a50abfc67f31 6989736: fix mapfile warnings on solaris Reviewed-by: kvn, iveresov, jcoomes ! make/linux/adlc_updater ! make/solaris/adlc_updater ! make/solaris/makefiles/reorder_COMPILER1_i486 ! make/solaris/makefiles/reorder_COMPILER1_sparc ! make/solaris/makefiles/reorder_TIERED_amd64 ! make/solaris/makefiles/reorder_TIERED_i486 ! make/solaris/makefiles/reorder_TIERED_sparc ! make/solaris/makefiles/reorder_TIERED_sparcv9 From james.melvin at oracle.com Wed Oct 6 06:31:20 2010 From: james.melvin at oracle.com (James Melvin) Date: Wed, 06 Oct 2010 09:31:20 -0400 Subject: review (S) for 6989736: fix mapfile warnings on solaris In-Reply-To: <4CABBDC3.3080409@oracle.com> References: <54651CD5-5C14-42CA-9BD8-93DD5779A3E4@oracle.com> <4CABB192.60604@oracle.com> <2E64B682-5D54-4968-99DB-661C4F282580@oracle.com> <4CABBDC3.3080409@oracle.com> Message-ID: <4CAC7A28.4000309@oracle.com> We also need to consider periodic tuning of the class data sharing archive, perhaps with a more modern list of training apps. I would also mention the Quick Starter archive as well, but I believe we are doing away with this in JDK7. - Jim On 10/5/10 8:07 PM, John Pampuch wrote: > Is this something that Jerry's team should be looking at? Maybe they > should work on automating the reorder file generation? > > If there aren't objections, can you get someone too look at it Jerry? > > -John > > On 10/5/10 4:33 PM, Tom Rodriguez wrote: >> On Oct 5, 2010, at 4:15 PM, Vladimir Kozlov wrote: >> >>> Tom, >>> >>> It seems, nobody want to spend time to regenerate reorder files >>> for several years already. What we only do is removing lines >>> from these files which produce warnings. May be we should add >>> your script into sources and use it more frequently: >> Yes they are dying a death of a thousand cuts. If I remember correct, removing their use seemed to hurt startup but regenerating them didn't seem to help. I'd rather not put the script in the repo though. >> >> tom >> >>> make/solaris/clear_mapfile_warnings.sh >>> >>> Otherwise looks good. >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6989736 >>>> 6989736: fix mapfile warnings on solaris >>>> Reviewed-by: >>>> The map files are getting out of date resulting in a bunch of warnings >>>> for product builds so it's time to clean them again. The 64 bit >>>> tiered reorder files have only recently started being used and those >>>> have a lot of entries out of date. I also fixed a minor build issue >>>> where the first build of the adlc didn't run the fix_lines portion of >>>> the adlc_updater which caused the next incremental build to regenerate >>>> some files because the #line directives had changed. Tested by >>>> building each target. I attached the automated script I used for this >>>> to the bug report. From jerry.driscoll at oracle.com Tue Oct 5 18:12:54 2010 From: jerry.driscoll at oracle.com (Jerry Driscoll) Date: Tue, 5 Oct 2010 18:12:54 -0700 Subject: review (S) for 6989736: fix mapfile warnings on solaris In-Reply-To: <4CABBDC3.3080409@oracle.com> References: <54651CD5-5C14-42CA-9BD8-93DD5779A3E4@oracle.com> <4CABB192.60604@oracle.com> <2E64B682-5D54-4968-99DB-661C4F282580@oracle.com> <4CABBDC3.3080409@oracle.com> Message-ID: I'll see if I can get someone to help. jerry On Oct 5, 2010, at 5:07 PM, John Pampuch wrote: > Is this something that Jerry's team should be looking at? Maybe they should work on automating the reorder file generation? > > If there aren't objections, can you get someone too look at it Jerry? > > -John > > On 10/5/10 4:33 PM, Tom Rodriguez wrote: >> >> On Oct 5, 2010, at 4:15 PM, Vladimir Kozlov wrote: >> >>> Tom, >>> >>> It seems, nobody want to spend time to regenerate reorder files >>> for several years already. What we only do is removing lines >>> from these files which produce warnings. May be we should add >>> your script into sources and use it more frequently: >> Yes they are dying a death of a thousand cuts. If I remember correct, removing their use seemed to hurt startup but regenerating them didn't seem to help. I'd rather not put the script in the repo though. >> >> tom >> >>> make/solaris/clear_mapfile_warnings.sh >>> >>> Otherwise looks good. >>> >>> Thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6989736 >>>> 6989736: fix mapfile warnings on solaris >>>> Reviewed-by: >>>> The map files are getting out of date resulting in a bunch of warnings >>>> for product builds so it's time to clean them again. The 64 bit >>>> tiered reorder files have only recently started being used and those >>>> have a lot of entries out of date. I also fixed a minor build issue >>>> where the first build of the adlc didn't run the fix_lines portion of >>>> the adlc_updater which caused the next incremental build to regenerate >>>> some files because the #line directives had changed. Tested by >>>> building each target. I attached the automated script I used for this >>>> to the bug report. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101005/3f19ec00/attachment.html From vladimir.kozlov at oracle.com Wed Oct 6 16:31:13 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 06 Oct 2010 23:31:13 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 20 new changesets Message-ID: <20101006233152.0F9D847F5C@hg.openjdk.java.net> Changeset: 883a82d6d41d Author: acorn Date: 2010-09-10 12:36 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/883a82d6d41d 6942092: Loader-constraint test is failing Summary: Fix test string compare to match source update Reviewed-by: dcubed, phh ! test/runtime/6626217/Test6626217.sh Changeset: 6cde0ed1b568 Author: acorn Date: 2010-09-14 10:15 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6cde0ed1b568 Merge Changeset: 4094f07967ca Author: kamg Date: 2010-09-15 16:28 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4094f07967ca 6974813: JVM needs to use demand loading for its DTrace probes Summary: Pass -xlazyload to the 'dtrace -G' invocation Reviewed-by: phh, ysr ! make/solaris/makefiles/dtrace.make Changeset: 728a287f6c20 Author: zgu Date: 2010-09-17 09:45 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/728a287f6c20 6981753: Rebrand vm vendor property settings Summary: Uses JDK_Version to determinate to set vm vendor to "Oracle Corporation" for JDK7 and later. Reviewed-by: kamg, ohair, coleenp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vm_version.cpp Changeset: 51640ecd89f8 Author: zgu Date: 2010-09-17 09:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/51640ecd89f8 Merge Changeset: 3babdb042f25 Author: kamg Date: 2010-09-17 19:45 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3babdb042f25 Merge Changeset: 60f88489896f Author: kamg Date: 2010-09-20 15:38 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/60f88489896f 6975210: java.lang.VerifyError in some of JCK tests Summary: Naked oop in verificationType::is_reference_assignable_from() Reviewed-by: never, kvn, coleenp ! src/share/vm/classfile/verificationType.cpp Changeset: 2966dab85b3e Author: dcubed Date: 2010-09-21 06:58 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2966dab85b3e 6985848: 3/4 fix for 6561870 causes sa-jdi.jar to be rebuilt every time Summary: Refine fix for 6561870 to only rebuild sa-jdi.jar when needed Reviewed-by: never, ohair, coleenp ! make/linux/makefiles/sa.make ! make/solaris/makefiles/sa.make Changeset: a25394352030 Author: kamg Date: 2010-09-22 12:54 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a25394352030 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 2fe09e2e70d0 Author: cl Date: 2010-09-03 12:49 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2fe09e2e70d0 Added tag jdk7-b108 for changeset e44a93947ccb ! .hgtags Changeset: cc4bb3022b31 Author: cl Date: 2010-09-09 14:27 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cc4bb3022b31 Merge ! .hgtags - src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp Changeset: 2f25f2b8de27 Author: cl Date: 2010-09-09 15:07 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/2f25f2b8de27 Added tag jdk7-b109 for changeset cc4bb3022b31 ! .hgtags Changeset: 07b042e13dde Author: cl Date: 2010-09-16 15:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/07b042e13dde Added tag jdk7-b110 for changeset 2f25f2b8de27 ! .hgtags Changeset: 8d5897b4230f Author: cl Date: 2010-09-23 17:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8d5897b4230f Added tag jdk7-b111 for changeset 07b042e13dde ! .hgtags Changeset: 9bdbd693dbaa Author: trims Date: 2010-09-24 00:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/9bdbd693dbaa Merge Changeset: b2045e0af26e Author: trims Date: 2010-09-24 00:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b2045e0af26e 6987149: Fix incorrect Oracle copyright header in make/templates files Summary: Minor fix to first line of template copyright files Reviewed-by: ohair ! make/templates/bsd-header ! make/templates/gpl-cp-header ! make/templates/gpl-header Changeset: 5511edd5d719 Author: iveresov Date: 2010-09-30 16:00 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5511edd5d719 6988779: c1_LIRAssembler_x86.cpp crashes VS2010 compiler Summary: The workaround changes the scope of the variable Reviewed-by: phh, ysr, kvn ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: beef35b96b81 Author: cl Date: 2010-10-01 15:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/beef35b96b81 Added tag jdk7-b112 for changeset 5511edd5d719 ! .hgtags Changeset: 1c52033222eb Author: trims Date: 2010-10-01 18:04 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1c52033222eb Added tag hs20-b01 for changeset 5511edd5d719 ! .hgtags Changeset: 22e4420d19f7 Author: kvn Date: 2010-10-06 14:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/22e4420d19f7 Merge ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/share/vm/runtime/arguments.cpp From tom.rodriguez at oracle.com Thu Oct 7 11:28:31 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 7 Oct 2010 11:28:31 -0700 Subject: review (S) for 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" Message-ID: <45F0E839-2E01-4B50-A70A-77E7600FD990@oracle.com> http://cr.openjdk.java.net/~never/6980792 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" Reviewed-by: The calls to checkcast_arraycopy were passing ints to functions which expected long in 64 bit so unclean ints would cause failures since the count would appear to be extremely large. I also moved the assert_clean_int test above the check for copies within single array since it was the true source of the problem. The recently added fill code had the same problem. Fixed by adding appropriate conversions. Tested using failing test case from report. From vladimir.kozlov at oracle.com Thu Oct 7 12:03:44 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Oct 2010 12:03:44 -0700 Subject: review (S) for 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" In-Reply-To: <45F0E839-2E01-4B50-A70A-77E7600FD990@oracle.com> References: <45F0E839-2E01-4B50-A70A-77E7600FD990@oracle.com> Message-ID: <4CAE1990.5090202@oracle.com> Tom, could you add comment with array_fill signature for OptoRuntime::array_fill_Type()? Also add comments what first and second arguments are. thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6980792 > > 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" > Reviewed-by: > > The calls to checkcast_arraycopy were passing ints to functions which > expected long in 64 bit so unclean ints would cause failures since > the count would appear to be extremely large. I also moved the > assert_clean_int test above the check for copies within single array > since it was the true source of the problem. The recently added fill > code had the same problem. Fixed by adding appropriate conversions. > Tested using failing test case from report. > From tom.rodriguez at oracle.com Thu Oct 7 12:15:22 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 7 Oct 2010 12:15:22 -0700 Subject: review (S) for 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" In-Reply-To: <4CAE1990.5090202@oracle.com> References: <45F0E839-2E01-4B50-A70A-77E7600FD990@oracle.com> <4CAE1990.5090202@oracle.com> Message-ID: <71242590-15A3-4906-86E1-DAEDC3458DBD@oracle.com> I added this: const TypeFunc* OptoRuntime::array_fill_Type() { // create input type (domain): pointer, int, size_t tom On Oct 7, 2010, at 12:03 PM, Vladimir Kozlov wrote: > Tom, > > could you add comment with array_fill signature for OptoRuntime::array_fill_Type()? > Also add comments what first and second arguments are. > > thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6980792 >> 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" >> Reviewed-by: >> The calls to checkcast_arraycopy were passing ints to functions which >> expected long in 64 bit so unclean ints would cause failures since >> the count would appear to be extremely large. I also moved the >> assert_clean_int test above the check for copies within single array >> since it was the true source of the problem. The recently added fill >> code had the same problem. Fixed by adding appropriate conversions. >> Tested using failing test case from report. From vladimir.kozlov at oracle.com Thu Oct 7 12:17:04 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Oct 2010 12:17:04 -0700 Subject: review (S) for 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" In-Reply-To: <71242590-15A3-4906-86E1-DAEDC3458DBD@oracle.com> References: <45F0E839-2E01-4B50-A70A-77E7600FD990@oracle.com> <4CAE1990.5090202@oracle.com> <71242590-15A3-4906-86E1-DAEDC3458DBD@oracle.com> Message-ID: <4CAE1CB0.7080904@oracle.com> Tom, Looks good. Thanks, Vladimir Tom Rodriguez wrote: > I added this: > > const TypeFunc* OptoRuntime::array_fill_Type() { > // create input type (domain): pointer, int, size_t > > tom > > On Oct 7, 2010, at 12:03 PM, Vladimir Kozlov wrote: > >> Tom, >> >> could you add comment with array_fill signature for OptoRuntime::array_fill_Type()? >> Also add comments what first and second arguments are. >> >> thanks, >> Vladimir >> >> Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/6980792 >>> 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" >>> Reviewed-by: >>> The calls to checkcast_arraycopy were passing ints to functions which >>> expected long in 64 bit so unclean ints would cause failures since >>> the count would appear to be extremely large. I also moved the >>> assert_clean_int test above the check for copies within single array >>> since it was the true source of the problem. The recently added fill >>> code had the same problem. Fixed by adding appropriate conversions. >>> Tested using failing test case from report. > From tom.rodriguez at oracle.com Thu Oct 7 12:28:27 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 7 Oct 2010 12:28:27 -0700 Subject: review (S) for 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" In-Reply-To: <4CAE1CB0.7080904@oracle.com> References: <45F0E839-2E01-4B50-A70A-77E7600FD990@oracle.com> <4CAE1990.5090202@oracle.com> <71242590-15A3-4906-86E1-DAEDC3458DBD@oracle.com> <4CAE1CB0.7080904@oracle.com> Message-ID: <55B5D6C4-2FDF-42E3-A53B-43D92871B58A@oracle.com> Thanks! tom On Oct 7, 2010, at 12:17 PM, Vladimir Kozlov wrote: > Tom, > > Looks good. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> I added this: >> const TypeFunc* OptoRuntime::array_fill_Type() { >> // create input type (domain): pointer, int, size_t >> tom >> On Oct 7, 2010, at 12:03 PM, Vladimir Kozlov wrote: >>> Tom, >>> >>> could you add comment with array_fill signature for OptoRuntime::array_fill_Type()? >>> Also add comments what first and second arguments are. >>> >>> thanks, >>> Vladimir >>> >>> Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/6980792 >>>> 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" >>>> Reviewed-by: >>>> The calls to checkcast_arraycopy were passing ints to functions which >>>> expected long in 64 bit so unclean ints would cause failures since >>>> the count would appear to be extremely large. I also moved the >>>> assert_clean_int test above the check for copies within single array >>>> since it was the true source of the problem. The recently added fill >>>> code had the same problem. Fixed by adding appropriate conversions. >>>> Tested using failing test case from report. From christian.thalinger at oracle.com Thu Oct 7 13:18:08 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 07 Oct 2010 22:18:08 +0200 Subject: Request for reviews (M): 6829194: JSR 292 needs to support compressed oops Message-ID: <1286482688.1871.684.camel@macbook> http://cr.openjdk.java.net/~twisti/6829194/webrev.01/ 6829194: JSR 292 needs to support compressed oops Reviewed-by: There are unimplemented portions of the hotspot code for method handles and invokedynamic specific to UseCompressedOops. They need to be filled in. Extensive testing with JRuby tests. From vladimir.kozlov at oracle.com Thu Oct 7 14:47:51 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Oct 2010 14:47:51 -0700 Subject: Request for reviews (M): 6829194: JSR 292 needs to support compressed oops In-Reply-To: <1286482688.1871.684.camel@macbook> References: <1286482688.1871.684.camel@macbook> Message-ID: <4CAE4007.2040707@oracle.com> Looks good except changes in src/share/vm/classfile/classFileParser.cpp I don't understand why you used DOUBLE in case of compressed oops. NONSTATIC_WORD is corresponds to 4 bytes value regardless 32- or 64-bits. What size of MethodHandle.vmentry in 64bit VM? Thanks, Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6829194/webrev.01/ > > 6829194: JSR 292 needs to support compressed oops > Reviewed-by: > > There are unimplemented portions of the hotspot code for method > handles and invokedynamic specific to UseCompressedOops. They need to > be filled in. > > Extensive testing with JRuby tests. > From john.r.rose at oracle.com Thu Oct 7 15:10:57 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 7 Oct 2010 15:10:57 -0700 Subject: Request for reviews (M): 6829194: JSR 292 needs to support compressed oops In-Reply-To: <4CAE4007.2040707@oracle.com> References: <1286482688.1871.684.camel@macbook> <4CAE4007.2040707@oracle.com> Message-ID: <0C28CCA0-DC03-466B-9180-BED32F644BCC@oracle.com> On Oct 7, 2010, at 2:47 PM, Vladimir Kozlov wrote: > What size of MethodHandle.vmentry in 64bit VM? It's a raw machine word, not compressed. -- John From vladimir.kozlov at oracle.com Thu Oct 7 15:22:57 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 07 Oct 2010 15:22:57 -0700 Subject: Request for reviews (M): 6829194: JSR 292 needs to support compressed oops In-Reply-To: <0C28CCA0-DC03-466B-9180-BED32F644BCC@oracle.com> References: <1286482688.1871.684.camel@macbook> <4CAE4007.2040707@oracle.com> <0C28CCA0-DC03-466B-9180-BED32F644BCC@oracle.com> Message-ID: <4CAE4841.6020609@oracle.com> "word" is not concrete size in computers :) In x86 it could be 2 bytes (16 bits). Is it int (4 bytes) or long (8 bytes) in 64 bit VM (LP64)? I don't understand why its size should depend on UseCompressedOops flag if it is raw. Vladimir John Rose wrote: > On Oct 7, 2010, at 2:47 PM, Vladimir Kozlov wrote: > >> What size of MethodHandle.vmentry in 64bit VM? > > It's a raw machine word, not compressed. > > -- John From john.r.rose at oracle.com Thu Oct 7 15:34:57 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 7 Oct 2010 15:34:57 -0700 Subject: Request for reviews (M): 6829194: JSR 292 needs to support compressed oops In-Reply-To: <4CAE4841.6020609@oracle.com> References: <1286482688.1871.684.camel@macbook> <4CAE4007.2040707@oracle.com> <0C28CCA0-DC03-466B-9180-BED32F644BCC@oracle.com> <4CAE4841.6020609@oracle.com> Message-ID: On Oct 7, 2010, at 3:22 PM, Vladimir Kozlov wrote: > "word" is not concrete size in computers :) In x86 it could be 2 bytes (16 bits). Oops. I meant the size in bytes is wordSize, HeapWordSize, sizeof(intptr_t), sizeof(void*). But the term "WORD" in that code means int32_t. It looks like you spotted a pre-existing bug for LP64. I suggest: + FieldAllocationType new_atype = (wordSize==longSize) ? NONSTATIC_DOUBLE : NONSTATIC_WORD; + assert(wordSize == longSize || wordSize == jintSize, "ILP32 or LP64"); Also the guard on "fac_ptr->nonstatic_double_count += 1" needs to be similar. Christian, the assembler changes look good, and (although I haven't read every line yet) the changes from ld_ptr to load_heap_oop, etc., look good. -- John > I don't understand why its size should depend on UseCompressedOops flag if it is raw. > > Vladimir > > John Rose wrote: >> On Oct 7, 2010, at 2:47 PM, Vladimir Kozlov wrote: >>> What size of MethodHandle.vmentry in 64bit VM? >> It's a raw machine word, not compressed. >> -- John From john.r.rose at oracle.com Thu Oct 7 15:50:09 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 7 Oct 2010 15:50:09 -0700 Subject: Request for reviews (M): 6829194: JSR 292 needs to support compressed oops In-Reply-To: <1286482688.1871.684.camel@macbook> References: <1286482688.1871.684.camel@macbook> Message-ID: <966815C0-3E6B-424A-9A25-5E265E6A1ED0@oracle.com> Looks good. I read all the diffs and spot-checked for missing or erroneous conversions from ptr access to heap_oop access; found no errors. There might be bugs hiding in there, but we'll flush them out, and it is likely that you have already flushed them all out. Did you run MethodHandlesTest? If not you should. It exercises nearly all of those paths. -- John On Oct 7, 2010, at 1:18 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6829194/webrev.01/ > > 6829194: JSR 292 needs to support compressed oops > Reviewed-by: > > There are unimplemented portions of the hotspot code for method > handles and invokedynamic specific to UseCompressedOops. They need to > be filled in. > > Extensive testing with JRuby tests. > From gbenson at redhat.com Thu Oct 7 16:34:47 2010 From: gbenson at redhat.com (Gary Benson) Date: Fri, 8 Oct 2010 00:34:47 +0100 Subject: Review Request: Zero and Shark fixes Message-ID: <20101007233447.GA1215@redhat.com> Hi all, This webrev contains a couple of fixes for Zero and Shark: http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-02/ Firstly, 6978355 renamed a couple of methods in CodeBuffer. Secondly, 6953144 changed the constants used to reference specific compiler tiers. I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From tom.rodriguez at oracle.com Thu Oct 7 23:46:18 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Fri, 08 Oct 2010 06:46:18 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" Message-ID: <20101008064622.B02D147FC1@hg.openjdk.java.net> Changeset: 75588558f1bf Author: never Date: 2010-10-07 21:40 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/75588558f1bf 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" Reviewed-by: kvn ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/runtime.cpp From christian.thalinger at oracle.com Fri Oct 8 00:00:36 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 08 Oct 2010 09:00:36 +0200 Subject: Request for reviews (M): 6829194: JSR 292 needs to support compressed oops In-Reply-To: <966815C0-3E6B-424A-9A25-5E265E6A1ED0@oracle.com> References: <1286482688.1871.684.camel@macbook> <966815C0-3E6B-424A-9A25-5E265E6A1ED0@oracle.com> Message-ID: <1286521236.1871.731.camel@macbook> On Thu, 2010-10-07 at 15:50 -0700, John Rose wrote: > Looks good. I read all the diffs and spot-checked for missing or > erroneous conversions from ptr access to heap_oop access; found no > errors. There might be bugs hiding in there, but we'll flush them > out, and it is likely that you have already flushed them all out. > > Did you run MethodHandlesTest? If not you should. It exercises > nearly all of those paths. Yes I did and it works. I forgot to mention it. -- Christian From christian.thalinger at oracle.com Fri Oct 8 00:58:50 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 08 Oct 2010 09:58:50 +0200 Subject: review (S) for 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" In-Reply-To: <45F0E839-2E01-4B50-A70A-77E7600FD990@oracle.com> References: <45F0E839-2E01-4B50-A70A-77E7600FD990@oracle.com> Message-ID: <1286524730.1871.790.camel@macbook> On Thu, 2010-10-07 at 11:28 -0700, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6980792 > > 6980792: Crash "exception happened outside interpreter, nmethods and vtable stubs (1)" > Reviewed-by: > > The calls to checkcast_arraycopy were passing ints to functions which > expected long in 64 bit so unclean ints would cause failures since > the count would appear to be extremely large. I also moved the > assert_clean_int test above the check for copies within single array > since it was the true source of the problem. The recently added fill > code had the same problem. Fixed by adding appropriate conversions. > Tested using failing test case from report. > Looks good. -- Christian From christian.thalinger at oracle.com Fri Oct 8 02:47:48 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 08 Oct 2010 11:47:48 +0200 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20101007233447.GA1215@redhat.com> References: <20101007233447.GA1215@redhat.com> Message-ID: <1286531268.1871.922.camel@macbook> On Fri, 2010-10-08 at 00:34 +0100, Gary Benson wrote: > Hi all, > > This webrev contains a couple of fixes for Zero and Shark: > > http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-02/ > > Firstly, 6978355 renamed a couple of methods in CodeBuffer. > Secondly, 6953144 changed the constants used to reference > specific compiler tiers. > > I don't have a bug id for this. 6990549: Zero and Shark fixes after 6978355 and 6953144 Changes look good and it's in the queue. -- Christian From Christian.Thalinger at Sun.COM Fri Oct 8 05:53:54 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 08 Oct 2010 12:53:54 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6990549: Zero and Shark fixes after 6978355 and 6953144 Message-ID: <20101008125358.87C2447FD0@hg.openjdk.java.net> Changeset: a222fcfba398 Author: twisti Date: 2010-10-08 02:42 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a222fcfba398 6990549: Zero and Shark fixes after 6978355 and 6953144 Reviewed-by: twisti Contributed-by: Gary Benson ! src/cpu/zero/vm/interpreterRT_zero.hpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/shark/sharkCompiler.hpp From suncg03 at gmail.com Sun Oct 10 10:43:52 2010 From: suncg03 at gmail.com (ChenGuang Sun) Date: Sun, 10 Oct 2010 13:43:52 -0400 Subject: Profiling Scalar Replacement Message-ID: Hi, I'm trying to profile the number of allocations scalarized by escape analysis. I modified PhaseMacroExpand::process_users_of_allocation like follows: ... const TypeFunc *increment_call_type = OptoRuntime::increment_alloc_count_Type(); int size = increment_call_type->domain()->cnt(); CallNode *call = (CallNode*)new (C, increment_call_type->domain()->cnt()) CallLeafNode( increment_call_type, CAST_FROM_FN_PTR(address, SharedRuntime::increment_alloc_count), "increment_alloc_count", TypeRawPtr::BOTTOM); // Set fixed predefined input arguments call->init_req( TypeFunc::Control, alloc->in(TypeFunc::Control) ); call->init_req( TypeFunc::I_O, alloc->in(TypeFunc::I_O) ); // Narrow memory as only memory input call->init_req( TypeFunc::Memory, alloc->in(TypeFunc::Memory)); call->init_req( TypeFunc::FramePtr, top() /* frameptr() */ ); call->init_req( TypeFunc::ReturnAdr, top() ); call->init_req(TypeFunc::Parms+0, transform_later( new (C, 1) ThreadLocalNode() )); call = (CallNode*)transform_later(call); /* if (_fallthroughcatchproj != NULL) { _igvn.replace_node(_fallthroughcatchproj, alloc->in(TypeFunc::Control)); } if (_memproj_fallthrough != NULL) { _igvn.replace_node(_memproj_fallthrough, alloc->in(TypeFunc::Memory)); } */ if (_fallthroughcatchproj != NULL) { _igvn.replace_node(_fallthroughcatchproj, transform_later( new (C, 1) ProjNode(call, TypeFunc::Control) )); } if (_memproj_fallthrough != NULL) { _igvn.replace_node(_memproj_fallthrough, transform_later( new (C, 1) ProjNode(call, TypeFunc::Memory) )); } if (_memproj_catchall != NULL) { _igvn.replace_node(_memproj_catchall, C->top()); } if (_ioproj_fallthrough != NULL) { _igvn.replace_node(_ioproj_fallthrough, transform_later( new (C, 1) ProjNode(call, TypeFunc::I_O) )); } if (_ioproj_catchall != NULL) { _igvn.replace_node(_ioproj_catchall, C->top()); } if (_catchallcatchproj != NULL) { _igvn.replace_node(_catchallcatchproj, C->top()); } But the functions corresponding to the CallLeafNode is never called. Could any one tell me what's wrong with my modification please? Thanks, Chenguang From puzzlesdj at gmail.com Sun Oct 10 20:27:33 2010 From: puzzlesdj at gmail.com (ddmetro) Date: Sun, 10 Oct 2010 20:27:33 -0700 (PDT) Subject: help on starting point of hotspot jvm In-Reply-To: <1286261691.9946.654.camel@macbook> References: <29785128.post@talk.nabble.com> <1285227489.14822.4030.camel@macbook> <29883454.post@talk.nabble.com> <1286261691.9946.654.camel@macbook> Message-ID: <29930900.post@talk.nabble.com> Thanks Christian. 1. I added printf statements in the beginning of the main() function of java.c files in the following locations: /openjdk/hotspot/src/os/linux/launcher/java.c /openjdk/jdk/src/share/bin/java.c /openjdk-ecj/hotspot/src/os/linux/launcher/java.c /openjdk-ecj/jdk/src/share/bin/java.c I then ran >make hotspot >source env.sh >./gamma I expect the printfs to be seen, however they don't appear. Question 1: Do i have to enable verbose output with gamma? Kindly direct me as to what am i missing out in here. Question 2: I am basically trying to figure out which file gets called first, when ./gamma is executed. I think it is /openjdk/hotspot/src/os/linux/launcher/java.c However, I am not able to get the changes (printf statments) reflected after build, when ./gamma is executed. Kindly point out if i am correct on the starting point of ./gamma. Thanking You, Dhiraj Padnani. -- View this message in context: http://old.nabble.com/help-on-starting-point-of-hotspot-jvm-tp29785128p29930900.html Sent from the OpenJDK Hotspot Compiler Development List mailing list archive at Nabble.com. From christian.thalinger at oracle.com Mon Oct 11 02:59:36 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 11 Oct 2010 11:59:36 +0200 Subject: Request for reviews (M): 6829194: JSR 292 needs to support compressed oops In-Reply-To: References: <1286482688.1871.684.camel@macbook> <4CAE4007.2040707@oracle.com> <0C28CCA0-DC03-466B-9180-BED32F644BCC@oracle.com> <4CAE4841.6020609@oracle.com> Message-ID: <4CB2E008.4020006@oracle.com> On 10/08/2010 12:34 AM, John Rose wrote: > On Oct 7, 2010, at 3:22 PM, Vladimir Kozlov wrote: > >> "word" is not concrete size in computers :) In x86 it could be 2 bytes (16 bits). > > Oops. I meant the size in bytes is wordSize, HeapWordSize, sizeof(intptr_t), sizeof(void*). But the term "WORD" in that code means int32_t. It looks like you spotted a pre-existing bug for LP64. I suggest: > > + FieldAllocationType new_atype = (wordSize==longSize) ? NONSTATIC_DOUBLE : NONSTATIC_WORD; > + assert(wordSize == longSize || wordSize == jintSize, "ILP32 or LP64"); > > Also the guard on "fac_ptr->nonstatic_double_count += 1" needs to be similar. > > Christian, the assembler changes look good, and (although I haven't read every line yet) the changes from ld_ptr to load_heap_oop, etc., look good. I added the change above and will push this version: http://cr.openjdk.java.net/~twisti/6829194/webrev.02/ -- Christian From christian.thalinger at oracle.com Mon Oct 11 03:28:37 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 11 Oct 2010 12:28:37 +0200 Subject: help on starting point of hotspot jvm In-Reply-To: <29930900.post@talk.nabble.com> References: <29785128.post@talk.nabble.com> <1285227489.14822.4030.camel@macbook> <29883454.post@talk.nabble.com> <1286261691.9946.654.camel@macbook> <29930900.post@talk.nabble.com> Message-ID: <4CB2E6D5.6090204@oracle.com> On 10/11/2010 05:27 AM, ddmetro wrote: > > Thanks Christian. > > 1. I added printf statements in the beginning of the main() function of > java.c files in the following locations: > /openjdk/hotspot/src/os/linux/launcher/java.c > /openjdk/jdk/src/share/bin/java.c > /openjdk-ecj/hotspot/src/os/linux/launcher/java.c > /openjdk-ecj/jdk/src/share/bin/java.c > > I then ran >make hotspot >> source env.sh >> ./gamma > I expect the printfs to be seen, however they don't appear. Well, it works for me: $ hg di src/os/linux/launcher/java.c diff --git a/src/os/linux/launcher/java.c b/src/os/linux/launcher/java.c --- a/src/os/linux/launcher/java.c +++ b/src/os/linux/launcher/java.c @@ -190,6 +190,7 @@ static int noExitErrorMessage = 0; int main(int argc, char ** argv) { +printf("foo\n"); JavaVM *vm = 0; JNIEnv *env = 0; char *jarfile = 0; $ . env.sh $ ./gamma foo Usage: gamma [-options] class [args...] -- Christian From Christian.Thalinger at Sun.COM Mon Oct 11 06:38:38 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 11 Oct 2010 13:38:38 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6829194: JSR 292 needs to support compressed oops Message-ID: <20101011133844.BF92347070@hg.openjdk.java.net> Changeset: d55217dc206f Author: twisti Date: 2010-10-11 04:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d55217dc206f 6829194: JSR 292 needs to support compressed oops Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/oop.inline.hpp From vladimir.kozlov at oracle.com Mon Oct 11 09:52:27 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Oct 2010 09:52:27 -0700 Subject: Request for reviews (M): 6829194: JSR 292 needs to support compressed oops In-Reply-To: <4CB2E008.4020006@oracle.com> References: <1286482688.1871.684.camel@macbook> <4CAE4007.2040707@oracle.com> <0C28CCA0-DC03-466B-9180-BED32F644BCC@oracle.com> <4CAE4841.6020609@oracle.com> <4CB2E008.4020006@oracle.com> Message-ID: <4CB340CB.9090805@oracle.com> ! if (UseCompressedOops) fac_ptr->nonstatic_double_count += 1; should be ! if (wordSize == longSize) fac_ptr->nonstatic_double_count += 1; Since it is raw it should not depend on coop. Vladimir On 10/11/10 2:59 AM, Christian Thalinger wrote: > On 10/08/2010 12:34 AM, John Rose wrote: >> On Oct 7, 2010, at 3:22 PM, Vladimir Kozlov wrote: >> >>> "word" is not concrete size in computers :) In x86 it could be 2 bytes (16 bits). >> >> Oops. I meant the size in bytes is wordSize, HeapWordSize, sizeof(intptr_t), sizeof(void*). But the term "WORD" in that code means int32_t. It looks like you spotted a pre-existing bug for LP64. I suggest: >> >> + FieldAllocationType new_atype = (wordSize==longSize) ? NONSTATIC_DOUBLE : NONSTATIC_WORD; >> + assert(wordSize == longSize || wordSize == jintSize, "ILP32 or LP64"); >> >> Also the guard on "fac_ptr->nonstatic_double_count += 1" needs to be similar. >> >> Christian, the assembler changes look good, and (although I haven't read every line yet) the changes from ld_ptr to load_heap_oop, etc., look good. > > I added the change above and will push this version: > > http://cr.openjdk.java.net/~twisti/6829194/webrev.02/ > > -- Christian From christian.thalinger at oracle.com Mon Oct 11 10:56:41 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 11 Oct 2010 19:56:41 +0200 Subject: Request for reviews (M): 6829194: JSR 292 needs to support compressed oops In-Reply-To: <4CB340CB.9090805@oracle.com> References: <1286482688.1871.684.camel@macbook> <4CAE4007.2040707@oracle.com> <0C28CCA0-DC03-466B-9180-BED32F644BCC@oracle.com> <4CAE4841.6020609@oracle.com> <4CB2E008.4020006@oracle.com> <4CB340CB.9090805@oracle.com> Message-ID: <4CB34FD9.6030905@oracle.com> On 10/11/10 6:52 PM, Vladimir Kozlov wrote: > ! if (UseCompressedOops) fac_ptr->nonstatic_double_count += 1; > > should be > > ! if (wordSize == longSize) fac_ptr->nonstatic_double_count += 1; > > Since it is raw it should not depend on coop. Damn. I'm a little confused today. Will file a new bug and push that fix. Sorry. -- Christian From vladimir.kozlov at oracle.com Mon Oct 11 11:06:43 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Oct 2010 11:06:43 -0700 Subject: Profiling Scalar Replacement In-Reply-To: References: Message-ID: <4CB35233.9060605@oracle.com> Chenguang, I would suggest to build not product VM (optimized or fastdebug) and run with -XX:+PrintEliminateAllocations flag to see if you are getting scalar replaced objects. Add -Xbatch -XX:+PrintCompilation to see in which method you have replaced objects. Then use -XX:CompileCommand=print,:: to print generated code for the method to see if your call is generated. Note: use CallLeafNoFPNode since you don't have java memory side effects. Vladimir ChenGuang Sun wrote: > Hi, > > I'm trying to profile the number of allocations scalarized by > escape analysis. I modified > PhaseMacroExpand::process_users_of_allocation like follows: > > ... > > const TypeFunc *increment_call_type = > OptoRuntime::increment_alloc_count_Type(); > int size = increment_call_type->domain()->cnt(); > CallNode *call = (CallNode*)new (C, > increment_call_type->domain()->cnt()) CallLeafNode( > increment_call_type, > CAST_FROM_FN_PTR(address, SharedRuntime::increment_alloc_count), > "increment_alloc_count", > TypeRawPtr::BOTTOM); > > // Set fixed predefined input arguments > call->init_req( TypeFunc::Control, alloc->in(TypeFunc::Control) ); > call->init_req( TypeFunc::I_O, alloc->in(TypeFunc::I_O) ); > // Narrow memory as only memory input > call->init_req( TypeFunc::Memory, alloc->in(TypeFunc::Memory)); > call->init_req( TypeFunc::FramePtr, top() /* frameptr() */ ); > call->init_req( TypeFunc::ReturnAdr, top() ); > call->init_req(TypeFunc::Parms+0, transform_later( new (C, 1) > ThreadLocalNode() )); > call = (CallNode*)transform_later(call); > /* > if (_fallthroughcatchproj != NULL) { > _igvn.replace_node(_fallthroughcatchproj, alloc->in(TypeFunc::Control)); > } > if (_memproj_fallthrough != NULL) { > _igvn.replace_node(_memproj_fallthrough, alloc->in(TypeFunc::Memory)); > } > */ > if (_fallthroughcatchproj != NULL) { > _igvn.replace_node(_fallthroughcatchproj, transform_later( new (C, > 1) ProjNode(call, TypeFunc::Control) )); > } > if (_memproj_fallthrough != NULL) { > _igvn.replace_node(_memproj_fallthrough, transform_later( new (C, > 1) ProjNode(call, TypeFunc::Memory) )); > } > if (_memproj_catchall != NULL) { > _igvn.replace_node(_memproj_catchall, C->top()); > } > if (_ioproj_fallthrough != NULL) { > _igvn.replace_node(_ioproj_fallthrough, transform_later( new (C, > 1) ProjNode(call, TypeFunc::I_O) )); > } > if (_ioproj_catchall != NULL) { > _igvn.replace_node(_ioproj_catchall, C->top()); > } > if (_catchallcatchproj != NULL) { > _igvn.replace_node(_catchallcatchproj, C->top()); > } > > > But the functions corresponding to the CallLeafNode is never called. > Could any one tell me what's wrong with my modification please? > > Thanks, > Chenguang From christian.thalinger at oracle.com Mon Oct 11 11:35:16 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 11 Oct 2010 20:35:16 +0200 Subject: Request for reviews (XS): 6991065: missed a review comment in 6829194 Message-ID: <4CB358E4.9020207@oracle.com> http://cr.openjdk.java.net/~twisti/6991065/webrev.01/ 6991065: missed a review comment in 6829194 Reviewed-by: This adds the missed review comment in 6829194 Vladimir pointed out. From vladimir.kozlov at oracle.com Mon Oct 11 11:59:28 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 11 Oct 2010 11:59:28 -0700 Subject: Request for reviews (XS): 6991065: missed a review comment in 6829194 In-Reply-To: <4CB358E4.9020207@oracle.com> References: <4CB358E4.9020207@oracle.com> Message-ID: <4CB35E90.6020000@oracle.com> Looks good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6991065/webrev.01/ > > 6991065: missed a review comment in 6829194 > Reviewed-by: > > This adds the missed review comment in 6829194 Vladimir pointed > out. From gbenson at redhat.com Tue Oct 12 01:14:33 2010 From: gbenson at redhat.com (Gary Benson) Date: Tue, 12 Oct 2010 09:14:33 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <1286531268.1871.922.camel@macbook> References: <20101007233447.GA1215@redhat.com> <1286531268.1871.922.camel@macbook> Message-ID: <20101012081432.GA3471@redhat.com> Christian Thalinger wrote: > On Fri, 2010-10-08 at 00:34 +0100, Gary Benson wrote: > > Hi all, > > > > This webrev contains a couple of fixes for Zero and Shark: > > > > http://cr.openjdk.java.net/~gbenson/zero-shark-fixes-02/ > > > > Firstly, 6978355 renamed a couple of methods in CodeBuffer. > > Secondly, 6953144 changed the constants used to reference > > specific compiler tiers. > > > > I don't have a bug id for this. > > 6990549: Zero and Shark fixes after 6978355 and 6953144 > > Changes look good and it's in the queue. Thanks twisti. Cheers, Gary -- http://gbenson.net/ From roland.westrelin at oracle.com Tue Oct 12 01:51:43 2010 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 12 Oct 2010 10:51:43 +0200 Subject: Request for review (XS): assert failure on C1/sparc following 6972540 fix Message-ID: http://cr.openjdk.java.net/~roland/6991211/webrev.00/ From Christian.Thalinger at Sun.COM Tue Oct 12 04:35:08 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Tue, 12 Oct 2010 11:35:08 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6991065: missed a review comment in 6829194 Message-ID: <20101012113512.988AF470A4@hg.openjdk.java.net> Changeset: a932f331ef90 Author: twisti Date: 2010-10-12 02:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/a932f331ef90 6991065: missed a review comment in 6829194 Reviewed-by: kvn ! src/share/vm/classfile/classFileParser.cpp From christian.thalinger at oracle.com Tue Oct 12 08:49:32 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 12 Oct 2010 17:49:32 +0200 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: <1285868742.1772.336.camel@macbook> References: <1285587786.27094.109.camel@macbook> <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> <1285748294.27094.1762.camel@macbook> <1285768699.27094.2120.camel@macbook> <20727F33-914D-4937-87DB-7FE4C09295D9@oracle.com> <342256CA-214E-4D57-8800-4847EC11908D@oracle.com> <8B2D7285-416B-4590-A7B3-C5EF8AADC66F@oracle.com> <1285868742.1772.336.camel@macbook> Message-ID: <4CB4838C.90805@oracle.com> On 9/30/10 7:45 PM, Christian Thalinger wrote: > On Wed, 2010-09-29 at 09:40 -0700, John Rose wrote: >> On Sep 29, 2010, at 9:22 AM, Tom Rodriguez wrote: >> >>> Why aren't the values dependent on which operation is being performed then? >> >> They certainly can be. That will move the complication out of the >> assembly code. (And into methodHandles.cpp, with a new CPU-specific >> query, plus a new but useful distinction between value conversion and >> unboxing.) I'm fine with doing it either way. > > I will look into that and try to come up with a new patch. http://cr.openjdk.java.net/~twisti/6987555/webrev.02/ That works and seems to be a good patch. It also adds a compiler test. -- Christian From tom.rodriguez at oracle.com Tue Oct 12 09:36:42 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 12 Oct 2010 09:36:42 -0700 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: <4CB4838C.90805@oracle.com> References: <1285587786.27094.109.camel@macbook> <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> <1285748294.27094.1762.camel@macbook> <1285768699.27094.2120.camel@macbook> <20727F33-914D-4937-87DB-7FE4C09295D9@oracle.com> <342256CA-214E-4D57-8800-4847EC11908D@oracle.com> <8B2D7285-416B-4590-A7B3-C5EF8AADC66F@oracle.com> <1285868742.1772.336.camel@macbook> <4CB4838C.90805@oracle.com> Message-ID: <2FBDA1BB-9DA7-4DA4-A989-CB2C925F7248@oracle.com> On Oct 12, 2010, at 8:49 AM, Christian Thalinger wrote: > On 9/30/10 7:45 PM, Christian Thalinger wrote: >> On Wed, 2010-09-29 at 09:40 -0700, John Rose wrote: >>> On Sep 29, 2010, at 9:22 AM, Tom Rodriguez wrote: >>> >>>> Why aren't the values dependent on which operation is being performed then? >>> >>> They certainly can be. That will move the complication out of the >>> assembly code. (And into methodHandles.cpp, with a new CPU-specific >>> query, plus a new but useful distinction between value conversion and >>> unboxing.) I'm fine with doing it either way. >> >> I will look into that and try to come up with a new patch. > > http://cr.openjdk.java.net/~twisti/6987555/webrev.02/ > > That works and seems to be a good patch. It also adds a compiler test. Looks good. For consistency shouldn't methodHandles_x86.cpp use the same values? tom > > -- Christian From christian.thalinger at oracle.com Tue Oct 12 09:41:27 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 12 Oct 2010 18:41:27 +0200 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: <2FBDA1BB-9DA7-4DA4-A989-CB2C925F7248@oracle.com> References: <1285587786.27094.109.camel@macbook> <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> <1285748294.27094.1762.camel@macbook> <1285768699.27094.2120.camel@macbook> <20727F33-914D-4937-87DB-7FE4C09295D9@oracle.com> <342256CA-214E-4D57-8800-4847EC11908D@oracle.com> <8B2D7285-416B-4590-A7B3-C5EF8AADC66F@oracle.com> <1285868742.1772.336.camel@macbook> <4CB4838C.90805@oracle.com> <2FBDA1BB-9DA7-4DA4-A989-CB2C925F7248@oracle.com> Message-ID: <4CB48FB7.4020403@oracle.com> On 10/12/10 6:36 PM, Tom Rodriguez wrote: > > On Oct 12, 2010, at 8:49 AM, Christian Thalinger wrote: > >> On 9/30/10 7:45 PM, Christian Thalinger wrote: >>> On Wed, 2010-09-29 at 09:40 -0700, John Rose wrote: >>>> On Sep 29, 2010, at 9:22 AM, Tom Rodriguez wrote: >>>> >>>>> Why aren't the values dependent on which operation is being performed then? >>>> >>>> They certainly can be. That will move the complication out of the >>>> assembly code. (And into methodHandles.cpp, with a new CPU-specific >>>> query, plus a new but useful distinction between value conversion and >>>> unboxing.) I'm fine with doing it either way. >>> >>> I will look into that and try to come up with a new patch. >> >> http://cr.openjdk.java.net/~twisti/6987555/webrev.02/ >> >> That works and seems to be a good patch. It also adds a compiler test. > > Looks good. For consistency shouldn't methodHandles_x86.cpp use the same values? It does. vminfo is loaded from the method handle object and used to do the shifts. methodHandles_sparc.cpp is actually not changed in this patch, it just contains some of John's cleanups. -- Christian From tom.rodriguez at oracle.com Tue Oct 12 10:01:19 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 12 Oct 2010 10:01:19 -0700 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: <4CB48FB7.4020403@oracle.com> References: <1285587786.27094.109.camel@macbook> <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> <1285748294.27094.1762.camel@macbook> <1285768699.27094.2120.camel@macbook> <20727F33-914D-4937-87DB-7FE4C09295D9@oracle.com> <342256CA-214E-4D57-8800-4847EC11908D@oracle.com> <8B2D7285-416B-4590-A7B3-C5EF8AADC66F@oracle.com> <1285868742.1772.336.camel@macbook> <4CB4838C.90805@oracle.com> <2FBDA1BB-9DA7-4DA4-A989-CB2C925F7248@oracle.com> <4CB48FB7.4020403@oracle.com> Message-ID: On Oct 12, 2010, at 9:41 AM, Christian Thalinger wrote: > On 10/12/10 6:36 PM, Tom Rodriguez wrote: >> >> On Oct 12, 2010, at 8:49 AM, Christian Thalinger wrote: >> >>> On 9/30/10 7:45 PM, Christian Thalinger wrote: >>>> On Wed, 2010-09-29 at 09:40 -0700, John Rose wrote: >>>>> On Sep 29, 2010, at 9:22 AM, Tom Rodriguez wrote: >>>>> >>>>>> Why aren't the values dependent on which operation is being performed then? >>>>> >>>>> They certainly can be. That will move the complication out of the >>>>> assembly code. (And into methodHandles.cpp, with a new CPU-specific >>>>> query, plus a new but useful distinction between value conversion and >>>>> unboxing.) I'm fine with doing it either way. >>>> >>>> I will look into that and try to come up with a new patch. >>> >>> http://cr.openjdk.java.net/~twisti/6987555/webrev.02/ >>> >>> That works and seems to be a good patch. It also adds a compiler test. >> >> Looks good. For consistency shouldn't methodHandles_x86.cpp use the same values? > > It does. vminfo is loaded from the method handle object and used to do the shifts. methodHandles_sparc.cpp is actually not changed in this patch, it just contains some of John's cleanups. Oh, right, I forgot how this works. Looks good. By the way, opt_i2i and opt_i2l are still unimplemented on sparc. Is that on a list some where? tom > > -- Christian From christian.thalinger at oracle.com Tue Oct 12 10:07:03 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 12 Oct 2010 19:07:03 +0200 Subject: Request for reviews (S): 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC In-Reply-To: References: <1285587786.27094.109.camel@macbook> <8CD809B7-7711-4E39-B27D-D61C2B67209F@oracle.com> <1285748294.27094.1762.camel@macbook> <1285768699.27094.2120.camel@macbook> <20727F33-914D-4937-87DB-7FE4C09295D9@oracle.com> <342256CA-214E-4D57-8800-4847EC11908D@oracle.com> <8B2D7285-416B-4590-A7B3-C5EF8AADC66F@oracle.com> <1285868742.1772.336.camel@macbook> <4CB4838C.90805@oracle.com> <2FBDA1BB-9DA7-4DA4-A989-CB2C925F7248@oracle.com> <4CB48FB7.4020403@oracle.com> Message-ID: <4CB495B7.9080403@oracle.com> On 10/12/10 7:01 PM, Tom Rodriguez wrote: > > On Oct 12, 2010, at 9:41 AM, Christian Thalinger wrote: > >> On 10/12/10 6:36 PM, Tom Rodriguez wrote: >>> >>> On Oct 12, 2010, at 8:49 AM, Christian Thalinger wrote: >>> >>>> On 9/30/10 7:45 PM, Christian Thalinger wrote: >>>>> On Wed, 2010-09-29 at 09:40 -0700, John Rose wrote: >>>>>> On Sep 29, 2010, at 9:22 AM, Tom Rodriguez wrote: >>>>>> >>>>>>> Why aren't the values dependent on which operation is being performed then? >>>>>> >>>>>> They certainly can be. That will move the complication out of the >>>>>> assembly code. (And into methodHandles.cpp, with a new CPU-specific >>>>>> query, plus a new but useful distinction between value conversion and >>>>>> unboxing.) I'm fine with doing it either way. >>>>> >>>>> I will look into that and try to come up with a new patch. >>>> >>>> http://cr.openjdk.java.net/~twisti/6987555/webrev.02/ >>>> >>>> That works and seems to be a good patch. It also adds a compiler test. >>> >>> Looks good. For consistency shouldn't methodHandles_x86.cpp use the same values? >> >> It does. vminfo is loaded from the method handle object and used to do the shifts. methodHandles_sparc.cpp is actually not changed in this patch, it just contains some of John's cleanups. > > Oh, right, I forgot how this works. Looks good. > > By the way, opt_i2i and opt_i2l are still unimplemented on sparc. Is that on a list some where? Not really, I just never ran a test that used it. I will try tomorrow to write something and implement it. Thanks for the review! -- Christian From tom.rodriguez at oracle.com Tue Oct 12 10:59:46 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 12 Oct 2010 10:59:46 -0700 Subject: Request for review (XS): assert failure on C1/sparc following 6972540 fix In-Reply-To: References: Message-ID: <546298A4-D103-4FE0-B4F3-99931A39BB8D@oracle.com> Looks good. Thanks for catching this. tom On Oct 12, 2010, at 1:51 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/6991211/webrev.00/ From linuxhippy at gmail.com Tue Oct 12 15:19:58 2010 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Wed, 13 Oct 2010 00:19:58 +0200 Subject: review (S) for 6968348: Byteswapped memory access can point to wrong location after JIT In-Reply-To: <4CA508A0.6010806@gmx.de> References: <4CA499EA.7030103@gmx.de> <4CA508A0.6010806@gmx.de> Message-ID: > Hm, but you are storing in a long[], not a byte[], or do I miss something? > Will have an additional look at it tomorrow. No, he stores to an Unsafe which is always adressed in bytes - the type which backs the Unsafe is irrelevant. - Clemens From igor.veresov at oracle.com Tue Oct 12 17:12:44 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 12 Oct 2010 17:12:44 -0700 Subject: Request for review(S): 6991512: G1 barriers fail with 64bit C1 Message-ID: <4CB4F97C.5090803@oracle.com> This fixes two problems: 1. On x64, c1_LIR.hpp:401, # assert(is_single_cpu() && !is_virtual()) failed: type check Which is due to passing a pointer to T_LONG instead of T_OBJECT to G1 post-barrier when emitting LIR for CompareAndSwap intrinsic. The fix is to create a register with an appropriate type when CASing an object reference. 2. On sparc, assembler_sparc.hpp:843, # assert(nbits == 32 || -(1 << nbits-1) <= x && x < ( 1 << nbits-1)) failed: value out of range This one is due to the limited jump range of branch-on-reg-value instruction. The solution is to use cmp+brx since the jump target is not guaranteed to be in 16 bit range (the target is a continuation of a stub). Webrev: http://cr.openjdk.java.net/~iveresov/6991512/webrev.00/ Tested with a couple of failed nightlies. Thanks, igor From tom.rodriguez at oracle.com Tue Oct 12 17:41:07 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 12 Oct 2010 17:41:07 -0700 Subject: Request for review(S): 6991512: G1 barriers fail with 64bit C1 In-Reply-To: <4CB4F97C.5090803@oracle.com> References: <4CB4F97C.5090803@oracle.com> Message-ID: On Oct 12, 2010, at 5:12 PM, Igor Veresov wrote: > This fixes two problems: > 1. On x64, c1_LIR.hpp:401, > # assert(is_single_cpu() && !is_virtual()) failed: type check > > Which is due to passing a pointer to T_LONG instead of T_OBJECT to G1 post-barrier when emitting LIR for CompareAndSwap intrinsic. The fix is to create a register with an appropriate type when CASing an object reference. Looks good. > > 2. On sparc, assembler_sparc.hpp:843, > # assert(nbits == 32 || -(1 << nbits-1) <= x && x < ( 1 << nbits-1)) failed: value out of range > > This one is due to the limited jump range of branch-on-reg-value instruction. The solution is to use cmp+brx since the jump target is not guaranteed to be in 16 bit range (the target is a continuation of a stub). In this particular case the label should be bound when emit_code is called so you could in fact check the distance and use br_on_reg_cond if it will reach. It seems like it mostly reaches. Using the longer sequence is fine too. tom > > > Webrev: http://cr.openjdk.java.net/~iveresov/6991512/webrev.00/ > > > Tested with a couple of failed nightlies. > > Thanks, > igor > From igor.veresov at oracle.com Tue Oct 12 19:30:45 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 12 Oct 2010 19:30:45 -0700 Subject: Request for review(S): 6991512: G1 barriers fail with 64bit C1 In-Reply-To: References: <4CB4F97C.5090803@oracle.com> Message-ID: <4CB519D5.9040700@oracle.com> On 10/12/10 5:41 PM, Tom Rodriguez wrote: > > On Oct 12, 2010, at 5:12 PM, Igor Veresov wrote: > >> This fixes two problems: >> 1. On x64, c1_LIR.hpp:401, >> # assert(is_single_cpu()&& !is_virtual()) failed: type check >> >> Which is due to passing a pointer to T_LONG instead of T_OBJECT to G1 post-barrier when emitting LIR for CompareAndSwap intrinsic. The fix is to create a register with an appropriate type when CASing an object reference. > > Looks good. > >> >> 2. On sparc, assembler_sparc.hpp:843, >> # assert(nbits == 32 || -(1<< nbits-1)<= x&& x< ( 1<< nbits-1)) failed: value out of range >> >> This one is due to the limited jump range of branch-on-reg-value instruction. The solution is to use cmp+brx since the jump target is not guaranteed to be in 16 bit range (the target is a continuation of a stub). > > In this particular case the label should be bound when emit_code is called so you could in fact check the distance and use br_on_reg_cond if it will reach. It seems like it mostly reaches. Using the longer sequence is fine too. > Yes, it does in most of the cases... Here is the updated webrev: http://cr.openjdk.java.net/~iveresov/6991512/webrev.01/ igor > tom > >> >> >> Webrev: http://cr.openjdk.java.net/~iveresov/6991512/webrev.00/ >> >> >> Tested with a couple of failed nightlies. >> >> Thanks, >> igor >> > From vladimir.kozlov at oracle.com Tue Oct 12 19:51:41 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Oct 2010 19:51:41 -0700 Subject: Request for review(S): 6991512: G1 barriers fail with 64bit C1 In-Reply-To: <4CB519D5.9040700@oracle.com> References: <4CB4F97C.5090803@oracle.com> <4CB519D5.9040700@oracle.com> Message-ID: <4CB51EBD.70801@oracle.com> Why 18 and not 16?: + return is_simm(d, 18); Other changes are good. Vladimir On 10/12/10 7:30 PM, Igor Veresov wrote: > On 10/12/10 5:41 PM, Tom Rodriguez wrote: >> >> On Oct 12, 2010, at 5:12 PM, Igor Veresov wrote: >> >>> This fixes two problems: >>> 1. On x64, c1_LIR.hpp:401, >>> # assert(is_single_cpu()&& !is_virtual()) failed: type check >>> >>> Which is due to passing a pointer to T_LONG instead of T_OBJECT to G1 post-barrier when emitting LIR for >>> CompareAndSwap intrinsic. The fix is to create a register with an appropriate type when CASing an object reference. >> >> Looks good. >> >>> >>> 2. On sparc, assembler_sparc.hpp:843, >>> # assert(nbits == 32 || -(1<< nbits-1)<= x&& x< ( 1<< nbits-1)) failed: value out of range >>> >>> This one is due to the limited jump range of branch-on-reg-value instruction. The solution is to use cmp+brx since >>> the jump target is not guaranteed to be in 16 bit range (the target is a continuation of a stub). >> >> In this particular case the label should be bound when emit_code is called so you could in fact check the distance and >> use br_on_reg_cond if it will reach. It seems like it mostly reaches. Using the longer sequence is fine too. >> > > Yes, it does in most of the cases... > > Here is the updated webrev: > http://cr.openjdk.java.net/~iveresov/6991512/webrev.01/ > > igor > >> tom >> >>> >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/6991512/webrev.00/ >>> >>> >>> Tested with a couple of failed nightlies. >>> >>> Thanks, >>> igor >>> >> > From igor.veresov at oracle.com Tue Oct 12 20:32:33 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 12 Oct 2010 20:32:33 -0700 Subject: Request for review(S): 6991512: G1 barriers fail with 64bit C1 In-Reply-To: <4CB51EBD.70801@oracle.com> References: <4CB4F97C.5090803@oracle.com> <4CB519D5.9040700@oracle.com> <4CB51EBD.70801@oracle.com> Message-ID: <4CB52851.2060008@oracle.com> On 10/12/10 7:51 PM, Vladimir Kozlov wrote: > Why 18 and not 16?: bpr instruction uses an simm16 offset in words. I guess I chose a bad name for the method. I renamed it to is_in_wdisp16_range() to reflect that fact better. Webrev updated in-place. igor > > + return is_simm(d, 18); > > Other changes are good. > > Vladimir > > On 10/12/10 7:30 PM, Igor Veresov wrote: >> On 10/12/10 5:41 PM, Tom Rodriguez wrote: >>> >>> On Oct 12, 2010, at 5:12 PM, Igor Veresov wrote: >>> >>>> This fixes two problems: >>>> 1. On x64, c1_LIR.hpp:401, >>>> # assert(is_single_cpu()&& !is_virtual()) failed: type check >>>> >>>> Which is due to passing a pointer to T_LONG instead of T_OBJECT to >>>> G1 post-barrier when emitting LIR for >>>> CompareAndSwap intrinsic. The fix is to create a register with an >>>> appropriate type when CASing an object reference. >>> >>> Looks good. >>> >>>> >>>> 2. On sparc, assembler_sparc.hpp:843, >>>> # assert(nbits == 32 || -(1<< nbits-1)<= x&& x< ( 1<< nbits-1)) >>>> failed: value out of range >>>> >>>> This one is due to the limited jump range of branch-on-reg-value >>>> instruction. The solution is to use cmp+brx since >>>> the jump target is not guaranteed to be in 16 bit range (the target >>>> is a continuation of a stub). >>> >>> In this particular case the label should be bound when emit_code is >>> called so you could in fact check the distance and >>> use br_on_reg_cond if it will reach. It seems like it mostly reaches. >>> Using the longer sequence is fine too. >>> >> >> Yes, it does in most of the cases... >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~iveresov/6991512/webrev.01/ >> >> igor >> >>> tom >>> >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/6991512/webrev.00/ >>>> >>>> >>>> Tested with a couple of failed nightlies. >>>> >>>> Thanks, >>>> igor >>>> >>> >> From vladimir.kozlov at oracle.com Tue Oct 12 21:25:50 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Oct 2010 21:25:50 -0700 Subject: Request for review(S): 6991512: G1 barriers fail with 64bit C1 In-Reply-To: <4CB52851.2060008@oracle.com> References: <4CB4F97C.5090803@oracle.com> <4CB519D5.9040700@oracle.com> <4CB51EBD.70801@oracle.com> <4CB52851.2060008@oracle.com> Message-ID: <4CB534CE.2060808@oracle.com> Got it. Looks good. Thanks, Vladimir On 10/12/10 8:32 PM, Igor Veresov wrote: > On 10/12/10 7:51 PM, Vladimir Kozlov wrote: >> Why 18 and not 16?: > > bpr instruction uses an simm16 offset in words. I guess I chose a bad name for the method. I renamed it to > is_in_wdisp16_range() to reflect that fact better. Webrev updated in-place. > > igor > >> >> + return is_simm(d, 18); >> >> Other changes are good. >> >> Vladimir >> >> On 10/12/10 7:30 PM, Igor Veresov wrote: >>> On 10/12/10 5:41 PM, Tom Rodriguez wrote: >>>> >>>> On Oct 12, 2010, at 5:12 PM, Igor Veresov wrote: >>>> >>>>> This fixes two problems: >>>>> 1. On x64, c1_LIR.hpp:401, >>>>> # assert(is_single_cpu()&& !is_virtual()) failed: type check >>>>> >>>>> Which is due to passing a pointer to T_LONG instead of T_OBJECT to >>>>> G1 post-barrier when emitting LIR for >>>>> CompareAndSwap intrinsic. The fix is to create a register with an >>>>> appropriate type when CASing an object reference. >>>> >>>> Looks good. >>>> >>>>> >>>>> 2. On sparc, assembler_sparc.hpp:843, >>>>> # assert(nbits == 32 || -(1<< nbits-1)<= x&& x< ( 1<< nbits-1)) >>>>> failed: value out of range >>>>> >>>>> This one is due to the limited jump range of branch-on-reg-value >>>>> instruction. The solution is to use cmp+brx since >>>>> the jump target is not guaranteed to be in 16 bit range (the target >>>>> is a continuation of a stub). >>>> >>>> In this particular case the label should be bound when emit_code is >>>> called so you could in fact check the distance and >>>> use br_on_reg_cond if it will reach. It seems like it mostly reaches. >>>> Using the longer sequence is fine too. >>>> >>> >>> Yes, it does in most of the cases... >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~iveresov/6991512/webrev.01/ >>> >>> igor >>> >>>> tom >>>> >>>>> >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/6991512/webrev.00/ >>>>> >>>>> >>>>> Tested with a couple of failed nightlies. >>>>> >>>>> Thanks, >>>>> igor >>>>> >>>> >>> > From igor.veresov at oracle.com Tue Oct 12 21:48:04 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 12 Oct 2010 21:48:04 -0700 Subject: Request for review(S): 6991512: G1 barriers fail with 64bit C1 In-Reply-To: <4CB534CE.2060808@oracle.com> References: <4CB4F97C.5090803@oracle.com> <4CB519D5.9040700@oracle.com> <4CB51EBD.70801@oracle.com> <4CB52851.2060008@oracle.com> <4CB534CE.2060808@oracle.com> Message-ID: <4CB53A04.9010605@oracle.com> Thanks, Vladimir and Tom! igor On 10/12/10 9:25 PM, Vladimir Kozlov wrote: > Got it. Looks good. > > Thanks, > Vladimir > > On 10/12/10 8:32 PM, Igor Veresov wrote: >> On 10/12/10 7:51 PM, Vladimir Kozlov wrote: >>> Why 18 and not 16?: >> >> bpr instruction uses an simm16 offset in words. I guess I chose a bad >> name for the method. I renamed it to >> is_in_wdisp16_range() to reflect that fact better. Webrev updated >> in-place. >> >> igor >> >>> >>> + return is_simm(d, 18); >>> >>> Other changes are good. >>> >>> Vladimir >>> >>> On 10/12/10 7:30 PM, Igor Veresov wrote: >>>> On 10/12/10 5:41 PM, Tom Rodriguez wrote: >>>>> >>>>> On Oct 12, 2010, at 5:12 PM, Igor Veresov wrote: >>>>> >>>>>> This fixes two problems: >>>>>> 1. On x64, c1_LIR.hpp:401, >>>>>> # assert(is_single_cpu()&& !is_virtual()) failed: type check >>>>>> >>>>>> Which is due to passing a pointer to T_LONG instead of T_OBJECT to >>>>>> G1 post-barrier when emitting LIR for >>>>>> CompareAndSwap intrinsic. The fix is to create a register with an >>>>>> appropriate type when CASing an object reference. >>>>> >>>>> Looks good. >>>>> >>>>>> >>>>>> 2. On sparc, assembler_sparc.hpp:843, >>>>>> # assert(nbits == 32 || -(1<< nbits-1)<= x&& x< ( 1<< nbits-1)) >>>>>> failed: value out of range >>>>>> >>>>>> This one is due to the limited jump range of branch-on-reg-value >>>>>> instruction. The solution is to use cmp+brx since >>>>>> the jump target is not guaranteed to be in 16 bit range (the target >>>>>> is a continuation of a stub). >>>>> >>>>> In this particular case the label should be bound when emit_code is >>>>> called so you could in fact check the distance and >>>>> use br_on_reg_cond if it will reach. It seems like it mostly reaches. >>>>> Using the longer sequence is fine too. >>>>> >>>> >>>> Yes, it does in most of the cases... >>>> >>>> Here is the updated webrev: >>>> http://cr.openjdk.java.net/~iveresov/6991512/webrev.01/ >>>> >>>> igor >>>> >>>>> tom >>>>> >>>>>> >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/6991512/webrev.00/ >>>>>> >>>>>> >>>>>> Tested with a couple of failed nightlies. >>>>>> >>>>>> Thanks, >>>>>> igor >>>>>> >>>>> >>>> >> From christian.thalinger at oracle.com Wed Oct 13 11:42:11 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 13 Oct 2010 20:42:11 +0200 Subject: Request for reviews (S): 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC Message-ID: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> http://cr.openjdk.java.net/~twisti/6991596/webrev.01/ 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC Reviewed-by: On SPARC adapter_opt_i2i and adapter_opt_l2i are still unimplemented. This needs to be filled in. This change also adds a testcase that tests as much conversions as currently possible (there are some bugs in the current RI). From igor.veresov at oracle.com Wed Oct 13 13:29:22 2010 From: igor.veresov at oracle.com (igor.veresov at oracle.com) Date: Wed, 13 Oct 2010 20:29:22 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6991512: G1 barriers fail with 64bit C1 Message-ID: <20101013202926.F177447104@hg.openjdk.java.net> Changeset: c393f046f4c5 Author: iveresov Date: 2010-10-12 23:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c393f046f4c5 6991512: G1 barriers fail with 64bit C1 Summary: Fix compare-and-swap intrinsic problem with G1 post-barriers and issue with branch ranges in G1 stubs on sparc Reviewed-by: never, kvn ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_CodeStubs_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_LIRGenerator.cpp From vladimir.kozlov at oracle.com Wed Oct 13 15:08:34 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Oct 2010 15:08:34 -0700 Subject: Request for reviews (S): 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC In-Reply-To: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> References: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> Message-ID: <4CB62DE2.3080304@oracle.com> Looks good. Vladimir Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6991596/webrev.01/ > > 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC > Reviewed-by: > > On SPARC adapter_opt_i2i and adapter_opt_l2i are still unimplemented. > This needs to be filled in. > > This change also adds a testcase that tests as much conversions as > currently possible (there are some bugs in the current RI). From Christian.Thalinger at Sun.COM Wed Oct 13 15:35:59 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 13 Oct 2010 22:35:59 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20101013223602.D44DC47109@hg.openjdk.java.net> Changeset: 5beba6174298 Author: twisti Date: 2010-10-13 01:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/5beba6174298 6987555: JSR 292 unboxing to a boolean value fails on big-endian SPARC Reviewed-by: never, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp + test/compiler/6987555/Test6987555.java Changeset: ecca2e3e2767 Author: twisti Date: 2010-10-13 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ecca2e3e2767 Merge From john.r.rose at oracle.com Wed Oct 13 16:32:25 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 13 Oct 2010 16:32:25 -0700 Subject: Request for reviews (S): 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC In-Reply-To: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> References: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> Message-ID: On Oct 13, 2010, at 11:42 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6991596/webrev.01/ > > 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC > Reviewed-by: > > On SPARC adapter_opt_i2i and adapter_opt_l2i are still unimplemented. > This needs to be filled in. Good. > This change also adds a testcase that tests as much conversions as > currently possible (there are some bugs in the current RI). That's a very nice test case! I believe the newer version of javac support for method handles has been released. If so, compiling the test case will cause warnings, and those warnings will turn to errors as JSR 292 finalizes. Please try the new syntax: - boolean a = mh1.invokeExact((boolean) x); - boolean a = (boolean) mh1.invokeExact((boolean) x); Suggestion: To make the overall structure of the test code easier to read, factor the long initializers for mh1 and mh2 into suitably parameterized subroutines. -- John From roland.westrelin at oracle.com Wed Oct 13 17:42:50 2010 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Thu, 14 Oct 2010 00:42:50 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20101014004256.4907747115@hg.openjdk.java.net> Changeset: 357451a9ae6a Author: roland Date: 2010-10-13 10:29 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/357451a9ae6a 6991211: assert failure on sparc: "can not have caller-save register operands at calls" Summary: fixes sparc only assert failure following 6972540 Reviewed-by: never ! src/cpu/sparc/vm/c1_LinearScan_sparc.hpp Changeset: 94d77a279225 Author: roland Date: 2010-10-13 15:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/94d77a279225 Merge From roland.westrelin at oracle.com Thu Oct 14 00:45:38 2010 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 14 Oct 2010 09:45:38 +0200 Subject: Request for Review(S): Ifop optimization for c1 Message-ID: http://cr.openjdk.java.net/~roland/6991577/webrev.00/ From forax at univ-mlv.fr Thu Oct 14 01:24:09 2010 From: forax at univ-mlv.fr (=?ISO-8859-15?Q?R=E9mi_Forax?=) Date: Thu, 14 Oct 2010 10:24:09 +0200 Subject: Request for Review(S): Ifop optimization for c1 In-Reply-To: References: Message-ID: <4CB6BE29.3090502@univ-mlv.fr> Le 14/10/2010 09:45, Roland Westrelin a ?crit : > http://cr.openjdk.java.net/~roland/6991577/webrev.00/ A minor comment from an amateur. In c1_Optimizer.cpp, in CE_Eliminator::make_ifop: Constant* x_const = x->as_Constant(); should be computed only in the else branch and not before if (x_ifop != NULL) R?mi From christian.thalinger at oracle.com Thu Oct 14 01:43:45 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 14 Oct 2010 10:43:45 +0200 Subject: Request for reviews (S): 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC In-Reply-To: References: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> Message-ID: On Oct 14, 2010, at 1:32 AM, John Rose wrote: >> This change also adds a testcase that tests as much conversions as >> currently possible (there are some bugs in the current RI). > > > That's a very nice test case! > > I believe the newer version of javac support for method handles has > been released. If so, compiling the test case will cause warnings, > and those warnings will turn to errors as JSR 292 finalizes. Please > try the new syntax: > > - boolean a = mh1.invokeExact((boolean) x); > - boolean a = (boolean) mh1.invokeExact((boolean) x); I know and I also tried that but it seems there is a bug somewhere: Exception in thread "main" java.dyn.WrongMethodTypeException: (Z)Z cannot be called as (Z)Ljava/lang/Object; > > Suggestion: To make the overall structure of the test code easier > to read, factor the long initializers for mh1 and mh2 into suitably > parameterized subroutines. Good idea. -- Christian From forax at univ-mlv.fr Thu Oct 14 02:00:25 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 14 Oct 2010 11:00:25 +0200 Subject: Request for reviews (S): 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC In-Reply-To: References: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> Message-ID: <4CB6C6A9.4010405@univ-mlv.fr> Le 14/10/2010 10:43, Christian Thalinger a ?crit : > On Oct 14, 2010, at 1:32 AM, John Rose wrote: >>> This change also adds a testcase that tests as much conversions as >>> currently possible (there are some bugs in the current RI). >> >> >> That's a very nice test case! >> >> I believe the newer version of javac support for method handles has >> been released. If so, compiling the test case will cause warnings, >> and those warnings will turn to errors as JSR 292 finalizes. Please >> try the new syntax: >> >> - boolean a = mh1.invokeExact((boolean) x); >> - boolean a = (boolean) mh1.invokeExact((boolean) x); > > I know and I also tried that but it seems there is a bug somewhere: > > Exception in thread "main" java.dyn.WrongMethodTypeException: (Z)Z > cannot be called as (Z)Ljava/lang/Object; Your javac just doesn't understand the new syntax. > >> >> Suggestion: To make the overall structure of the test code easier to >> read, factor the long initializers for mh1 and mh2 into suitably >> parameterized subroutines. > > > Good idea. > > -- Christian R?mi From christian.thalinger at oracle.com Thu Oct 14 02:15:25 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 14 Oct 2010 11:15:25 +0200 Subject: Request for reviews (S): 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC In-Reply-To: <4CB6C6A9.4010405@univ-mlv.fr> References: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> <4CB6C6A9.4010405@univ-mlv.fr> Message-ID: <1813E161-D436-45FE-943B-B963D76EADFD@oracle.com> On Oct 14, 2010, at 11:00 AM, R?mi Forax wrote: > Le 14/10/2010 10:43, Christian Thalinger a ?crit : >> On Oct 14, 2010, at 1:32 AM, John Rose wrote: >>>> This change also adds a testcase that tests as much conversions as >>>> currently possible (there are some bugs in the current RI). >>> >>> >>> That's a very nice test case! >>> >>> I believe the newer version of javac support for method handles >>> has been released. If so, compiling the test case will cause >>> warnings, and those warnings will turn to errors as JSR 292 >>> finalizes. Please try the new syntax: >>> >>> - boolean a = mh1.invokeExact((boolean) x); >>> - boolean a = (boolean) mh1.invokeExact((boolean) x); >> >> I know and I also tried that but it seems there is a bug somewhere: >> >> Exception in thread "main" java.dyn.WrongMethodTypeException: (Z)Z >> cannot be called as (Z)Ljava/lang/Object; > > Your javac just doesn't understand the new syntax. Well, then the new javac isn't in b113. -- Christian From roland.westrelin at oracle.com Thu Oct 14 04:30:03 2010 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 14 Oct 2010 13:30:03 +0200 Subject: Request for Review(S): Ifop optimization for c1 In-Reply-To: <4CB6BE29.3090502@univ-mlv.fr> References: <4CB6BE29.3090502@univ-mlv.fr> Message-ID: Hi R?mi, > A minor comment from an amateur. > In c1_Optimizer.cpp, in CE_Eliminator::make_ifop: > > Constant* x_const = x->as_Constant(); > > should be computed only in the else branch and not before > > if (x_ifop != NULL) Thanks for the comment. I've updated the webrev: http://cr.openjdk.java.net/~roland/6991577/webrev.01/ Roland. From tom.rodriguez at oracle.com Thu Oct 14 09:35:06 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 14 Oct 2010 09:35:06 -0700 Subject: Request for Review(S): Ifop optimization for c1 In-Reply-To: References: <4CB6BE29.3090502@univ-mlv.fr> Message-ID: <9BD7CCE7-FB03-4255-957D-0B2CD7303D28@oracle.com> Looks good. tom On Oct 14, 2010, at 4:30 AM, Roland Westrelin wrote: > > Hi R?mi, > >> A minor comment from an amateur. >> In c1_Optimizer.cpp, in CE_Eliminator::make_ifop: >> >> Constant* x_const = x->as_Constant(); >> >> should be computed only in the else branch and not before >> >> if (x_ifop != NULL) > > Thanks for the comment. I've updated the webrev: > http://cr.openjdk.java.net/~roland/6991577/webrev.01/ > > Roland. From john.r.rose at oracle.com Thu Oct 14 09:53:33 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 14 Oct 2010 09:53:33 -0700 Subject: Request for reviews (S): 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC In-Reply-To: <1813E161-D436-45FE-943B-B963D76EADFD@oracle.com> References: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> <4CB6C6A9.4010405@univ-mlv.fr> <1813E161-D436-45FE-943B-B963D76EADFD@oracle.com> Message-ID: On Oct 14, 2010, at 2:15 AM, Christian Thalinger wrote: > On Oct 14, 2010, at 11:00 AM, R?mi Forax wrote: >> Le 14/10/2010 10:43, Christian Thalinger a ?crit : >>> On Oct 14, 2010, at 1:32 AM, John Rose wrote: >>>>> This change also adds a testcase that tests as much conversions as >>>>> currently possible (there are some bugs in the current RI). >>>> >>>> >>>> That's a very nice test case! >>>> >>>> I believe the newer version of javac support for method handles has been released. If so, compiling the test case will cause warnings, and those warnings will turn to errors as JSR 292 finalizes. Please try the new syntax: >>>> >>>> - boolean a = mh1.invokeExact((boolean) x); >>>> - boolean a = (boolean) mh1.invokeExact((boolean) x); >>> >>> I know and I also tried that but it seems there is a bug somewhere: >>> >>> Exception in thread "main" java.dyn.WrongMethodTypeException: (Z)Z cannot be called as (Z)Ljava/lang/Object; >> >> Your javac just doesn't understand the new syntax. > > Well, then the new javac isn't in b113. -- Christian Indeed, I thought it would be. But it's broken. :-( The new syntax almost works, but the cast type is dropped and the return type stays as the default, Object. This is because bug 6979327 had a bad fix, introduced somehow just before integration. The re-fix will be bug 6991980. Sorry, folks. -- John From igor.veresov at oracle.com Thu Oct 14 10:22:39 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 14 Oct 2010 10:22:39 -0700 Subject: Request for Review(S): Ifop optimization for c1 In-Reply-To: References: Message-ID: <4CB73C5F.1090204@oracle.com> Looks good. igor On 10/14/10 12:45 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/6991577/webrev.00/ From christian.thalinger at oracle.com Thu Oct 14 11:02:19 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 14 Oct 2010 20:02:19 +0200 Subject: Request for reviews (S): 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC In-Reply-To: References: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> <4CB6C6A9.4010405@univ-mlv.fr> <1813E161-D436-45FE-943B-B963D76EADFD@oracle.com> Message-ID: <7B65EB7E-ACD8-4AF3-B662-C8DA5B6E1258@oracle.com> On Oct 14, 2010, at 6:53 PM, John Rose wrote: > On Oct 14, 2010, at 2:15 AM, Christian Thalinger wrote: > >> On Oct 14, 2010, at 11:00 AM, R?mi Forax wrote: >>> Le 14/10/2010 10:43, Christian Thalinger a ?crit : >>>> On Oct 14, 2010, at 1:32 AM, John Rose wrote: >>>>>> This change also adds a testcase that tests as much conversions >>>>>> as >>>>>> currently possible (there are some bugs in the current RI). >>>>> >>>>> >>>>> That's a very nice test case! >>>>> >>>>> I believe the newer version of javac support for method handles >>>>> has been released. If so, compiling the test case will cause >>>>> warnings, and those warnings will turn to errors as JSR 292 >>>>> finalizes. Please try the new syntax: >>>>> >>>>> - boolean a = mh1.invokeExact((boolean) x); >>>>> - boolean a = (boolean) mh1.invokeExact((boolean) x); >>>> >>>> I know and I also tried that but it seems there is a bug somewhere: >>>> >>>> Exception in thread "main" java.dyn.WrongMethodTypeException: >>>> (Z)Z cannot be called as (Z)Ljava/lang/Object; >>> >>> Your javac just doesn't understand the new syntax. >> >> Well, then the new javac isn't in b113. -- Christian > > Indeed, I thought it would be. But it's broken. :-( The new > syntax almost works, but the cast type is dropped and the return > type stays as the default, Object. > > This is because bug 6979327 had a bad fix, introduced somehow just > before integration. The re-fix will be bug 6991980. Sorry, folks. When will the fix be available? Should I wait for 6991980 before I push my changes or should I fix the test later? -- Christian From john.r.rose at oracle.com Thu Oct 14 11:13:48 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 14 Oct 2010 11:13:48 -0700 Subject: Request for reviews (S): 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC In-Reply-To: <7B65EB7E-ACD8-4AF3-B662-C8DA5B6E1258@oracle.com> References: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> <4CB6C6A9.4010405@univ-mlv.fr> <1813E161-D436-45FE-943B-B963D76EADFD@oracle.com> <7B65EB7E-ACD8-4AF3-B662-C8DA5B6E1258@oracle.com> Message-ID: <7CEC52CE-BD5F-48A7-8CC8-217FDEC01598@oracle.com> On Oct 14, 2010, at 11:02 AM, Christian Thalinger wrote: > When will the fix be available? Should I wait for 6991980 before I push my changes or should I fix the test later? Go ahead and push. We'll fix the tests when we transform the other source code. -- John From christian.thalinger at oracle.com Fri Oct 15 02:48:47 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 15 Oct 2010 11:48:47 +0200 Subject: Request for reviews (S): 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC In-Reply-To: <7CEC52CE-BD5F-48A7-8CC8-217FDEC01598@oracle.com> References: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> <4CB6C6A9.4010405@univ-mlv.fr> <1813E161-D436-45FE-943B-B963D76EADFD@oracle.com> <7B65EB7E-ACD8-4AF3-B662-C8DA5B6E1258@oracle.com> <7CEC52CE-BD5F-48A7-8CC8-217FDEC01598@oracle.com> Message-ID: <5B26B937-1608-4137-9B4A-C38134C24D36@oracle.com> On Oct 14, 2010, at 8:13 PM, John Rose wrote: > On Oct 14, 2010, at 11:02 AM, Christian Thalinger wrote: > >> When will the fix be available? Should I wait for 6991980 before I >> push my changes or should I fix the test later? > > Go ahead and push. We'll fix the tests when we transform the other > source code. -- John Alright. I also did a small change in the test/Makefile to use ALT_OUTPUTDIR when it's set. That speeds up running tests when the source repository is on a NFS drive. Can I get at least one review of that? http://cr.openjdk.java.net/~twisti/6991596/webrev.02/ -- Christian From vladimir.kozlov at oracle.com Fri Oct 15 02:56:48 2010 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Fri, 15 Oct 2010 09:56:48 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 12 new changesets Message-ID: <20101015095711.B4D1747184@hg.openjdk.java.net> Changeset: 8b10f48633dc Author: jmasa Date: 2010-09-20 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8b10f48633dc 6984287: Regularize how GC parallel workers are specified. Summary: Associate number of GC workers with the workgang as opposed to the task. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/parNew/parCardTableModRefBS.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/workgroup.cpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.cpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 22cace5e30b5 Author: jcoomes Date: 2010-09-08 16:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/22cace5e30b5 6983296: build sanity checks for jdk7 should require SS12u1 Reviewed-by: ohair ! make/solaris/makefiles/sparcWorks.make Changeset: 4805b9f4779e Author: johnc Date: 2010-09-28 09:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4805b9f4779e 6941395: G1: Use only lock-free versions of region stack push() and pop() Summary: Re-enable use of the lock-free versions of region stack push() and pop() by recording aborted regions in a thread-local structure, which are then processed when scanning of the region stack restarts. The previous locking versions of these routines are retained for diagnostic purposes. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp Changeset: 894b1d7c7e01 Author: jcoomes Date: 2010-09-28 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/894b1d7c7e01 6423256: GC stacks should use a better data structure 6942771: SEGV in ParScanThreadState::take_from_overflow_stack Reviewed-by: apetrusenko, ysr, pbk ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_serial ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + src/share/vm/utilities/stack.hpp + src/share/vm/utilities/stack.inline.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: c99c53f07c14 Author: ysr Date: 2010-09-29 16:17 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c99c53f07c14 6692906: CMS: parallel concurrent marking may be prone to hanging or stalling mutators for periods of time Summary: Inserted missing yield(check)s in closures used during the work-stealing phase of parallel concurrent marking, a missing synchronous yield-request in the cms perm gen allocation path, and a terminator-terminator for the offer_termination invocation that monitors the yield status of the concurrent marking task. Elaborated some documentation comments and made some task queue termination loop flags configurable at start-up to aid debugging in the field. Reviewed-by: jmasa, johnc, poonam ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: 8f6f7587d292 Author: jcoomes Date: 2010-09-30 12:15 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8f6f7587d292 6988678: fatal error deadlock handling was unintentionally disabled Reviewed-by: ysr ! src/share/vm/runtime/thread.cpp Changeset: e41cd7fd68a6 Author: ysr Date: 2010-10-01 16:12 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e41cd7fd68a6 6794422: Perm gen expansion policy for concurrent collectors Summary: Concurrent collectors should expand the perm gen without a full STW GC, but possibly by triggering a concurrent collection. Temporary band-aid for G1 where no concurrent collection is kicked off since the perm gen is not collected concurrently. Reviewed-by: johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp ! src/share/vm/includeDB_core ! src/share/vm/memory/permGen.cpp ! src/share/vm/memory/permGen.hpp Changeset: 4e0094bc41fa Author: johnc Date: 2010-10-01 18:23 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4e0094bc41fa 6983311: G1: LoopTest hangs when run with -XX:+ExplicitInvokesConcurrent Summary: Clear the concurrent marking "in progress" flag while the FullGCCount_lock is held. This avoids a race that can cause back to back System.gc() calls, when ExplicitGCInvokesConcurrent is enabled, to fail to initiate a marking cycle causing the requesting thread to hang. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 32a1f7bf0c21 Author: johnc Date: 2010-10-01 21:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/32a1f7bf0c21 Merge Changeset: 6e0aac35bfa9 Author: tonyp Date: 2010-10-01 16:43 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6e0aac35bfa9 6980838: G1: guarantee(false) failed: thread has an unexpected active value in its SATB queue Summary: Under certain circumstances a safepoint could happen between a JavaThread object being created and that object being added to the Java threads list. This could cause the active field of that thread's SATB queue to get out-of-sync with respect to the other Java threads. The solution is to activate the SATB queue, when necessary, before adding the thread to the Java threads list, not when the JavaThread object is created. The changeset also includes a small fix to rename the surrogate locker thread from "Surrogate Locker Thread (CMS)" to "Surrogate Locker Thread (Concurrent GC)" since it's also used in G1. Reviewed-by: iveresov, ysr, johnc, jcoomes ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 0715f0cf171d Author: jcoomes Date: 2010-10-08 09:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0715f0cf171d Merge ! src/share/vm/includeDB_core ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: b98784e85f71 Author: kvn Date: 2010-10-14 10:46 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b98784e85f71 Merge From roland.westrelin at oracle.com Fri Oct 15 05:06:06 2010 From: roland.westrelin at oracle.com (roland.westrelin at oracle.com) Date: Fri, 15 Oct 2010 12:06:06 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20101015120610.157A84718A@hg.openjdk.java.net> Changeset: 42a10fc37986 Author: roland Date: 2010-10-15 09:38 +0200 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/42a10fc37986 6991577: add IfOp optimization to C1 Summary: Ifop optimization for c1 Reviewed-by: never, phh, iveresov ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_globals.hpp Changeset: e5c3d73017ab Author: roland Date: 2010-10-15 02:59 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e5c3d73017ab Merge From Dmitriy.Samersoff at oracle.com Fri Oct 15 06:17:37 2010 From: Dmitriy.Samersoff at oracle.com (Dmitriy Samersoff) Date: Fri, 15 Oct 2010 17:17:37 +0400 Subject: Request for reviews (S): 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC In-Reply-To: <5B26B937-1608-4137-9B4A-C38134C24D36@oracle.com> References: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> <4CB6C6A9.4010405@univ-mlv.fr> <1813E161-D436-45FE-943B-B963D76EADFD@oracle.com> <7B65EB7E-ACD8-4AF3-B662-C8DA5B6E1258@oracle.com> <7CEC52CE-BD5F-48A7-8CC8-217FDEC01598@oracle.com> <5B26B937-1608-4137-9B4A-C38134C24D36@oracle.com> Message-ID: <4CB85471.5020104@oracle.com> Christian, On 2010-10-15 13:48, Christian Thalinger wrote: > Alright. I also did a small change in the test/Makefile to use > ALT_OUTPUTDIR when it's set. That speeds up running tests when the > source repository is on a NFS drive. Can I get at least one review of that? > > http://cr.openjdk.java.net/~twisti/6991596/webrev.02/ Besides the fact that it shouldn't be in the same changeset - looks good for me. -- Dmitry Samersoff J2SE Sustaining team, SPB04 * Give Rabbit time and he'll always get the answer ... From christian.thalinger at oracle.com Fri Oct 15 08:37:28 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 15 Oct 2010 17:37:28 +0200 Subject: Request for reviews (S): 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC In-Reply-To: <4CB85471.5020104@oracle.com> References: <9CBE85A6-922A-4844-843F-0493AB73EE03@oracle.com> <4CB6C6A9.4010405@univ-mlv.fr> <1813E161-D436-45FE-943B-B963D76EADFD@oracle.com> <7B65EB7E-ACD8-4AF3-B662-C8DA5B6E1258@oracle.com> <7CEC52CE-BD5F-48A7-8CC8-217FDEC01598@oracle.com> <5B26B937-1608-4137-9B4A-C38134C24D36@oracle.com> <4CB85471.5020104@oracle.com> Message-ID: <94B2DA81-F447-4A7B-9EA3-824EEAD2D82A@oracle.com> On Oct 15, 2010, at 3:17 PM, Dmitriy Samersoff wrote: > Christian, > > On 2010-10-15 13:48, Christian Thalinger wrote: >> Alright. I also did a small change in the test/Makefile to use >> ALT_OUTPUTDIR when it's set. That speeds up running tests when the >> source repository is on a NFS drive. Can I get at least one review >> of that? >> >> http://cr.openjdk.java.net/~twisti/6991596/webrev.02/ > > Besides the fact that it shouldn't be in the same changeset - > looks good for me. Well, it a very small change so I think I can piggy-back it. Thanks for the review! -- Christian From tom.rodriguez at oracle.com Fri Oct 15 11:40:03 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 15 Oct 2010 11:40:03 -0700 Subject: review (S) for 6992477: fix for 6991512 broke sparc barriers Message-ID: <9E185745-2959-4226-9107-069DD4FBEA67@oracle.com> http://cr.openjdk.java.net/~never/6992477 6992477: fix for 6991512 broke sparc barriers Reviewed-by: The fix for 6991512 changed the type of the temporary register used for the address of the field being modified in a Object cmpxchg from intptr_t to T_OBJECT. T_OBJECT is only used for pointers to the head of an object and the result of this calculation is a derived pointer which causes later failures when trying to emit code. The fix is to restore the original code and then fix the original issue by changing the G1PostBarrierStub::emit_code on x86 to use as_pointer_register to match the sparc version of the code. Tested with failing tests from nightly. src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp src/cpu/x86/vm/c1_LIRGenerator_x86.cpp src/share/vm/c1/c1_LIRGenerator.cpp src/cpu/x86/vm/c1_CodeStubs_x86.cpp From igor.veresov at oracle.com Fri Oct 15 12:03:56 2010 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 15 Oct 2010 12:03:56 -0700 Subject: review (S) for 6992477: fix for 6991512 broke sparc barriers In-Reply-To: <9E185745-2959-4226-9107-069DD4FBEA67@oracle.com> References: <9E185745-2959-4226-9107-069DD4FBEA67@oracle.com> Message-ID: <4CB8A59C.7080804@oracle.com> I got it obviously wrong. :( Look good. Thanks a lot for fixing it! igor On 10/15/10 11:40 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6992477 > > 6992477: fix for 6991512 broke sparc barriers > Reviewed-by: > > The fix for 6991512 changed the type of the temporary register used > for the address of the field being modified in a Object cmpxchg from > intptr_t to T_OBJECT. T_OBJECT is only used for pointers to the head > of an object and the result of this calculation is a derived pointer > which causes later failures when trying to emit code. The fix is to > restore the original code and then fix the original issue by changing > the G1PostBarrierStub::emit_code on x86 to use as_pointer_register to > match the sparc version of the code. Tested with failing tests from > nightly. > > src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp > src/cpu/x86/vm/c1_LIRGenerator_x86.cpp > src/share/vm/c1/c1_LIRGenerator.cpp > src/cpu/x86/vm/c1_CodeStubs_x86.cpp From vladimir.kozlov at oracle.com Fri Oct 15 12:17:18 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Oct 2010 12:17:18 -0700 Subject: review (S) for 6992477: fix for 6991512 broke sparc barriers In-Reply-To: <9E185745-2959-4226-9107-069DD4FBEA67@oracle.com> References: <9E185745-2959-4226-9107-069DD4FBEA67@oracle.com> Message-ID: <4CB8A8BE.1030207@oracle.com> Looks good. Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6992477 > > 6992477: fix for 6991512 broke sparc barriers > Reviewed-by: > > The fix for 6991512 changed the type of the temporary register used > for the address of the field being modified in a Object cmpxchg from > intptr_t to T_OBJECT. T_OBJECT is only used for pointers to the head > of an object and the result of this calculation is a derived pointer > which causes later failures when trying to emit code. The fix is to > restore the original code and then fix the original issue by changing > the G1PostBarrierStub::emit_code on x86 to use as_pointer_register to > match the sparc version of the code. Tested with failing tests from > nightly. > > src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp > src/cpu/x86/vm/c1_LIRGenerator_x86.cpp > src/share/vm/c1/c1_LIRGenerator.cpp > src/cpu/x86/vm/c1_CodeStubs_x86.cpp From tom.rodriguez at oracle.com Fri Oct 15 12:29:27 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 15 Oct 2010 12:29:27 -0700 Subject: review (S) for 6992477: fix for 6991512 broke sparc barriers In-Reply-To: <4CB8A59C.7080804@oracle.com> References: <9E185745-2959-4226-9107-069DD4FBEA67@oracle.com> <4CB8A59C.7080804@oracle.com> Message-ID: <1BAC83AF-CB41-46AD-892F-52E45AF8ED6C@oracle.com> Sorry I missed this in my review. Thanks! tom On Oct 15, 2010, at 12:03 PM, Igor Veresov wrote: > I got it obviously wrong. :( > Look good. Thanks a lot for fixing it! > > igor > > On 10/15/10 11:40 AM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6992477 >> >> 6992477: fix for 6991512 broke sparc barriers >> Reviewed-by: >> >> The fix for 6991512 changed the type of the temporary register used >> for the address of the field being modified in a Object cmpxchg from >> intptr_t to T_OBJECT. T_OBJECT is only used for pointers to the head >> of an object and the result of this calculation is a derived pointer >> which causes later failures when trying to emit code. The fix is to >> restore the original code and then fix the original issue by changing >> the G1PostBarrierStub::emit_code on x86 to use as_pointer_register to >> match the sparc version of the code. Tested with failing tests from >> nightly. >> >> src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp >> src/cpu/x86/vm/c1_LIRGenerator_x86.cpp >> src/share/vm/c1/c1_LIRGenerator.cpp >> src/cpu/x86/vm/c1_CodeStubs_x86.cpp > From tom.rodriguez at oracle.com Fri Oct 15 12:29:37 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 15 Oct 2010 12:29:37 -0700 Subject: review (S) for 6992477: fix for 6991512 broke sparc barriers In-Reply-To: <4CB8A8BE.1030207@oracle.com> References: <9E185745-2959-4226-9107-069DD4FBEA67@oracle.com> <4CB8A8BE.1030207@oracle.com> Message-ID: <4C4A5B09-385F-4362-B0FD-769A162677DD@oracle.com> Thanks! tom On Oct 15, 2010, at 12:17 PM, Vladimir Kozlov wrote: > Looks good. > > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6992477 >> 6992477: fix for 6991512 broke sparc barriers >> Reviewed-by: >> The fix for 6991512 changed the type of the temporary register used >> for the address of the field being modified in a Object cmpxchg from >> intptr_t to T_OBJECT. T_OBJECT is only used for pointers to the head >> of an object and the result of this calculation is a derived pointer >> which causes later failures when trying to emit code. The fix is to >> restore the original code and then fix the original issue by changing >> the G1PostBarrierStub::emit_code on x86 to use as_pointer_register to >> match the sparc version of the code. Tested with failing tests from >> nightly. >> src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp >> src/cpu/x86/vm/c1_LIRGenerator_x86.cpp >> src/share/vm/c1/c1_LIRGenerator.cpp >> src/cpu/x86/vm/c1_CodeStubs_x86.cpp From Christian.Thalinger at Sun.COM Mon Oct 18 07:52:04 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 18 Oct 2010 14:52:04 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC Message-ID: <20101018145214.111F847235@hg.openjdk.java.net> Changeset: 7aff5786cc02 Author: twisti Date: 2010-10-18 01:54 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7aff5786cc02 6991596: JSR 292 unimplemented adapter_opt_i2i and adapter_opt_l2i on SPARC Reviewed-by: kvn, jrose, dsamersoff ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! test/Makefile + test/compiler/6991596/Test6991596.java From christian.thalinger at oracle.com Mon Oct 18 09:25:02 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 18 Oct 2010 18:25:02 +0200 Subject: Request for reviews (M): 6990192: VM crashes in ciTypeFlow::get_block_for() Message-ID: <2377BCAF-FD88-44B7-B1D8-F436192CC50D@oracle.com> http://cr.openjdk.java.net/~twisti/6990192/webrev.01/ 6990192: VM crashes in ciTypeFlow::get_block_for() Reviewed-by: In SystemDictionary::find_method_handle_invoke when the classes of the signature are not on the bootclasspath the method always returns the newly created method resulting in an assert in ConstantPoolCacheEntry::set_f1. The fix is to set the first method coming in into the constant pool cache. To avoid races this is done atomically. Additionally the initialization of the invoke-method table is changed to be eagerly since initializing it lazily contains another race. Tested with testcase mentioned in CR. From tom.rodriguez at oracle.com Mon Oct 18 09:41:26 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 18 Oct 2010 09:41:26 -0700 Subject: Request for reviews (M): 6990192: VM crashes in ciTypeFlow::get_block_for() In-Reply-To: <2377BCAF-FD88-44B7-B1D8-F436192CC50D@oracle.com> References: <2377BCAF-FD88-44B7-B1D8-F436192CC50D@oracle.com> Message-ID: On Oct 18, 2010, at 9:25 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6990192/webrev.01/ > > 6990192: VM crashes in ciTypeFlow::get_block_for() > Reviewed-by: > > In SystemDictionary::find_method_handle_invoke when the classes of the > signature are not on the bootclasspath the method always returns the > newly created method resulting in an assert in > ConstantPoolCacheEntry::set_f1. > > The fix is to set the first method coming in into the constant pool > cache. To avoid races this is done atomically. > > Additionally the initialization of the invoke-method table is changed > to be eagerly since initializing it lazily contains another race. I don't think you want to use atomic_compare_exchange_oop since that is for handling Java fields that might be compressed. The fields in the cpCache are never compressed so you should just use cmpxchg_ptr directly. Otherwise it seems ok. tom > > Tested with testcase mentioned in CR. From christian.thalinger at oracle.com Mon Oct 18 10:07:40 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 18 Oct 2010 19:07:40 +0200 Subject: Request for reviews (M): 6990192: VM crashes in ciTypeFlow::get_block_for() In-Reply-To: References: <2377BCAF-FD88-44B7-B1D8-F436192CC50D@oracle.com> Message-ID: <14F7AC4C-488F-491A-BD6D-4D02C4A3EF49@oracle.com> On Oct 18, 2010, at 6:41 PM, Tom Rodriguez wrote: > > On Oct 18, 2010, at 9:25 AM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/6990192/webrev.01/ >> >> 6990192: VM crashes in ciTypeFlow::get_block_for() >> Reviewed-by: >> >> In SystemDictionary::find_method_handle_invoke when the classes of >> the >> signature are not on the bootclasspath the method always returns the >> newly created method resulting in an assert in >> ConstantPoolCacheEntry::set_f1. >> >> The fix is to set the first method coming in into the constant pool >> cache. To avoid races this is done atomically. >> >> Additionally the initialization of the invoke-method table is changed >> to be eagerly since initializing it lazily contains another race. > > I don't think you want to use atomic_compare_exchange_oop since that > is for handling Java fields that might be compressed. The fields in > the cpCache are never compressed so you should just use cmpxchg_ptr > directly. Otherwise it seems ok. > > tom OK. I wasn't sure I can use cmpxchg_ptr directly, but since I'm handling the barriers myself it should be fine. Thanks! -- Christian From tom.rodriguez at oracle.com Mon Oct 18 12:32:05 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 18 Oct 2010 12:32:05 -0700 Subject: review (S) for 6968367: can_post_on_exceptions is still using VM_DeoptimizeFrame in some places Message-ID: <867C94C9-6FF3-4F5E-934A-0E8631D391F7@oracle.com> http://cr.openjdk.java.net/~never/6968367 6968367: can_post_on_exceptions is still using VM_DeoptimizeFrame in some places Reviewed-by: The fix for 6902182 changed some call sites where deopt is needed to call directly into deoptimize_frame instead of using VM_DeoptimizeFrame but it missed quite a few places, particularly in the client compiler. Instead of directly modifying each site to use the appropriate version I modified Deoptimization::deoptimize_frame to select the appropriate version, made VM_DeoptimizeFrame private, and updated all call sites to use the main entry point. Tested with all the nsk JVMTI tests. From vladimir.kozlov at oracle.com Mon Oct 18 12:51:31 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 18 Oct 2010 12:51:31 -0700 Subject: review (S) for 6968367: can_post_on_exceptions is still using VM_DeoptimizeFrame in some places In-Reply-To: <867C94C9-6FF3-4F5E-934A-0E8631D391F7@oracle.com> References: <867C94C9-6FF3-4F5E-934A-0E8631D391F7@oracle.com> Message-ID: <4CBCA543.5010107@oracle.com> Looks good. There are typos "frmaes" in vm_operations.hpp: + // Deopt helper that can deoptimize frmaes in threads other than the "doptimize" in deoptimization.hpp: + // VM_DeoptimizeFrame otherwise, doptimize directly. Thanks, Vladimir Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/6968367 > > 6968367: can_post_on_exceptions is still using VM_DeoptimizeFrame in some places > Reviewed-by: > > The fix for 6902182 changed some call sites where deopt is needed to > call directly into deoptimize_frame instead of using > VM_DeoptimizeFrame but it missed quite a few places, particularly in > the client compiler. Instead of directly modifying each site to use > the appropriate version I modified Deoptimization::deoptimize_frame to > select the appropriate version, made VM_DeoptimizeFrame private, and > updated all call sites to use the main entry point. Tested with all > the nsk JVMTI tests. From tom.rodriguez at oracle.com Mon Oct 18 13:27:45 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 18 Oct 2010 13:27:45 -0700 Subject: review (S) for 6968367: can_post_on_exceptions is still using VM_DeoptimizeFrame in some places In-Reply-To: <4CBCA543.5010107@oracle.com> References: <867C94C9-6FF3-4F5E-934A-0E8631D391F7@oracle.com> <4CBCA543.5010107@oracle.com> Message-ID: Fixed. I also removed that inappropriate comma. Thanks! tom On Oct 18, 2010, at 12:51 PM, Vladimir Kozlov wrote: > Looks good. > > There are typos > > "frmaes" in vm_operations.hpp: > > + // Deopt helper that can deoptimize frmaes in threads other than the > > "doptimize" in deoptimization.hpp: > > + // VM_DeoptimizeFrame otherwise, doptimize directly. > > Thanks, > Vladimir > > Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/6968367 >> 6968367: can_post_on_exceptions is still using VM_DeoptimizeFrame in some places >> Reviewed-by: >> The fix for 6902182 changed some call sites where deopt is needed to >> call directly into deoptimize_frame instead of using >> VM_DeoptimizeFrame but it missed quite a few places, particularly in >> the client compiler. Instead of directly modifying each site to use >> the appropriate version I modified Deoptimization::deoptimize_frame to >> select the appropriate version, made VM_DeoptimizeFrame private, and >> updated all call sites to use the main entry point. Tested with all >> the nsk JVMTI tests. From christian.thalinger at oracle.com Tue Oct 19 01:31:00 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 19 Oct 2010 10:31:00 +0200 Subject: review (S) for 6968367: can_post_on_exceptions is still using VM_DeoptimizeFrame in some places In-Reply-To: References: <867C94C9-6FF3-4F5E-934A-0E8631D391F7@oracle.com> <4CBCA543.5010107@oracle.com> Message-ID: <701C0E8B-7FD3-4E9B-801F-59935E796C16@oracle.com> On Oct 18, 2010, at 10:27 PM, Tom Rodriguez wrote: > Fixed. I also removed that inappropriate comma. Thanks! Looks good. -- Christian From christian.thalinger at oracle.com Tue Oct 19 02:45:15 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 19 Oct 2010 11:45:15 +0200 Subject: Request for reviews (M): 6990192: VM crashes in ciTypeFlow::get_block_for() In-Reply-To: <14F7AC4C-488F-491A-BD6D-4D02C4A3EF49@oracle.com> References: <2377BCAF-FD88-44B7-B1D8-F436192CC50D@oracle.com> <14F7AC4C-488F-491A-BD6D-4D02C4A3EF49@oracle.com> Message-ID: <006697DD-036E-4083-8257-523B4F249BD7@oracle.com> On Oct 18, 2010, at 7:07 PM, Christian Thalinger wrote: > On Oct 18, 2010, at 6:41 PM, Tom Rodriguez wrote: >> >> On Oct 18, 2010, at 9:25 AM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/6990192/webrev.01/ >>> >>> 6990192: VM crashes in ciTypeFlow::get_block_for() >>> Reviewed-by: >>> >>> In SystemDictionary::find_method_handle_invoke when the classes of >>> the >>> signature are not on the bootclasspath the method always returns the >>> newly created method resulting in an assert in >>> ConstantPoolCacheEntry::set_f1. >>> >>> The fix is to set the first method coming in into the constant pool >>> cache. To avoid races this is done atomically. >>> >>> Additionally the initialization of the invoke-method table is >>> changed >>> to be eagerly since initializing it lazily contains another race. >> >> I don't think you want to use atomic_compare_exchange_oop since >> that is for handling Java fields that might be compressed. The >> fields in the cpCache are never compressed so you should just use >> cmpxchg_ptr directly. Otherwise it seems ok. >> >> tom > > > OK. I wasn't sure I can use cmpxchg_ptr directly, but since I'm > handling the barriers myself it should be fine. Thanks! I'm going to commit as: http://cr.openjdk.java.net/~twisti/6990192/webrev.02/ Additionally I tested failing JRuby tests. -- Christian From tom.rodriguez at oracle.com Tue Oct 19 05:00:45 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Tue, 19 Oct 2010 12:00:45 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 15 new changesets Message-ID: <20101019120119.7DF694727D@hg.openjdk.java.net> Changeset: c32059ef4dc0 Author: johnc Date: 2010-10-12 09:36 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c32059ef4dc0 6971296: G1: simplify G1RemSet class hierarchy Summary: Remove G1RemSet base class and StupidG1RemSet class; rename HRInto_G1RemSet to just G1RemSet. Reviewed-by: ysr, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: b14ec34b1e07 Author: jcoomes Date: 2010-10-12 11:29 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b14ec34b1e07 6989448: G1: refactor and simplify G1ParScanThreadState Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: ee813f7b46e4 Author: jcoomes Date: 2010-10-14 11:57 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ee813f7b46e4 Merge Changeset: dfb38ea7da17 Author: zgu Date: 2010-09-30 12:05 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/dfb38ea7da17 6988363: Rebrand vm vendor property settings (jdk7 only) Summary: Vendor properties should be initialized after JDK version is determined. Reviewed-by: kamg, ohair, dcubed, dholmes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp Changeset: 1c352af0135d Author: acorn Date: 2010-10-04 13:11 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1c352af0135d 6763959: java.util.concurrent.locks.LockSupport.parkUntil(0) blocks forever Summary: Absolute time 0 needs to return immediately. Reviewed-by: phh, dcubed, dholmes ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: 644f98c78e33 Author: acorn Date: 2010-10-04 10:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/644f98c78e33 Merge Changeset: b6aedd1acdc0 Author: coleenp Date: 2010-10-07 08:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b6aedd1acdc0 6983240: guarantee((Solaris::min_stack_allowed >= (StackYellowPages+StackRedPages...) wrong Summary: min_stack_allowed is a compile time constant and Stack*Pages are settable Reviewed-by: dholmes, kvn ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/exceptions.cpp Changeset: 3dc12ef8735e Author: bobv Date: 2010-10-07 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3dc12ef8735e 6989297: Integrate additional portability improvements Reviewed-by: vladidan, dholmes ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/os/linux/vm/attachListener_linux.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 7491c8b96111 Author: bobv Date: 2010-10-07 15:14 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/7491c8b96111 Merge Changeset: c77b5c592eab Author: kamg Date: 2010-10-12 10:57 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/c77b5c592eab 6392697: Additional flag needed to supress Hotspot warning messages Summary: Apply PrintJvmWarnings flag to all warnings Reviewed-by: coleenp, phh ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp Changeset: 75b0735b4d04 Author: acorn Date: 2010-10-13 11:46 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/75b0735b4d04 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/includeDB_core ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: beba40b26a79 Author: acorn Date: 2010-10-15 15:12 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/beba40b26a79 Merge ! src/cpu/x86/vm/methodHandles_x86.cpp Changeset: 07a218de38cb Author: never Date: 2010-10-15 14:21 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/07a218de38cb 6992477: fix for 6991512 broke sparc barriers Reviewed-by: kvn, iveresov ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 75ab0162aa84 Author: never Date: 2010-10-18 09:33 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/75ab0162aa84 Merge Changeset: 0357ff4bd6b2 Author: never Date: 2010-10-18 15:43 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/0357ff4bd6b2 Merge From vladimir.kozlov at oracle.com Tue Oct 19 07:35:38 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Oct 2010 07:35:38 -0700 Subject: Request for reviews (M): 6990192: VM crashes in ciTypeFlow::get_block_for() In-Reply-To: <006697DD-036E-4083-8257-523B4F249BD7@oracle.com> References: <2377BCAF-FD88-44B7-B1D8-F436192CC50D@oracle.com> <14F7AC4C-488F-491A-BD6D-4D02C4A3EF49@oracle.com> <006697DD-036E-4083-8257-523B4F249BD7@oracle.com> Message-ID: <4CBDACBA.6070705@oracle.com> Looks good. Vladimir On 10/19/10 2:45 AM, Christian Thalinger wrote: > On Oct 18, 2010, at 7:07 PM, Christian Thalinger wrote: >> On Oct 18, 2010, at 6:41 PM, Tom Rodriguez wrote: >>> >>> On Oct 18, 2010, at 9:25 AM, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/6990192/webrev.01/ >>>> >>>> 6990192: VM crashes in ciTypeFlow::get_block_for() >>>> Reviewed-by: >>>> >>>> In SystemDictionary::find_method_handle_invoke when the classes of the >>>> signature are not on the bootclasspath the method always returns the >>>> newly created method resulting in an assert in >>>> ConstantPoolCacheEntry::set_f1. >>>> >>>> The fix is to set the first method coming in into the constant pool >>>> cache. To avoid races this is done atomically. >>>> >>>> Additionally the initialization of the invoke-method table is changed >>>> to be eagerly since initializing it lazily contains another race. >>> >>> I don't think you want to use atomic_compare_exchange_oop since that is for handling Java fields that might be >>> compressed. The fields in the cpCache are never compressed so you should just use cmpxchg_ptr directly. Otherwise it >>> seems ok. >>> >>> tom >> >> >> OK. I wasn't sure I can use cmpxchg_ptr directly, but since I'm handling the barriers myself it should be fine. Thanks! > > I'm going to commit as: > > http://cr.openjdk.java.net/~twisti/6990192/webrev.02/ > > Additionally I tested failing JRuby tests. > > -- Christian From Christian.Thalinger at Sun.COM Wed Oct 20 07:39:11 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 20 Oct 2010 14:39:11 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20101020143914.C4BCD472CB@hg.openjdk.java.net> Changeset: 87d6a4d1ecbc Author: twisti Date: 2010-10-19 02:52 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/87d6a4d1ecbc 6990192: VM crashes in ciTypeFlow::get_block_for() Reviewed-by: never ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/cpCacheOop.cpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/runtime/thread.cpp Changeset: cd4e20dc9917 Author: twisti Date: 2010-10-20 04:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cd4e20dc9917 Merge ! src/share/vm/runtime/thread.cpp From tom.rodriguez at oracle.com Wed Oct 20 16:14:53 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Wed, 20 Oct 2010 23:14:53 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 2 new changesets Message-ID: <20101020231457.E1A4D472E6@hg.openjdk.java.net> Changeset: ce6848d0666d Author: never Date: 2010-10-19 16:14 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/ce6848d0666d 6968367: can_post_on_exceptions is still using VM_DeoptimizeFrame in some places Reviewed-by: kvn, twisti ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/includeDB_features ! src/share/vm/includeDB_jvmti ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp Changeset: f8aaf8522a6b Author: never Date: 2010-10-20 13:18 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f8aaf8522a6b Merge From tom.rodriguez at oracle.com Thu Oct 21 16:05:56 2010 From: tom.rodriguez at oracle.com (tom.rodriguez at oracle.com) Date: Thu, 21 Oct 2010 23:05:56 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6970683: improvements to hs_err output Message-ID: <20101021230558.3BB2F47326@hg.openjdk.java.net> Changeset: 1e9a9d2e6509 Author: never Date: 2010-10-21 11:55 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/1e9a9d2e6509 6970683: improvements to hs_err output Reviewed-by: kvn, jrose, dholmes, coleenp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/heap.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/vmError.cpp From john.r.rose at oracle.com Fri Oct 22 00:37:08 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 22 Oct 2010 00:37:08 -0700 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 In-Reply-To: <1284970585.14822.2034.camel@macbook> References: <82AE8340-AC58-4D7E-9953-2E8A25DDB739@oracle.com> <1284457872.9557.47.camel@macbook> <1284970585.14822.2034.camel@macbook> Message-ID: On Sep 20, 2010, at 1:16 AM, Christian Thalinger wrote: > On Tue, 2010-09-14 at 19:55 -0700, John Rose wrote: >> Here's the update: >> >> http://cr.openjdk.java.net/~jrose/6984311/webrev.01/ > > I looked closely at the SPARC changes and these look good. Thanks. I split out the changes from methodHandles_sparc (and supporting assembler functions) into a new bug 6994093, since those group with the invokeGeneric stuff. Here's the split out patch: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-ing-6994093.patch The bug report for 6994093 has a properly rebased patch for JDK 7, which is what I'll apply. -- John From john.r.rose at oracle.com Fri Oct 22 00:40:48 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 22 Oct 2010 00:40:48 -0700 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 In-Reply-To: <1284969431.14822.2014.camel@macbook> References: <82AE8340-AC58-4D7E-9953-2E8A25DDB739@oracle.com> <1284457872.9557.47.camel@macbook> <51F2F4F8-45C4-4192-9239-AFAC62D8C85F@oracle.com> <1284969431.14822.2014.camel@macbook> Message-ID: <1AE93780-52AA-42A1-870E-06B88A9F1C7A@oracle.com> Here is an updated patch for what used to be N-ary MethodApply nodes. At Remi Forax's suggestion, the N-ary argument list has been moved into the CONSTANT_InvokeDynamic entry, and the CONSTANT_MethodApply type has been deleted. This code passes a unit test with both trivial and non-trivial argument lists. It also passes -XX:+StressMethodComparator, which walks all over the constant pool. Please re-review. -- John On Sep 20, 2010, at 12:57 AM, Christian Thalinger wrote: > On Wed, 2010-09-15 at 01:22 -0700, John Rose wrote: >> On Sep 14, 2010, at 7:55 PM, John Rose wrote: >> >>> Here's the update: >>> >>> http://cr.openjdk.java.net/~jrose/6984311/webrev.01/ >>> >>> Note: I may ask for review of an alternative form of this change set, which uses N-ary instead of binary nodes in the constant pool. The EG is discussing both options. >> >> I did the variation which supports N-ary MethodApply nodes. It is somewhat less natural than the binary MethodApply nodes, because constant pools contain mostly binary nodes, but it matches the meaning of the constants better to allow them to be N-ary. And the extra data structure is pretty simple. See what you think. >> >> http://cr.openjdk.java.net/~jrose/6984311/webrev.01.nary >> >> (These are only the diffs from the binary to the N-ary version.) > > src/share/vm/classfile/classFileParser.cpp: > > + cfs->guarantee_more(3, CHECK); // operand_count, ..., tag/access_flags > + u2 op_count = cfs->get_u2_fast(); > + cfs->guarantee_more(2*op_count + 1, CHECK); > > I think the additional +1 is wrong as you check for 3 in the first > guarantee_more. > > Otherwise it looks good. > > -- Christian > From john.r.rose at oracle.com Fri Oct 22 00:59:05 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 22 Oct 2010 00:59:05 -0700 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 In-Reply-To: <4C908FC8.2000604@univ-mlv.fr> References: <82AE8340-AC58-4D7E-9953-2E8A25DDB739@oracle.com> <1284457872.9557.47.camel@macbook> <51F2F4F8-45C4-4192-9239-AFAC62D8C85F@oracle.com> <4C908FC8.2000604@univ-mlv.fr> Message-ID: <30DC4D00-F9C6-4D23-AA72-F4A8C6329D82@oracle.com> On Sep 15, 2010, at 2:20 AM, R?mi Forax wrote: >> http://cr.openjdk.java.net/~jrose/6984311/webrev.01.nary >> >> (These are only the diffs from the binary to the N-ary version.) >> >> -- John > > I prefer the N-ary version :) > > Questions: > - Why having two constants InvokeDynamic and MethodApply in that case. > Constant arguments are tied to a BSM. I don't think you can reuse > array of arguments accross different BSMs. Your wish is my command, this time :-) http://cr.openjdk.java.net/~jrose/6984311/webrev.02/ > - Why argcount is stored using 2 bytes instead of one ? > These arguments are arguments of a Java method (the BSM) > which limit the number or argument to 255. The argument list gets passed to the BSM as a single argument, an Object array of length up to 65535. This in turn is easy to receive into the BSM as a Java varargs argument (or simple Object[]). This is easier to implement and far more useful than passing a variable (and limited) number of arguments on the stack. More details on the mlvm-dev list... -- John From gbenson at redhat.com Fri Oct 22 03:09:51 2010 From: gbenson at redhat.com (Gary Benson) Date: Fri, 22 Oct 2010 11:09:51 +0100 Subject: Review Request: Zero PowerPC fix Message-ID: <20101022100951.GB5952@redhat.com> Hi all, The recent addition of PowerPC-specific code broke Zero. This webrev fixes: http://cr.openjdk.java.net/~gbenson/zero-ppc-fix/ I don't have a bug id for this. Cheers, Gary -- http://gbenson.net/ From christian.thalinger at oracle.com Fri Oct 22 03:22:28 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Oct 2010 12:22:28 +0200 Subject: Review Request: Zero PowerPC fix In-Reply-To: <20101022100951.GB5952@redhat.com> References: <20101022100951.GB5952@redhat.com> Message-ID: <2D3AE4D5-CD95-4F50-A176-F0397A93C8EE@oracle.com> On Oct 22, 2010, at 12:09 PM, Gary Benson wrote: > Hi all, > > The recent addition of PowerPC-specific code broke Zero. > This webrev fixes: > > http://cr.openjdk.java.net/~gbenson/zero-ppc-fix/ > > I don't have a bug id for this. I filed: 6994130: Zero PowerPC fix The change looks good. -- Christian From gbenson at redhat.com Fri Oct 22 03:35:41 2010 From: gbenson at redhat.com (Gary Benson) Date: Fri, 22 Oct 2010 11:35:41 +0100 Subject: Review Request: Zero PowerPC fix In-Reply-To: <2D3AE4D5-CD95-4F50-A176-F0397A93C8EE@oracle.com> References: <20101022100951.GB5952@redhat.com> <2D3AE4D5-CD95-4F50-A176-F0397A93C8EE@oracle.com> Message-ID: <20101022103541.GE5952@redhat.com> Christian Thalinger wrote: > On Oct 22, 2010, at 12:09 PM, Gary Benson wrote: > > The recent addition of PowerPC-specific code broke Zero. > > This webrev fixes: > > > > http://cr.openjdk.java.net/~gbenson/zero-ppc-fix/ > > > > I don't have a bug id for this. > > I filed: > > 6994130: Zero PowerPC fix > > The change looks good. Awesome, thanks! Cheers, Gary -- http://gbenson.net/ From Christian.Thalinger at Sun.COM Fri Oct 22 06:38:14 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 22 Oct 2010 13:38:14 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6994130: Zero PowerPC fix Message-ID: <20101022133816.41A4147359@hg.openjdk.java.net> Changeset: f195c4737aca Author: twisti Date: 2010-10-22 03:34 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/f195c4737aca 6994130: Zero PowerPC fix Summary: 6953477 broke Zero. Reviewed-by: twisti Contributed-by: Gary Benson ! src/share/vm/runtime/frame.cpp From vladimir.kozlov at oracle.com Fri Oct 22 18:25:01 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Oct 2010 18:25:01 -0700 Subject: Request for reviews (M): 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. Message-ID: <4CC2396D.5000701@oracle.com> http://cr.openjdk.java.net/~kvn/6987135/webrev.00 Fixed 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. Changes for 6603011 added the conversion of long division by constant to the code with multiply. But some modern cpus improved DIV instruction performance. Use it for long division by constant when it is faster than code with multiply. Tested on US3, T1, T2, Sparc64, AMD and Intel latest cpus. From john.r.rose at oracle.com Sat Oct 23 00:04:53 2010 From: john.r.rose at oracle.com (John Rose) Date: Sat, 23 Oct 2010 00:04:53 -0700 Subject: review request (S): 6981788 GC map generator sometimes picks up the wrong kind of instruction operand Message-ID: <7BF334CE-4D06-4A20-BDE8-EFA34846BE2C@oracle.com> 6981788: GC map generator sometimes picks up the wrong kind of instruction operand Summary: Distinguish pool indexes from cache indexes in recently changed code. http://cr.openjdk.java.net/~jrose/6981788/webrev.00 The bug reproduces with ScavengeALot on an invokedynamic instruction and on a fast_aldc instruction (ldc/MH). Verified the fix. Tried it with and without TraceNewOopMapGeneration. -- John From tom.rodriguez at oracle.com Mon Oct 25 11:30:38 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 25 Oct 2010 11:30:38 -0700 Subject: review request (S): 6981788 GC map generator sometimes picks up the wrong kind of instruction operand In-Reply-To: <7BF334CE-4D06-4A20-BDE8-EFA34846BE2C@oracle.com> References: <7BF334CE-4D06-4A20-BDE8-EFA34846BE2C@oracle.com> Message-ID: <20F6E98B-ACEB-4A47-AF9A-AB35B8F9F5B3@oracle.com> On Oct 23, 2010, at 12:04 AM, John Rose wrote: > 6981788: GC map generator sometimes picks up the wrong kind of instruction operand > Summary: Distinguish pool indexes from cache indexes in recently changed code. > http://cr.openjdk.java.net/~jrose/6981788/webrev.00 I don't understand this line: + int idx = currentBC->has_index_u4() ? currentBC->get_index_u4() : currentBC->get_index_u2_cpcache(); idx is used to index into the constant pool immediately after, so why is it asking for cpcache? Also why is this right? + bool ref = ldc->has_cache_index() || cp->is_pointer_entry(ldc->pool_index()); What does has_cache_index have to do with ref'ness? tom > > The bug reproduces with ScavengeALot on an invokedynamic instruction and on a fast_aldc instruction (ldc/MH). > > Verified the fix. Tried it with and without TraceNewOopMapGeneration. > > -- John From john.r.rose at oracle.com Mon Oct 25 12:22:27 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 25 Oct 2010 12:22:27 -0700 Subject: review request (S): 6981788 GC map generator sometimes picks up the wrong kind of instruction operand In-Reply-To: <20F6E98B-ACEB-4A47-AF9A-AB35B8F9F5B3@oracle.com> References: <7BF334CE-4D06-4A20-BDE8-EFA34846BE2C@oracle.com> <20F6E98B-ACEB-4A47-AF9A-AB35B8F9F5B3@oracle.com> Message-ID: On Oct 25, 2010, at 11:30 AM, Tom Rodriguez wrote: > On Oct 23, 2010, at 12:04 AM, John Rose wrote: > >> 6981788: GC map generator sometimes picks up the wrong kind of instruction operand >> Summary: Distinguish pool indexes from cache indexes in recently changed code. >> http://cr.openjdk.java.net/~jrose/6981788/webrev.00 > > I don't understand this line: > > + int idx = currentBC->has_index_u4() ? currentBC->get_index_u4() : currentBC->get_index_u2_cpcache(); > > idx is used to index into the constant pool immediately after, so why is it asking for cpcache? CP::name_and_type_ref_index_at and related accessors use CP::remap_instruction_operand_from_cache to interpret their indexes. The idea is to take a "raw" index from the rewritten bytecodes and hand it to the CP, and have the CP interpret it correctly, whether it is a normal index or a cache index. The CP accessors themselves are (in their appearance) ambiguous as to which kind of index each one takes. The "uncached" versions make it clear they take a plain index, and suggest that the regular versions take cache indexes. There is a comment paragraph around line 500 of constantPoolOop.hpp which explains this. (I just noticed that the comment mentions byte swapping, which is out of date. I'll change that, since byte swapping is now managed by the bytecode stream.) It has worked like this for a long time, but recently I made it more obvious by making the bytecode stream accessors call out whether they were intending to pick up a cache index or regular index. A next step could be to distinguish the CP accessors more clearly also. > Also why is this right? > > + bool ref = ldc->has_cache_index() || cp->is_pointer_entry(ldc->pool_index()); > > What does has_cache_index have to do with ref'ness? It's an internal detail: ldc constants which are rewritten to use the cache are all oops. Primitive constants stay put in the main CP. Shall I put in a comment there? Thanks, -- John > tom > >> >> The bug reproduces with ScavengeALot on an invokedynamic instruction and on a fast_aldc instruction (ldc/MH). >> >> Verified the fix. Tried it with and without TraceNewOopMapGeneration. >> >> -- John > From tom.rodriguez at oracle.com Mon Oct 25 12:32:34 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 25 Oct 2010 12:32:34 -0700 Subject: review request (S): 6981788 GC map generator sometimes picks up the wrong kind of instruction operand In-Reply-To: References: <7BF334CE-4D06-4A20-BDE8-EFA34846BE2C@oracle.com> <20F6E98B-ACEB-4A47-AF9A-AB35B8F9F5B3@oracle.com> Message-ID: On Oct 25, 2010, at 12:22 PM, John Rose wrote: > On Oct 25, 2010, at 11:30 AM, Tom Rodriguez wrote: > >> On Oct 23, 2010, at 12:04 AM, John Rose wrote: >> >>> 6981788: GC map generator sometimes picks up the wrong kind of instruction operand >>> Summary: Distinguish pool indexes from cache indexes in recently changed code. >>> http://cr.openjdk.java.net/~jrose/6981788/webrev.00 >> >> I don't understand this line: >> >> + int idx = currentBC->has_index_u4() ? currentBC->get_index_u4() : currentBC->get_index_u2_cpcache(); >> >> idx is used to index into the constant pool immediately after, so why is it asking for cpcache? > > CP::name_and_type_ref_index_at and related accessors use CP::remap_instruction_operand_from_cache to interpret their indexes. The idea is to take a "raw" index from the rewritten bytecodes and hand it to the CP, and have the CP interpret it correctly, whether it is a normal index or a cache index. The CP accessors themselves are (in their appearance) ambiguous as to which kind of index each one takes. The "uncached" versions make it clear they take a plain index, and suggest that the regular versions take cache indexes. There is a comment paragraph around line 500 of constantPoolOop.hpp which explains this. Ah, yes. I'd forgotten that. That looks fine. > (I just noticed that the comment mentions byte swapping, which is out of date. I'll change that, since byte swapping is now managed by the bytecode stream.) > > It has worked like this for a long time, but recently I made it more obvious by making the bytecode stream accessors call out whether they were intending to pick up a cache index or regular index. A next step could be to distinguish the CP accessors more clearly also. It's certainly a bit confusing when you look at it closely. Most of the time the distinction is ignored/invisible by users of the constant pools. > >> Also why is this right? >> >> + bool ref = ldc->has_cache_index() || cp->is_pointer_entry(ldc->pool_index()); >> >> What does has_cache_index have to do with ref'ness? > > It's an internal detail: ldc constants which are rewritten to use the cache are all oops. Primitive constants stay put in the main CP. Shall I put in a comment there? That's what I figured. Please do. Is there an appropriate place where that assumption could be asserted? Looks good otherwise. tom > > Thanks, > -- John > >> tom >> >>> >>> The bug reproduces with ScavengeALot on an invokedynamic instruction and on a fast_aldc instruction (ldc/MH). >>> >>> Verified the fix. Tried it with and without TraceNewOopMapGeneration. >>> >>> -- John >> > From tom.rodriguez at oracle.com Mon Oct 25 13:15:37 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 25 Oct 2010 13:15:37 -0700 Subject: Request for reviews (M): 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. In-Reply-To: <4CC2396D.5000701@oracle.com> References: <4CC2396D.5000701@oracle.com> Message-ID: <98B06EDE-B138-4389-AF13-DF9E684D0637@oracle.com> On Oct 22, 2010, at 6:25 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/6987135/webrev.00 > > Fixed 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. > > Changes for 6603011 added the conversion of long > division by constant to the code with multiply. > But some modern cpus improved DIV instruction > performance. Use it for long division by constant > when it is faster than code with multiply. The formats in x86_32.ad don't match the code. In modL_eReg_imm32, why can't the value be 0 or -1? Why don't you use an immL definition that ensures that? If imm is MININT then the pcon calculation will go wrong. I believe you could do the register declarations like this: + instruct modL_eReg_imm32( eADXRegL dst, eRegL src, immL32 imm, eRegI tmp, eFlagsReg cr ) %{ + match(Set dst (ModL src imm)); + effect(TEMP dst, TEMP tmp, KILL cr ); to leave the src and tmp unbound which would give the RA a little more freedom. Actually wouldn't connecting src and dst directly result in fewer moves in the normal case? You might need a new temp but it seems like there are quite a few moves of src into dst for the idivl. + instruct modL_eReg_imm32( eADXRegL dst, immL32 imm, eSIRegI tmp, eFlagsReg cr ) %{ + match(Set dst (ModL dst imm)); + effect( KILL cr ); tom > > Tested on US3, T1, T2, Sparc64, AMD and Intel latest cpus. > From john.r.rose at oracle.com Mon Oct 25 17:00:00 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 25 Oct 2010 17:00:00 -0700 Subject: review request (S): 6981788 GC map generator sometimes picks up the wrong kind of instruction operand In-Reply-To: References: <7BF334CE-4D06-4A20-BDE8-EFA34846BE2C@oracle.com> <20F6E98B-ACEB-4A47-AF9A-AB35B8F9F5B3@oracle.com> Message-ID: <07D40E42-F229-4F7F-986B-F2581CDA6D83@oracle.com> Thanks, Tom. Please see if this makes things clearer: http://cr.openjdk.java.net/~jrose/6981788/webrev.01 -- John From john.r.rose at oracle.com Tue Oct 26 01:39:59 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Oct 2010 01:39:59 -0700 Subject: review request (XL): 6981777: implement JSR 292 EG adjustments from summer 2010 Message-ID: <0522FD4C-C456-4C60-83AF-5ABC494AF871@oracle.com> This is a large set of miscellaneous API adjustments that takes account of intensive JSR 292 Expert Group work since the JVM Language Summit and JavaOne. http://cr.openjdk.java.net/~jrose/6981777/webrev.01/ An earlier message, sent to the EG and copied to mlvm-dev, details the changes: http://mail.openjdk.java.net/pipermail/mlvm-dev/2010-October/002048.html The focus of this change set is finalizing the API. The implementation in some cases is still partial. This change set passes the included jtreg unit tests, notably the one for the MethodHandles API. If you wish to consult the javadoc for this API change, it is here: http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm (live distribution) http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm-1026.zip (archived copy for this version) Thanks, -- John P.S. Thanks to Remi Forax and Alex Buckley for already pointing out bugs in the 1024 javadoc. They are fixed here. From forax at univ-mlv.fr Tue Oct 26 02:59:53 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 26 Oct 2010 11:59:53 +0200 Subject: review request (XL): 6981777: implement JSR 292 EG adjustments from summer 2010 In-Reply-To: <0522FD4C-C456-4C60-83AF-5ABC494AF871@oracle.com> References: <0522FD4C-C456-4C60-83AF-5ABC494AF871@oracle.com> Message-ID: <4CC6A699.6080904@univ-mlv.fr> Le 26/10/2010 10:39, John Rose a ?crit : > This is a large set of miscellaneous API adjustments that takes account of intensive JSR 292 Expert Group work since the JVM Language Summit and JavaOne. > > http://cr.openjdk.java.net/~jrose/6981777/webrev.01/ > > An earlier message, sent to the EG and copied to mlvm-dev, details the changes: > http://mail.openjdk.java.net/pipermail/mlvm-dev/2010-October/002048.html > > The focus of this change set is finalizing the API. The implementation in some cases is still partial. > > This change set passes the included jtreg unit tests, notably the one for the MethodHandles API. > > If you wish to consult the javadoc for this API change, it is here: > http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm (live distribution) > http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm-1026.zip (archived copy for this version) > > Thanks, > -- John > > P.S. Thanks to Remi Forax and Alex Buckley for already pointing out bugs in the 1024 javadoc. They are fixed here. You should also remove MethodType.toBytecodeString() and MethodType.fromBytecodeString() or at least deprecate them. They are very old and the backport never support them and nobody complain. R?mi ** -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101026/60b16159/attachment.html From tom.rodriguez at oracle.com Tue Oct 26 09:23:25 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 26 Oct 2010 09:23:25 -0700 Subject: review request (S): 6981788 GC map generator sometimes picks up the wrong kind of instruction operand In-Reply-To: <07D40E42-F229-4F7F-986B-F2581CDA6D83@oracle.com> References: <7BF334CE-4D06-4A20-BDE8-EFA34846BE2C@oracle.com> <20F6E98B-ACEB-4A47-AF9A-AB35B8F9F5B3@oracle.com> <07D40E42-F229-4F7F-986B-F2581CDA6D83@oracle.com> Message-ID: <1496C9EE-A0A6-4785-B093-37BC391E6CAA@oracle.com> That looks good. A real assert message, like "expected object", would be nice. tom On Oct 25, 2010, at 5:00 PM, John Rose wrote: > Thanks, Tom. Please see if this makes things clearer: > http://cr.openjdk.java.net/~jrose/6981788/webrev.01 > > -- John From john.r.rose at oracle.com Tue Oct 26 12:43:50 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Oct 2010 12:43:50 -0700 Subject: review request (S): 6981788 GC map generator sometimes picks up the wrong kind of instruction operand In-Reply-To: <1496C9EE-A0A6-4785-B093-37BC391E6CAA@oracle.com> References: <7BF334CE-4D06-4A20-BDE8-EFA34846BE2C@oracle.com> <20F6E98B-ACEB-4A47-AF9A-AB35B8F9F5B3@oracle.com> <07D40E42-F229-4F7F-986B-F2581CDA6D83@oracle.com> <1496C9EE-A0A6-4785-B093-37BC391E6CAA@oracle.com> Message-ID: <45BE9B71-8B76-4F45-BED8-77E5BD9FB0F4@oracle.com> Good; will do. Thanks! -- John On Oct 26, 2010, at 9:23 AM, Tom Rodriguez wrote: > That looks good. A real assert message, like "expected object", would be nice. > > tom > > On Oct 25, 2010, at 5:00 PM, John Rose wrote: > >> Thanks, Tom. Please see if this makes things clearer: >> http://cr.openjdk.java.net/~jrose/6981788/webrev.01 >> >> -- John > From john.r.rose at oracle.com Tue Oct 26 14:24:31 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 26 Oct 2010 14:24:31 -0700 Subject: review request (XL): 6981777: implement JSR 292 EG adjustments from summer 2010 In-Reply-To: <4CC6A699.6080904@univ-mlv.fr> References: <0522FD4C-C456-4C60-83AF-5ABC494AF871@oracle.com> <4CC6A699.6080904@univ-mlv.fr> Message-ID: <66E31433-167B-4125-9F79-1A85E3ECADDF@oracle.com> On Oct 26, 2010, at 2:59 AM, R?mi Forax wrote: > You should also remove MethodType.toBytecodeString() and MethodType.fromBytecodeString() > or at least deprecate them. > > They are very old and the backport never support them and nobody complain. Thanks; done. -- John From christian.thalinger at oracle.com Wed Oct 27 05:25:40 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 27 Oct 2010 14:25:40 +0200 Subject: Request for reviews (S): 6994630: java/lang/instrument/IsModifiableClassAgent.java fails with -XX:+EnableInvokeDynamic Message-ID: <96145F10-A036-4DC4-8A97-9EDF23F8BBCB@oracle.com> http://cr.openjdk.java.net/~twisti/6994630/webrev.01/ 6994630: java/lang/instrument/IsModifiableClassAgent.java fails with - XX:+EnableInvokeDynamic Summary: The logic of ClassFileParser::java_dyn_MethodHandle_fix_pre needs to take care of an already changed vmentry signature. Reviewed-by: There is a problem with the logic of ClassFileParser::java_dyn_MethodHandle_fix_pre. The method searches for a field called "vmentry" with the signature "byte". The signature of the field is then changed to vmSymbols::machine_word_signature() to hold an unmanged pointer. When the method is called again the field's signature is already changed and it throws a VirtualMachineError resulting in a VerifyError. The fix is to also check for the field with the already changed signature. Tested with the failing testcase. I also changed the type of the fields argument since we don't update the field pointer and removed a duplicated comment. From christian.thalinger at oracle.com Wed Oct 27 06:02:16 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 27 Oct 2010 15:02:16 +0200 Subject: review request (S): 6981788 GC map generator sometimes picks up the wrong kind of instruction operand In-Reply-To: <45BE9B71-8B76-4F45-BED8-77E5BD9FB0F4@oracle.com> References: <7BF334CE-4D06-4A20-BDE8-EFA34846BE2C@oracle.com> <20F6E98B-ACEB-4A47-AF9A-AB35B8F9F5B3@oracle.com> <07D40E42-F229-4F7F-986B-F2581CDA6D83@oracle.com> <1496C9EE-A0A6-4785-B093-37BC391E6CAA@oracle.com> <45BE9B71-8B76-4F45-BED8-77E5BD9FB0F4@oracle.com> Message-ID: <443C570B-ED24-4FF8-9512-6F9027C981E4@oracle.com> On Oct 26, 2010, at 9:43 PM, John Rose wrote: > Good; will do. Thanks! -- John Looks good. -- Christian From tom.rodriguez at oracle.com Wed Oct 27 14:23:05 2010 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 27 Oct 2010 14:23:05 -0700 Subject: Request for reviews (S): 6994630: java/lang/instrument/IsModifiableClassAgent.java fails with -XX:+EnableInvokeDynamic In-Reply-To: <96145F10-A036-4DC4-8A97-9EDF23F8BBCB@oracle.com> References: <96145F10-A036-4DC4-8A97-9EDF23F8BBCB@oracle.com> Message-ID: Looks good. tom On Oct 27, 2010, at 5:25 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6994630/webrev.01/ > > 6994630: java/lang/instrument/IsModifiableClassAgent.java fails with -XX:+EnableInvokeDynamic > Summary: The logic of ClassFileParser::java_dyn_MethodHandle_fix_pre needs to take care of an already changed vmentry signature. > Reviewed-by: > > There is a problem with the logic of > ClassFileParser::java_dyn_MethodHandle_fix_pre. The method searches > for a field called "vmentry" with the signature "byte". The signature > of the field is then changed to vmSymbols::machine_word_signature() to > hold an unmanged pointer. > > When the method is called again the field's signature is already > changed and it throws a VirtualMachineError resulting in a > VerifyError. > > The fix is to also check for the field with the already changed > signature. > > Tested with the failing testcase. > > I also changed the type of the fields argument since we don't update > the field pointer and removed a duplicated comment. > From john.r.rose at oracle.com Wed Oct 27 14:39:17 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 27 Oct 2010 14:39:17 -0700 Subject: Request for reviews (S): 6994630: java/lang/instrument/IsModifiableClassAgent.java fails with -XX:+EnableInvokeDynamic In-Reply-To: <96145F10-A036-4DC4-8A97-9EDF23F8BBCB@oracle.com> References: <96145F10-A036-4DC4-8A97-9EDF23F8BBCB@oracle.com> Message-ID: That's good; thanks. -- John On Oct 27, 2010, at 5:25 AM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/6994630/webrev.01/ > > 6994630: java/lang/instrument/IsModifiableClassAgent.java fails with -XX:+EnableInvokeDynamic > Summary: The logic of ClassFileParser::java_dyn_MethodHandle_fix_pre needs to take care of an already changed vmentry signature. > Reviewed-by: > > There is a problem with the logic of > ClassFileParser::java_dyn_MethodHandle_fix_pre. The method searches > for a field called "vmentry" with the signature "byte". The signature > of the field is then changed to vmSymbols::machine_word_signature() to > hold an unmanged pointer. > > When the method is called again the field's signature is already > changed and it throws a VirtualMachineError resulting in a > VerifyError. > > The fix is to also check for the field with the already changed > signature. > > Tested with the failing testcase. > > I also changed the type of the fields argument since we don't update > the field pointer and removed a duplicated comment. > From Christian.Thalinger at Sun.COM Thu Oct 28 03:33:14 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 28 Oct 2010 10:33:14 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 6994630: java/lang/instrument/IsModifiableClassAgent.java fails with -XX:+EnableInvokeDynamic Message-ID: <20101028103319.C8176474B5@hg.openjdk.java.net> Changeset: d2e35ffae982 Author: twisti Date: 2010-10-28 00:48 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d2e35ffae982 6994630: java/lang/instrument/IsModifiableClassAgent.java fails with -XX:+EnableInvokeDynamic Summary: The logic of ClassFileParser::java_dyn_MethodHandle_fix_pre needs to take care of an already changed vmentry signature. Reviewed-by: never, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp From christian.thalinger at oracle.com Thu Oct 28 04:30:39 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 28 Oct 2010 13:30:39 +0200 Subject: review request (XL): 6981777: implement JSR 292 EG adjustments from summer 2010 In-Reply-To: <0522FD4C-C456-4C60-83AF-5ABC494AF871@oracle.com> References: <0522FD4C-C456-4C60-83AF-5ABC494AF871@oracle.com> Message-ID: On Oct 26, 2010, at 10:39 AM, John Rose wrote: > This is a large set of miscellaneous API adjustments that takes > account of intensive JSR 292 Expert Group work since the JVM > Language Summit and JavaOne. > > http://cr.openjdk.java.net/~jrose/6981777/webrev.01/ src/share/classes/java/dyn/MethodHandles.java: 833 * of {@code Object} arguments and an {@code Object} return type. There is something wrong with this line (accidental paste?). src/share/classes/java/dyn/package-info.java: 90 * The first pair of bytes bytes after the tag must be an index to a {@code CONSTANT_MethodHandle} One bytes too much. 225 * Any {@code varargs} modifier on the bootstrap method is irrelevant, 226 * since is no provision for adapting a bootstrap method with 227 * {@link java.dyn.MethodHandle#asCollector asCollector}. This sounds odd. 330 * or an {@code Object} array of reference to all the arguments (if there are two or more), references? src/share/classes/sun/dyn/CallSiteImpl.java: 66 if (false) // switch when invokeGeneric works Doesn't invokeGeneric work now? src/share/classes/sun/dyn/util/Wrapper.java: 118 /** Does the JVM verifier allow allow a variable of this wrapper's One allow too much. Otherwise looks good. -- Christian From christian.thalinger at oracle.com Thu Oct 28 05:11:47 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 28 Oct 2010 14:11:47 +0200 Subject: preliminary review (L): 6939861: JVM should handle more conversion operations In-Reply-To: References: Message-ID: On Sep 10, 2010, at 10:47 AM, John Rose wrote: > This is the JVM infrastructure for pushing a stack frame *during* a > method handle call, so that some sort of intermediate fixup > operation can be done before completing the call. > > The requirement is that a recognizable stack frame be pushed during > the intermediate fixup operation, so that if there is an exception, > or a GC, or some other stack walk, the stack will be parsed > properly. Crucially, the pending arguments must be recognized as > managed pointers. > > This is a preliminary review, because it shows just the new stack > frame type, rather than the use cases (which are forthcoming). > > 6939861: JVM should handle more conversion operations > http://cr.openjdk.java.net/~jrose/6939861/webrev.00/ src/share/vm/code/codeBlob.cpp: Have you tried to apply this change to a current HotSpot version? CodeBlob does not have instructions_begin/end anymore but content_begin/end or code_begin/end, depends on what you really want. src/share/vm/prims/methodHandles.hpp: + enum { // arg_mask values, used only for TaggedStackInterpreter I removed tagged stack interpreter support as of 6943304. Can we move enum method_handles_platform_dependent_constants from stubRoutines_.hpp to methodHandles_.hpp in this change? I also looked at the methodHandles_x86.cpp changes but it's hard to tell if everything is correct. -- Christian From john.r.rose at Oracle.com Thu Oct 28 11:40:05 2010 From: john.r.rose at Oracle.com (John Rose) Date: Thu, 28 Oct 2010 11:40:05 -0700 Subject: review request (L): 6984311 JSR 292 needs optional bootstrap method parameters Message-ID: <6112D7F4-DD79-4430-A915-602F129E5F1E@oracle.com> 6984311: JSR 292 needs optional bootstrap method parameters http://cr.openjdk.java.net/~jrose/6984311/webrev.02/ This is a rework of an earlier review request. (The subject line mentioned bug 6981777.) The changes are (1) the structure of the CONSTANT_MethodApply node is merged into the CONSTANT_InvokeDynamic node, and (2) the extra-argument structure is N-ary, not binary. Both of these changes reduce the number of constant pool nodes, relative to the binary MethodApply version. (Motivation: This change will support injection of additional metadata parameters at dynamic call sites. A key use is for Java closures, where the additional metadata parameter is a closure body method. There are many other language-specific uses for such metadata. Previously, such metadata had to be mangled into the name, or coded into a unique per-call-site bootstrap method. Both of those older workarounds are significantly more costly in complexity, class file size, and constant pool entry count.) -- John From christian.thalinger at oracle.com Fri Oct 29 04:09:42 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 29 Oct 2010 13:09:42 +0200 Subject: review request (L): 6984311 JSR 292 needs optional bootstrap method parameters In-Reply-To: <6112D7F4-DD79-4430-A915-602F129E5F1E@oracle.com> References: <6112D7F4-DD79-4430-A915-602F129E5F1E@oracle.com> Message-ID: <0EDC451E-6072-40EE-8A4C-DFA5C443BC4E@oracle.com> On Oct 28, 2010, at 8:40 PM, John Rose wrote: > 6984311: JSR 292 needs optional bootstrap method parameters > > http://cr.openjdk.java.net/~jrose/6984311/webrev.02/ > > This is a rework of an earlier review request. (The subject line > mentioned bug 6981777.) > > The changes are (1) the structure of the CONSTANT_MethodApply node > is merged into the CONSTANT_InvokeDynamic node, and (2) the extra- > argument structure is N-ary, not binary. > > Both of these changes reduce the number of constant pool nodes, > relative to the binary MethodApply version. > > (Motivation: This change will support injection of additional > metadata parameters at dynamic call sites. A key use is for Java > closures, where the additional metadata parameter is a closure body > method. There are many other language-specific uses for such > metadata. Previously, such metadata had to be mangled into the > name, or coded into a unique per-call-site bootstrap method. Both > of those older workarounds are significantly more costly in > complexity, class file size, and constant pool entry count.) src/share/vm/oops/constantPoolOop.cpp: 576 // Benign race condition: f1 may already be filled in while we were trying to lock. I guess we don't care here because the exception to be thrown is expected to be the same for different threads, right? 1613 Bytes::put_Java_u2((address) (bytes+5), argc); 1614 for (int arg_i = 0; arg_i < argc; arg_i++) { 1615 int arg = invoke_dynamic_argument_index_at(idx, arg_i); 1616 Bytes::put_Java_u2((address) (bytes+5+2*arg_i), arg); 1617 } Isn't argc here overwritten with the first arg? src/share/vm/utilities/constantTag.cpp: Only the copyright year is changed. Otherwise looks good. -- Christian From vladimir.kozlov at oracle.com Fri Oct 29 12:10:00 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Oct 2010 12:10:00 -0700 Subject: Request for reviews (M): 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. In-Reply-To: <98B06EDE-B138-4389-AF13-DF9E684D0637@oracle.com> References: <4CC2396D.5000701@oracle.com> <98B06EDE-B138-4389-AF13-DF9E684D0637@oracle.com> Message-ID: <4CCB1C08.40109@oracle.com> Thank you, Tom I updated webrev: http://cr.openjdk.java.net/~kvn/6987135/webrev.01 Tom Rodriguez wrote: > On Oct 22, 2010, at 6:25 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/6987135/webrev.00 >> >> Fixed 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. >> >> Changes for 6603011 added the conversion of long >> division by constant to the code with multiply. >> But some modern cpus improved DIV instruction >> performance. Use it for long division by constant >> when it is faster than code with multiply. > > The formats in x86_32.ad don't match the code. Fixed. > In modL_eReg_imm32, why can't the value be 0 or -1? There are Ideal transformations for such divisor values, DivL and ModL will never go to matcher with such divisor. Asserts verify it. > Why don't you use an immL definition that ensures that? If imm is MININT then the pcon calculation will go wrong. Matcher::use_asm_for_ldiv_by_con() has check for MININT. I added verification check into asserts. > > I believe you could do the register declarations like this: I updated both ModL and DivL code to use only dst. Thanks, Vladimir > > + instruct modL_eReg_imm32( eADXRegL dst, eRegL src, immL32 imm, eRegI tmp, eFlagsReg cr ) %{ > + match(Set dst (ModL src imm)); > + effect(TEMP dst, TEMP tmp, KILL cr ); > > to leave the src and tmp unbound which would give the RA a little more freedom. Actually wouldn't connecting src and dst directly result in fewer moves in the normal case? You might need a new temp but it seems like there are quite a few moves of src into dst for the idivl. > > + instruct modL_eReg_imm32( eADXRegL dst, immL32 imm, eSIRegI tmp, eFlagsReg cr ) %{ > + match(Set dst (ModL dst imm)); > + effect( KILL cr ); > > tom > >> Tested on US3, T1, T2, Sparc64, AMD and Intel latest cpus. >> > From vladimir.kozlov at oracle.com Fri Oct 29 17:14:19 2010 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Oct 2010 17:14:19 -0700 Subject: Request for reviews (M): 6987135: Performance regression on Intel platform with 32-bits edition between 6u13 and 6u14. In-Reply-To: <4CCB1C08.40109@oracle.com> References: <4CC2396D.5000701@oracle.com> <98B06EDE-B138-4389-AF13-DF9E684D0637@oracle.com> <4CCB1C08.40109@oracle.com> Message-ID: <4CCB635B.7030708@oracle.com> Tom suggested to use second TEMP register instead of push/pop. Here is new webrev: http://cr.openjdk.java.net/~kvn/6987135/webrev.02 Vladimir Vladimir Kozlov wrote: > Thank you, Tom > > I updated webrev: > > http://cr.openjdk.java.net/~kvn/6987135/webrev.01 > > Tom Rodriguez wrote: >> On Oct 22, 2010, at 6:25 PM, Vladimir Kozlov wrote: >> >>> http://cr.openjdk.java.net/~kvn/6987135/webrev.00 >>> >>> Fixed 6987135: Performance regression on Intel platform with 32-bits >>> edition between 6u13 and 6u14. >>> >>> Changes for 6603011 added the conversion of long >>> division by constant to the code with multiply. >>> But some modern cpus improved DIV instruction >>> performance. Use it for long division by constant >>> when it is faster than code with multiply. >> >> The formats in x86_32.ad don't match the code. > > Fixed. > >> In modL_eReg_imm32, why can't the value be 0 or -1? > > There are Ideal transformations for such divisor values, > DivL and ModL will never go to matcher with such divisor. > Asserts verify it. > >> Why don't you use an immL definition that ensures that? If imm is >> MININT then the pcon calculation will go wrong. > > Matcher::use_asm_for_ldiv_by_con() has check for MININT. > I added verification check into asserts. > >> >> I believe you could do the register declarations like this: > > I updated both ModL and DivL code to use only dst. > > Thanks, > Vladimir > >> >> + instruct modL_eReg_imm32( eADXRegL dst, eRegL src, immL32 imm, eRegI >> tmp, eFlagsReg cr ) %{ >> + match(Set dst (ModL src imm)); >> + effect(TEMP dst, TEMP tmp, KILL cr ); >> >> to leave the src and tmp unbound which would give the RA a little more >> freedom. Actually wouldn't connecting src and dst directly result in >> fewer moves in the normal case? You might need a new temp but it >> seems like there are quite a few moves of src into dst for the idivl. >> >> + instruct modL_eReg_imm32( eADXRegL dst, immL32 imm, eSIRegI tmp, >> eFlagsReg cr ) %{ >> + match(Set dst (ModL dst imm)); >> + effect( KILL cr ); >> >> tom >> >>> Tested on US3, T1, T2, Sparc64, AMD and Intel latest cpus. >>> >> From john.r.rose at oracle.com Sat Oct 30 12:08:52 2010 From: john.r.rose at oracle.com (John Rose) Date: Sat, 30 Oct 2010 12:08:52 -0700 Subject: review request (L): 6984311 JSR 292 needs optional bootstrap method parameters In-Reply-To: <0EDC451E-6072-40EE-8A4C-DFA5C443BC4E@oracle.com> References: <6112D7F4-DD79-4430-A915-602F129E5F1E@oracle.com> <0EDC451E-6072-40EE-8A4C-DFA5C443BC4E@oracle.com> Message-ID: <614316A7-EC07-4C52-A64C-BD97E6AF4E39@oracle.com> On Oct 29, 2010, at 4:09 AM, Christian Thalinger wrote: > On Oct 28, 2010, at 8:40 PM, John Rose wrote: >> 6984311: JSR 292 needs optional bootstrap method parameters >> >> http://cr.openjdk.java.net/~jrose/6984311/webrev.02/ > > src/share/vm/oops/constantPoolOop.cpp: > 576 // Benign race condition: f1 may already be filled in while we were trying to lock. > I guess we don't care here because the exception to be thrown is expected to be the same for different threads, right? Yes. I added more comments: + // Benign race condition: f1 may already be filled in while we were trying to lock. ++ // The important thing here is that all threads pick up the same result. ++ // It doesn't matter which racing thread wins, as long as only one ++ // result is used by all threads, and all future queries. ++ // That result may be either a resolved constant or a failure exception. This matches what is in the javadoc (for the java.dyn package-info): * Every use of this constant pool entry must lead to the same outcome. * If the resolution of the names in the method handle constant causes an exception to occur, * this exception must be recorded by the JVM, and re-thrown on every subsequent attempt * to use this particular constant. > 1613 Bytes::put_Java_u2((address) (bytes+5), argc); > 1614 for (int arg_i = 0; arg_i < argc; arg_i++) { > 1615 int arg = invoke_dynamic_argument_index_at(idx, arg_i); > 1616 Bytes::put_Java_u2((address) (bytes+5+2*arg_i), arg); > 1617 } > Isn't argc here overwritten with the first arg? Right! Changed 5 to 7 on line 1616. Thanks for spotting that. > src/share/vm/utilities/constantTag.cpp: > > Only the copyright year is changed. Fixed. > Otherwise looks good. Thanks. I am updating the webrev: http://cr.openjdk.java.net/~jrose/6984311/webrev.03/ -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20101030/d7457f73/attachment.html From john.r.rose at oracle.com Sat Oct 30 12:20:59 2010 From: john.r.rose at oracle.com (John Rose) Date: Sat, 30 Oct 2010 12:20:59 -0700 Subject: review request (XL): 6981777: implement JSR 292 EG adjustments from summer 2010 In-Reply-To: References: <0522FD4C-C456-4C60-83AF-5ABC494AF871@oracle.com> Message-ID: <69F74C5D-88B1-42AC-AD6D-9882C6DCAF38@oracle.com> Thanks for the review. I will answer it in detail shortly. Here's a related (tiny) review request for JVM code. http://cr.openjdk.java.net/~jrose/6984311/webrev.03/src/share/vm/prims/methodHandles.cpp.udiff.html A tiny JVM bug was uncovered by unit-testing the big JDK changes for 6981777. (It's in the *311 webrev because I thought of rolling it into the fixes for 6984311, but then decided to split it.) -- John On Oct 28, 2010, at 4:30 AM, Christian Thalinger wrote: > On Oct 26, 2010, at 10:39 AM, John Rose wrote: >> This is a large set of miscellaneous API adjustments that takes account of intensive JSR 292 Expert Group work since the JVM Language Summit and JavaOne. >> >> http://cr.openjdk.java.net/~jrose/6981777/webrev.01/ From john.r.rose at oracle.com Sat Oct 30 13:12:50 2010 From: john.r.rose at oracle.com (John Rose) Date: Sat, 30 Oct 2010 13:12:50 -0700 Subject: review request (XL): 6981777: implement JSR 292 EG adjustments from summer 2010 In-Reply-To: References: <0522FD4C-C456-4C60-83AF-5ABC494AF871@oracle.com> Message-ID: On Oct 28, 2010, at 4:30 AM, Christian Thalinger wrote: > On Oct 26, 2010, at 10:39 AM, John Rose wrote: >> This is a large set of miscellaneous API adjustments that takes account of intensive JSR 292 Expert Group work since the JVM Language Summit and JavaOne. >> >> http://cr.openjdk.java.net/~jrose/6981777/webrev.01/ > > src/share/classes/java/dyn/MethodHandles.java: > 833 * of {@code Object} arguments and an {@code Object} return type. > There is something wrong with this line (accidental paste?). A leftover from the previous version of the javadoc. Thanks. > src/share/classes/java/dyn/package-info.java: > 90 * The first pair of bytes bytes after the tag must be an index to a {@code CONSTANT_MethodHandle} > One bytes too much. :-) > 225 * Any {@code varargs} modifier on the bootstrap method is irrelevant, > 226 * since is no provision for adapting a bootstrap method with > 227 * {@link java.dyn.MethodHandle#asCollector asCollector}. > This sounds odd. I broke out the point separately, under the discussion of ldc/MH: * A constant may refer to a method or constructor with the {@code varargs} * bit (hexadecimal {@code 80}) set in its modifier bitmask. * The method handle constant produced for such a method behaves the same * as if the {@code varargs} bit were not set. * The argument-collecting behavior of {@code varargs} can be emulated by * adapting the method handle constant with * {@link java.dyn.MethodHandle#asCollector asCollector}. * There is no provision for doing this automatically. (It's important for users to know that varargs isn't simulated automagically. We could do this, though, with another constant pool entry subtype, to apply the asCollector call. But that's probably for a future version.) > 330 * or an {@code Object} array of reference to all the arguments (if there are two or more), > references? Yes, thanks. > src/share/classes/sun/dyn/CallSiteImpl.java: > > 66 if (false) // switch when invokeGeneric works > Doesn't invokeGeneric work now? I want to shake the bugs out a little more. > src/share/classes/sun/dyn/util/Wrapper.java: > > 118 /** Does the JVM verifier allow allow a variable of this wrapper's > One allow too much. > > Otherwise looks good. Thanks for reading it over carefully. > -- Christian -- John From john.r.rose at oracle.com Sat Oct 30 16:50:41 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 30 Oct 2010 23:50:41 +0000 Subject: hg: jdk7/hotspot-comp/hotspot: 4 new changesets Message-ID: <20101030235048.A5A4647565@hg.openjdk.java.net> Changeset: d1896d1dda3e Author: jrose Date: 2010-10-30 11:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/d1896d1dda3e 6981788: GC map generator sometimes picks up the wrong kind of instruction operand Summary: Distinguish pool indexes from cache indexes in recently changed code. Reviewed-by: never ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp Changeset: fff777a71346 Author: jrose Date: 2010-10-30 11:45 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fff777a71346 6994093: MethodHandle.invokeGeneric needs porting to SPARC Summary: SPARC code missing from fix to 6939224 Reviewed-by: twisti ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp Changeset: 8213b0f5c92d Author: jrose Date: 2010-10-30 12:19 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/8213b0f5c92d 6981777: implement JSR 292 EG adjustments from summer 2010 Summary: Small bug fix to make "raw" adapters work for JDK changes under 6981777 Reviewed-by: twisti ! src/share/vm/prims/methodHandles.cpp Changeset: 3b2dea75431e Author: jrose Date: 2010-10-30 13:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3b2dea75431e 6984311: JSR 292 needs optional bootstrap method parameters Summary: Allow CONSTANT_InvokeDynamic nodes to have any number of extra operands. Reviewed-by: twisti ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/ConstantTag.java ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/includeDB_core ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/prims/methodComparator.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/constantTag.hpp From john.r.rose at oracle.com Sat Oct 30 21:19:03 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 31 Oct 2010 04:19:03 +0000 Subject: hg: jdk7/hotspot-comp/jdk: 2 new changesets Message-ID: <20101031041956.16AAB4756E@hg.openjdk.java.net> Changeset: 19c125efeda3 Author: jrose Date: 2010-10-30 21:02 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/19c125efeda3 6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions Summary: JDK changes which run atop the corresponding JVM hook Reviewed-by: never, twisti ! src/share/classes/java/dyn/MethodHandle.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/BoundMethodHandle.java + src/share/classes/sun/dyn/InvokeGeneric.java ! src/share/classes/sun/dyn/Invokers.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/MethodHandleNatives.java ! src/share/classes/sun/dyn/MethodTypeImpl.java ! src/share/classes/sun/dyn/util/ValueConversions.java + test/java/dyn/InvokeGenericTest.java ! test/java/dyn/MethodHandlesTest.java Changeset: 45f5055dd53f Author: jrose Date: 2010-10-30 21:08 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-comp/jdk/rev/45f5055dd53f 6981777: implement JSR 292 EG adjustments from summer 2010 Reviewed-by: twisti - src/share/classes/java/dyn/BootstrapMethod.java ! src/share/classes/java/dyn/CallSite.java ! src/share/classes/java/dyn/ConstantCallSite.java - src/share/classes/java/dyn/InvokeDynamic.java ! src/share/classes/java/dyn/Linkage.java - src/share/classes/java/dyn/LinkagePermission.java ! src/share/classes/java/dyn/MethodHandle.java - src/share/classes/java/dyn/MethodHandleProvider.java ! src/share/classes/java/dyn/MethodHandles.java ! src/share/classes/java/dyn/MethodType.java + src/share/classes/java/dyn/VolatileCallSite.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/BoundMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FilterOneArgument.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/Invokers.java - src/share/classes/sun/dyn/JavaMethodHandle.java ! src/share/classes/sun/dyn/MethodHandleImpl.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java ! src/share/classes/sun/dyn/util/Wrapper.java ! test/java/dyn/InvokeGenericTest.java - test/java/dyn/JavaDocExamples.java + test/java/dyn/JavaDocExamplesTest.java ! test/java/dyn/MethodHandlesTest.java