From yumin.qi at oracle.com Thu Nov 1 11:06:14 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Thu, 01 Nov 2012 11:06:14 -0700 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: References: <50881EDA.8020100@oracle.com> <50899E09.3050905@oracle.com> <5B1D00DA-989D-4747-8A78-37269D08C722@oracle.com> <508EBE4D.9050903@oracle.com> Message-ID: <5092BA16.1050707@oracle.com> Hi, John and all Please have a look for new webrev http://cr.openjdk.java.net/~minqi/8000489 The new code works fine: new vm with new hsdis and old hsdis, old vm with new hsdis and old hsdis. (Kris, I tested both with -XX:+PrintInterpreter and -XX:+PrintAssembly separately, the output is OK, please let me know if you find new problem with output format) One problem is that SA could not work with old hsdis, the reason is when decode an address, old hsdis read byte from the address. In fact, when SA attached to process or core file, the address is from target process or core file, not an address in SA process itself. When hsdis read memory from this address --- it reads from SA process itself, could not reach out to target space, so the output is wrong. With new hsdis, we copy the bytes from target and pass into hsdis as a buffer, and hsdis read byte from this buffer, but the address value itself is only for print out. With old version hsdis, it will read from SA process. For VM disassemble output, using old version hsdis has no problem, since the address hsdis read is from the process itself as expected. I will file a bug to log this problem but no fix for it since the interface has no more param for this. Thanks Yumin On 10/29/2012 10:47 AM, John Rose wrote: > On Oct 29, 2012, at 10:35 AM, Yumin Qi wrote: > >> I haven't considered new JVM work with old hsdis. Will change >> disassemble.cpp to check: > > Perfect! Thanks, ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121101/57cb5076/attachment.html From krystal.mo at oracle.com Thu Nov 1 12:10:56 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Fri, 02 Nov 2012 03:10:56 +0800 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: <5092BA16.1050707@oracle.com> References: <50881EDA.8020100@oracle.com> <50899E09.3050905@oracle.com> <5B1D00DA-989D-4747-8A78-37269D08C722@oracle.com> <508EBE4D.9050903@oracle.com> <5092BA16.1050707@oracle.com> Message-ID: <5092C940.4020701@oracle.com> Hi Yumin, I just built hsdis with the new patch and dropped it into JDK7u5, and it's still missing newlines. Anyway, it not that bad, at least the disassembly contents are correct. PrintInterpreter log on JDK7u5 ends with: Old hsdis: 0x00007f8ae0e058d9: jmpq *(%r10,%rbx,8) 0x00007f8ae0e058dd: data32 xchg %ax,%ax ---------------------------------------------------------------------- New hsdis: 0x00007f26150208d9: jmpq *(%r10,%rbx,8) 0x00007f26150208dd: data32 xchg %ax,%ax---------------------------------------------------------------------- That's the only place that bothers me (a bit, but not that much). Besides that I'm okay with this patch. And I'm fine with the fact that SA couldn't use old hsdis to do disassembly. Thanks for fixing this! Kris On 11/02/2012 02:06 AM, yumin.qi at oracle.com wrote: > Hi, John and all > > Please have a look for new webrev > http://cr.openjdk.java.net/~minqi/8000489 > > The new code works fine: new vm with new hsdis and old hsdis, old > vm with new hsdis and old hsdis. > > (Kris, I tested both with -XX:+PrintInterpreter and > -XX:+PrintAssembly separately, the output is OK, please let me know if > you find new problem with output format) > > One problem is that SA could not work with old hsdis, the reason is > when decode an address, old hsdis read byte from the address. In fact, > when SA attached to process or core file, the address is from target > process or core file, not an address in SA process itself. When hsdis > read memory from this address --- it reads from SA process itself, > could not reach out to target space, so the output is wrong. With new > hsdis, we copy the bytes from target and pass into hsdis as a buffer, > and hsdis read byte from this buffer, but the address value itself is > only for print out. With old version hsdis, it will read from SA process. > > For VM disassemble output, using old version hsdis has no problem, > since the address hsdis read is from the process itself as expected. > > I will file a bug to log this problem but no fix for it since the > interface has no more param for this. > > Thanks > Yumin > > > > > On 10/29/2012 10:47 AM, John Rose wrote: >> On Oct 29, 2012, at 10:35 AM, Yumin Qi wrote: >> >>> I haven't considered new JVM work with old hsdis. Will change >>> disassemble.cpp to check: >> >> Perfect! Thanks, ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121102/275b6cc2/attachment.html From bharadwaj.yadavalli at oracle.com Thu Nov 1 13:15:02 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 01 Nov 2012 16:15:02 -0400 Subject: RFR (S) - 8001658: No need to pass resolved_references as argument to set_method_handle_common Message-ID: <5092D846.10804@oracle.com> http://cr.openjdk.java.net/~bharadwaj/8001658/webrev_0/ ConstantPoolCacheEntry::set_method_handle_common gets passed in cpool and resolved_references. The latter is not required because it's the same as cpool->resolved_references(). I also reduced the number of arguments to pass to set_method_handle*() and set_dynamic_call() by passing CallInfo. Thanks, Bharadwaj From christian.thalinger at oracle.com Thu Nov 1 15:25:26 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 1 Nov 2012 15:25:26 -0700 Subject: RFR (S) - 8001658: No need to pass resolved_references as argument to set_method_handle_common In-Reply-To: <5092D846.10804@oracle.com> References: <5092D846.10804@oracle.com> Message-ID: <234E811F-E6E4-4DDE-9909-E9B973E53452@oracle.com> Looks good. Thanks for cleaning that up. -- Chris On Nov 1, 2012, at 1:15 PM, Bharadwaj Yadavalli wrote: > http://cr.openjdk.java.net/~bharadwaj/8001658/webrev_0/ > > ConstantPoolCacheEntry::set_method_handle_common gets passed in cpool and resolved_references. > The latter is not required because it's the same as cpool->resolved_references(). I also reduced the number > of arguments to pass to set_method_handle*() and set_dynamic_call() by passing CallInfo. > > Thanks, > > Bharadwaj > From vladimir.kozlov at oracle.com Thu Nov 1 15:56:37 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 01 Nov 2012 15:56:37 -0700 Subject: RFR (S) - 8001658: No need to pass resolved_references as argument to set_method_handle_common In-Reply-To: <234E811F-E6E4-4DDE-9909-E9B973E53452@oracle.com> References: <5092D846.10804@oracle.com> <234E811F-E6E4-4DDE-9909-E9B973E53452@oracle.com> Message-ID: <5092FE25.3090706@oracle.com> Christian, Can you push it? Thanks, Vladimir Christian Thalinger wrote: > Looks good. Thanks for cleaning that up. -- Chris > > On Nov 1, 2012, at 1:15 PM, Bharadwaj Yadavalli wrote: > >> http://cr.openjdk.java.net/~bharadwaj/8001658/webrev_0/ >> >> ConstantPoolCacheEntry::set_method_handle_common gets passed in cpool and resolved_references. >> The latter is not required because it's the same as cpool->resolved_references(). I also reduced the number >> of arguments to pass to set_method_handle*() and set_dynamic_call() by passing CallInfo. >> >> Thanks, >> >> Bharadwaj >> > From christian.thalinger at oracle.com Thu Nov 1 16:11:10 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 1 Nov 2012 16:11:10 -0700 Subject: RFR (S) - 8001658: No need to pass resolved_references as argument to set_method_handle_common In-Reply-To: <5092FE25.3090706@oracle.com> References: <5092D846.10804@oracle.com> <234E811F-E6E4-4DDE-9909-E9B973E53452@oracle.com> <5092FE25.3090706@oracle.com> Message-ID: On Nov 1, 2012, at 3:56 PM, Vladimir Kozlov wrote: > Christian, > > Can you push it? Yes. -- Chris > > Thanks, > Vladimir > > Christian Thalinger wrote: >> Looks good. Thanks for cleaning that up. -- Chris >> On Nov 1, 2012, at 1:15 PM, Bharadwaj Yadavalli wrote: >>> http://cr.openjdk.java.net/~bharadwaj/8001658/webrev_0/ >>> >>> ConstantPoolCacheEntry::set_method_handle_common gets passed in cpool and resolved_references. >>> The latter is not required because it's the same as cpool->resolved_references(). I also reduced the number >>> of arguments to pass to set_method_handle*() and set_dynamic_call() by passing CallInfo. >>> >>> Thanks, >>> >>> Bharadwaj >>> From john.r.rose at oracle.com Thu Nov 1 16:24:15 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 1 Nov 2012 16:24:15 -0700 Subject: RFR: 8000489: older builds of hsdis don't work anymore after 6879063 In-Reply-To: <5092BA16.1050707@oracle.com> References: <50881EDA.8020100@oracle.com> <50899E09.3050905@oracle.com> <5B1D00DA-989D-4747-8A78-37269D08C722@oracle.com> <508EBE4D.9050903@oracle.com> <5092BA16.1050707@oracle.com> Message-ID: <42454084-4B83-48CD-994C-8CB91803CEE0@oracle.com> On Nov 1, 2012, at 11:06 AM, yumin.qi at oracle.com wrote: > Please have a look for new webrev > http://cr.openjdk.java.net/~minqi/8000489 > > The new code works fine: new vm with new hsdis and old hsdis, old vm with new hsdis and old hsdis. Good! ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121101/7dd0d827/attachment.html From john.coomes at oracle.com Thu Nov 1 21:07:54 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Nov 2012 04:07:54 +0000 Subject: hg: hsx/hotspot-comp: 8 new changesets Message-ID: <20121102040755.54F144770A@hg.openjdk.java.net> Changeset: 4bde5640fb36 Author: alanb Date: 2012-10-09 13:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/4bde5640fb36 7173494: some jdk tests are not run in test/Makefile Reviewed-by: chegar, mchung, mduigou, iris ! make/jprt.properties ! test/Makefile Changeset: ce2b111ee869 Author: lana Date: 2012-10-12 14:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/ce2b111ee869 Merge Changeset: 744e165aaf33 Author: lana Date: 2012-10-23 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/744e165aaf33 Merge Changeset: ce212cd7ea69 Author: lana Date: 2012-10-25 20:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/ce212cd7ea69 Merge Changeset: e64f2cb57d05 Author: ohair Date: 2012-10-26 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/e64f2cb57d05 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell ! NewMakefile.gmk ! common/autoconf/autogen.sh ! common/autoconf/basics.m4 + common/autoconf/basics_windows.m4 ! common/autoconf/boot-jdk.m4 ! common/autoconf/build-aux/config.guess ! common/autoconf/build-performance.m4 ! common/autoconf/builddeps.m4 ! common/autoconf/closed.version.numbers ! common/autoconf/compare.sh.in ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/jdk-options.m4 ! common/autoconf/libraries.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 + common/autoconf/toolchain_windows.m4 ! common/autoconf/version.numbers + common/bin/compare.sh + common/bin/compare_exceptions.sh.incl - common/bin/compareimage.sh - common/bin/diffexec.sh - common/bin/diffjarzip.sh - common/bin/difflib.sh - common/bin/difftext.sh - common/bin/exception_list_linux - common/bin/extractvcvars.sh ! common/bin/hide_important_warnings_from_javac.sh ! common/bin/logger.sh + common/bin/shell-tracer.sh - common/bin/unicode2x.sed ! common/makefiles/HotspotWrapper.gmk ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk + common/makefiles/Main.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk ! common/makefiles/RMICompilation.gmk - common/makefiles/compress.post - common/makefiles/compress.pre + common/makefiles/support/ListPathsSafely-post-compress.incl + common/makefiles/support/ListPathsSafely-pre-compress.incl + common/makefiles/support/ListPathsSafely-uncompress.sed + common/makefiles/support/unicode2x.sed - common/makefiles/uncompress.sed + common/src/fixpath.c - common/src/uncygdrive.c + configure Changeset: e3182741ade2 Author: ihse Date: 2012-10-29 14:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/e3182741ade2 8001897: build-infra: misc adjustments to configure script Reviewed-by: ohair ! common/autoconf/Makefile.in ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: 3229597524ca Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/3229597524ca Merge - common/bin/compareimage.sh - common/bin/diffexec.sh - common/bin/diffjarzip.sh - common/bin/difflib.sh - common/bin/difftext.sh - common/bin/exception_list_linux - common/bin/extractvcvars.sh - common/bin/unicode2x.sed - common/makefiles/compress.post - common/makefiles/compress.pre - common/makefiles/uncompress.sed - common/src/uncygdrive.c Changeset: cababb9dfce7 Author: katleman Date: 2012-11-01 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/cababb9dfce7 Added tag jdk8-b63 for changeset 3229597524ca ! .hgtags From john.coomes at oracle.com Thu Nov 1 21:08:00 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Nov 2012 04:08:00 +0000 Subject: hg: hsx/hotspot-comp/corba: 7 new changesets Message-ID: <20121102040806.846DF4770B@hg.openjdk.java.net> Changeset: 679e8ad9874f Author: coffeys Date: 2012-10-09 20:14 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/679e8ad9874f 7196086: update copyright years for files in corba repository (JDK 8) Reviewed-by: lancea ! make/common/Defs-bsd.gmk ! make/common/internal/Resources.gmk ! make/common/shared/Defs-bsd.gmk ! make/common/shared/Defs-utils.gmk ! make/tools/src/build/tools/stripproperties/StripPropertiesCorba.java ! make/tools/strip_properties/Makefile Changeset: 706684c5a058 Author: lana Date: 2012-10-12 14:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/706684c5a058 Merge Changeset: 23e0226a31ac Author: lana Date: 2012-10-23 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/23e0226a31ac Merge Changeset: 9094cd4a614f Author: lana Date: 2012-10-25 20:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/9094cd4a614f Merge ! make/common/shared/Defs-utils.gmk Changeset: de2b8def2be5 Author: ohair Date: 2012-10-26 14:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/de2b8def2be5 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildCorba.gmk ! makefiles/Makefile Changeset: 6ccbf67b68bf Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/6ccbf67b68bf Merge Changeset: b450c07849ab Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/b450c07849ab Added tag jdk8-b63 for changeset 6ccbf67b68bf ! .hgtags From john.coomes at oracle.com Thu Nov 1 21:08:11 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Nov 2012 04:08:11 +0000 Subject: hg: hsx/hotspot-comp/jaxp: 7 new changesets Message-ID: <20121102040834.A71EB4770C@hg.openjdk.java.net> Changeset: 53a2a4893c8f Author: joehw Date: 2012-10-09 14:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/53a2a4893c8f 8000172: 2 SAX features does not work properly Summary: When external dtd is not loaded, skippedEntity event should be reported for entity references. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java Changeset: b545c99e4f5e Author: lana Date: 2012-10-12 14:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/b545c99e4f5e Merge Changeset: 23e1d537224b Author: lana Date: 2012-10-23 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/23e1d537224b Merge Changeset: fc589819b335 Author: lana Date: 2012-10-25 20:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/fc589819b335 Merge Changeset: 121fc928a361 Author: ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/121fc928a361 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJaxp.gmk ! makefiles/Makefile Changeset: 192d8a244bc3 Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/192d8a244bc3 Merge Changeset: 27ab79568c34 Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/27ab79568c34 Added tag jdk8-b63 for changeset 192d8a244bc3 ! .hgtags From john.coomes at oracle.com Thu Nov 1 21:08:39 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Nov 2012 04:08:39 +0000 Subject: hg: hsx/hotspot-comp/jaxws: 3 new changesets Message-ID: <20121102040848.AAAB54770D@hg.openjdk.java.net> Changeset: c30a7cb5c587 Author: ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/c30a7cb5c587 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJaxws.gmk ! makefiles/Makefile Changeset: 86989f702267 Author: katleman Date: 2012-10-31 18:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/86989f702267 Merge Changeset: 5ded18a14bcc Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/5ded18a14bcc Added tag jdk8-b63 for changeset 86989f702267 ! .hgtags From john.coomes at oracle.com Thu Nov 1 21:10:43 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Nov 2012 04:10:43 +0000 Subject: hg: hsx/hotspot-comp/jdk: 83 new changesets Message-ID: <20121102042933.EE0C54770E@hg.openjdk.java.net> Changeset: 117eed515e42 Author: bae Date: 2012-10-23 13:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/117eed515e42 7051394: NullPointerException when running regression tests LoadProfileTest by using openjdk-7-b144 Reviewed-by: jgodinez, prr ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: aeb96dec1c6b Author: lana Date: 2012-10-23 09:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/aeb96dec1c6b Merge Changeset: 93e2669f1ac2 Author: leonidr Date: 2012-10-09 18:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/93e2669f1ac2 7185280: Jre7cert: focusgained does not get called for all focus req when do alt + tab Reviewed-by: anthony ! src/windows/native/sun/windows/awt_Window.cpp Changeset: 527f8eeb8e8d Author: leonidr Date: 2012-10-09 20:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/527f8eeb8e8d 7124321: [macosx] TrayIcon MouseListener is never triggered Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/macosx/native/sun/awt/CTrayIcon.h ! src/macosx/native/sun/awt/CTrayIcon.m Changeset: d4d0327e36e2 Author: kshefov Date: 2012-10-12 18:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d4d0327e36e2 7184326: TEST_BUG: java/awt/Frame/7024749/bug7024749.java has a typo Reviewed-by: anthony ! test/java/awt/Frame/7024749/bug7024749.java Changeset: 34d502d14a61 Author: lana Date: 2012-10-12 14:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/34d502d14a61 Merge - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: f42d178f0452 Author: anthony Date: 2012-10-16 20:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f42d178f0452 6818083: When DISPLAY is bad, InternalError thrown, not AWTError Summary: Throw AWTError instead of InternalError if the DISPLAY is bad Reviewed-by: anthony, serb Contributed-by: Mikhail Cherkasov ! src/solaris/native/sun/awt/awt_GraphicsEnv.c + test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.java + test/java/awt/Toolkit/BadDisplayTest/BadDisplayTest.sh Changeset: 47cdc463b4b0 Author: kizune Date: 2012-10-17 14:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/47cdc463b4b0 7175704: [macosx] "8" PIT: NPE in GetDisplayMode fullscreen test Reviewed-by: serb, leonidr ! src/macosx/classes/sun/awt/CGraphicsDevice.java Changeset: e6a8ee65d248 Author: alexsch Date: 2012-10-17 17:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e6a8ee65d248 8000969: [macosx] Directories are not deselected when JFileChooser has FILES_ONLY selection mode Reviewed-by: rupashka ! src/macosx/classes/com/apple/laf/AquaFileChooserUI.java Changeset: 29b7bd890d3a Author: alexsch Date: 2012-10-17 10:16 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/29b7bd890d3a 8000626: Implement dead key detection for KeyEvent on Linux Reviewed-by: kizune ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h Changeset: 9c6f60a4e996 Author: alexsch Date: 2012-10-18 17:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9c6f60a4e996 7199708: FileChooser crashs when opening large folder Reviewed-by: bagiras ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java Changeset: 8bbc6a5f1e92 Author: alexsch Date: 2012-10-18 18:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8bbc6a5f1e92 7175707: [macosx] PIT: 8 b43 Not running on AppKit thread issue again Reviewed-by: serb, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 6b16f6fc41c5 Author: serb Date: 2012-10-19 15:23 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6b16f6fc41c5 7124520: [macosx] re:6373505 Toolkit.getScreenResolution() != GraphicsConfiguration.getNormalizingTransform() Reviewed-by: anthony, kizune ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java + test/java/awt/GraphicsConfiguration/NormalizingTransformTest/NormalizingTransformTest.java Changeset: e0f91b40b8dd Author: alexsch Date: 2012-10-23 14:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e0f91b40b8dd 6624200: Regression test fails: test/closed/javax/swing/JMenuItem/4654927/bug4654927.java Reviewed-by: rupashka + test/javax/swing/JMenuItem/4654927/bug4654927.java ! test/javax/swing/regtesthelpers/Util.java Changeset: 37a6ead4a357 Author: lana Date: 2012-10-23 09:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/37a6ead4a357 Merge Changeset: fecba6a8b78e Author: coffeys Date: 2012-10-09 12:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fecba6a8b78e 7196533: TimeZone.getDefault() slow due to synchronization bottleneck Reviewed-by: okutsu ! src/share/classes/java/util/TimeZone.java Changeset: 3b79177ebfef Author: alanb Date: 2012-10-09 13:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3b79177ebfef 7173494: some jdk tests are not run in test/Makefile Reviewed-by: chegar, mchung, mduigou, iris ! make/jprt.properties ! test/Makefile ! test/ProblemList.txt Changeset: 036c55976cef Author: lancea Date: 2012-10-09 08:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/036c55976cef 7197395: Add @Deprecated to all deprecated methods to eliminate compiler warnings in JDBC Reviewed-by: alanb, smarks ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/JdbcRowSetImpl.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java Changeset: c725ce4bbf12 Author: naoto Date: 2012-10-09 09:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c725ce4bbf12 7200341: DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some circumstances Reviewed-by: okutsu ! src/share/classes/java/text/DateFormatSymbols.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh ! test/java/util/PluggableLocale/fooprovider.jar ! test/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java Changeset: 71de5e31d497 Author: coffeys Date: 2012-10-09 19:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/71de5e31d497 7181793: Socket getOutputStream create streams that cannot be GC'ed until Socket is closed Reviewed-by: alanb, chegar ! src/share/classes/java/net/AbstractPlainSocketImpl.java + test/java/net/Socket/SocketGrowth.java Changeset: 3c4be36de073 Author: lancea Date: 2012-10-10 11:15 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3c4be36de073 8000687: Correct javadoc typo for getLogWriter and setLogWriter Reviewed-by: alanb ! src/share/classes/java/sql/DriverManager.java Changeset: 6455182d2797 Author: alanb Date: 2012-10-10 20:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6455182d2797 7192274: Deprecate LogManager addPropertyChangeListener and removePropertyChangeLister methods Reviewed-by: mchung, lancea, chegar ! src/share/classes/java/util/logging/LogManager.java Changeset: 734ca9f4719c Author: lancea Date: 2012-10-10 17:34 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/734ca9f4719c 8000712: Remove unused fields in SyncFactory Reviewed-by: mchung ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java Changeset: c2be39b27e1c Author: dxu Date: 2012-10-11 11:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c2be39b27e1c 7186817: Remove Windows 95/98/ME Support Reviewed-by: alanb ! make/java/java/Makefile ! makefiles/CompileNativeLibraries.gmk - src/windows/classes/java/io/Win32FileSystem.java ! src/windows/classes/java/io/WinNTFileSystem.java ! src/windows/native/java/io/FileSystem_md.c - src/windows/native/java/io/Win32FileSystem_md.c ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/lang/ProcessImpl_md.c ! src/windows/native/java/util/TimeZone_md.c ! test/java/io/pathNames/win32/bug6344646.java Changeset: 7c2f5e52863c Author: robm Date: 2012-10-11 18:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7c2f5e52863c 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol] Reviewed-by: alanb, martin, dholmes ! test/java/lang/ProcessBuilder/Basic.java Changeset: daabaafd6798 Author: lancea Date: 2012-10-11 18:46 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/daabaafd6798 8000763: use XXX.valueOf methods instead of constructors Reviewed-by: mchung, forax ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java ! src/share/classes/com/sun/rowset/FilteredRowSetImpl.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java Changeset: e23f8e0a1d89 Author: lana Date: 2012-10-12 14:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e23f8e0a1d89 Merge Changeset: ff641c5b329b Author: jgish Date: 2012-10-13 10:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ff641c5b329b 7146552: java/util/logging/LoggingMXBeanTest.java failing intermittently Reviewed-by: alanb, mchung ! test/java/util/logging/LoggingMXBeanTest.java ! test/java/util/logging/LoggingMXBeanTest2.java Changeset: fe28e0b035e7 Author: sflores Date: 2012-10-14 22:58 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/fe28e0b035e7 7194449: String resources for Key Tool and Policy Tool should be in their respective packages Reviewed-by: alanb, weijun, mullan ! make/common/Release.gmk ! make/launchers/Makefile ! make/sun/security/tools/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/tools/KeyStoreUtil.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java + src/share/classes/sun/security/tools/jarsigner/Main.java + src/share/classes/sun/security/tools/jarsigner/Resources.java + src/share/classes/sun/security/tools/jarsigner/Resources_ja.java + src/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java + src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java + src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java + src/share/classes/sun/security/tools/keytool/Main.java + src/share/classes/sun/security/tools/keytool/Resources.java + src/share/classes/sun/security/tools/keytool/Resources_de.java + src/share/classes/sun/security/tools/keytool/Resources_es.java + src/share/classes/sun/security/tools/keytool/Resources_fr.java + src/share/classes/sun/security/tools/keytool/Resources_it.java + src/share/classes/sun/security/tools/keytool/Resources_ja.java + src/share/classes/sun/security/tools/keytool/Resources_ko.java + src/share/classes/sun/security/tools/keytool/Resources_pt_BR.java + src/share/classes/sun/security/tools/keytool/Resources_sv.java + src/share/classes/sun/security/tools/keytool/Resources_zh_CN.java + src/share/classes/sun/security/tools/keytool/Resources_zh_HK.java + src/share/classes/sun/security/tools/keytool/Resources_zh_TW.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java + src/share/classes/sun/security/tools/policytool/Resources.java + src/share/classes/sun/security/tools/policytool/Resources_de.java + src/share/classes/sun/security/tools/policytool/Resources_es.java + src/share/classes/sun/security/tools/policytool/Resources_fr.java + src/share/classes/sun/security/tools/policytool/Resources_it.java + src/share/classes/sun/security/tools/policytool/Resources_ja.java + src/share/classes/sun/security/tools/policytool/Resources_ko.java + src/share/classes/sun/security/tools/policytool/Resources_pt_BR.java + src/share/classes/sun/security/tools/policytool/Resources_sv.java + src/share/classes/sun/security/tools/policytool/Resources_zh_CN.java + src/share/classes/sun/security/tools/policytool/Resources_zh_HK.java + src/share/classes/sun/security/tools/policytool/Resources_zh_TW.java ! src/share/classes/sun/security/util/Resources.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_ja.java ! src/share/classes/sun/security/util/Resources_ko.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/util/Resources_sv.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/tools/jarsigner/JarSigningNonAscii.java ! test/sun/security/tools/jarsigner/LargeJarEntry.java ! test/sun/security/tools/keytool/CloseFile.java ! test/sun/security/tools/keytool/KeyToolTest.java ! test/sun/security/tools/keytool/NewSize7.java ! test/sun/security/tools/keytool/StartDateTest.java ! test/sun/security/tools/keytool/UnknownAndUnparseable.java ! test/sun/security/tools/keytool/autotest.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/util/Resources/Format.java ! test/sun/security/util/Resources/NewNamesFormat.java ! test/sun/security/util/Resources/NewResourcesNames.java ! test/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 7055257a25c4 Author: robm Date: 2012-10-15 03:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7055257a25c4 8000817: Reinstate accidentally removed sleep() from ProcessBuilder/Basic.java Reviewed-by: alanb, martin ! test/java/lang/ProcessBuilder/Basic.java Changeset: c0736b62160e Author: robm Date: 2012-10-15 22:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c0736b62160e 8000487: Java JNDI connection library on ldap conn is not honoring configured timeout Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi/ldap/LdapClient.java + test/com/sun/jndi/ldap/LdapTimeoutTest.java - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 32452042b781 Author: naoto Date: 2012-10-16 10:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/32452042b781 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) doesn't work as expected with custom extensions 8000273: java.util.Locale.getDisplayVariant(Locale l) isn't transferred to the custom service provider 8000615: JRE adapter: timezone name of en_US is changed when extension directory is added Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.sh ! test/java/util/PluggableLocale/ProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java Changeset: 3a6b76a468bd Author: khazra Date: 2012-10-16 15:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3a6b76a468bd 7198073: (prefs) user prefs not saved [macosx] Summary: Using class member field to get node instead of argument Reviewed-by: alanb ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java + test/java/util/prefs/CheckUserPrefFirst.java + test/java/util/prefs/CheckUserPrefLater.java + test/java/util/prefs/CheckUserPrefsStorage.sh Changeset: 14b9e294d049 Author: alanb Date: 2012-10-17 11:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/14b9e294d049 8000685: (props) Properties.storeToXML/loadFromXML should only require UTF-8 and UTF-16 to be supported Reviewed-by: mchung, chegar ! src/share/classes/java/util/Properties.java ! src/share/classes/sun/util/spi/XmlPropertiesProvider.java ! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java ! test/java/util/Properties/LoadAndStoreXML.java Changeset: 5eed4a92ca8c Author: ngmr Date: 2012-10-17 13:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5eed4a92ca8c 8000955: Hashtable.Entry.hashCode() does not conform to Map.Entry.hashCode() defined behaviour Reviewed-by: mduigou, alanb ! src/share/classes/java/util/Hashtable.java + test/java/util/Map/EntryHashCode.java Changeset: b2d8a99a049e Author: dsamersoff Date: 2012-10-17 18:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b2d8a99a049e 6809322: javax.management.timer.Timer does not fire all notifications Summary: Some notifications get dropped due to ConcurrentModificationException thrown in Timer.notifyAlarmClock() method. Reviewed-by: dholmes, rbackman Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/timer/Timer.java + test/javax/management/timer/MissingNotificationTest.java Changeset: 6156b9235758 Author: mchung Date: 2012-10-17 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6156b9235758 8001012: jdk8 SKIP_BUILD_CYCLE=false build fails with BUILD_JAXWS=false Reviewed-by: alanb, ohair ! make/common/internal/Defs-jaxws.gmk Changeset: 586028bbf885 Author: psandoz Date: 2012-10-17 20:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/586028bbf885 7198496: (sl) ServiceLoader.load(Class, null) behavior differs from spec Reviewed-by: dholmes, alanb ! src/share/classes/java/util/ServiceLoader.java ! test/java/util/ServiceLoader/Basic.java ! test/java/util/ServiceLoader/basic.sh Changeset: b265ead7f331 Author: alanb Date: 2012-10-17 21:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b265ead7f331 8000362: (pack200) Deprecate Packer/Unpacker addPropertyChangeLister and removePropertyChangeListener methods Reviewed-by: lancea, chegar, mchung, ksrini ! src/share/classes/java/util/jar/Pack200.java Changeset: 60994591be6b Author: naoto Date: 2012-10-17 13:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/60994591be6b 8001046: java/util/PluggableLocale/LocaleNameProviderTest.sh failing Reviewed-by: okutsu ! test/java/util/PluggableLocale/barprovider.jar Changeset: 3f62cfc4e83d Author: xuelei Date: 2012-10-18 01:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3f62cfc4e83d 7068321: Support TLS Server Name Indication (SNI) Extension in JSSE Server Reviewed-by: mullan, weijun, wetmore ! src/share/classes/javax/net/ssl/ExtendedSSLSession.java ! src/share/classes/javax/net/ssl/HandshakeCompletedEvent.java + src/share/classes/javax/net/ssl/SNIHostName.java + src/share/classes/javax/net/ssl/SNIMatcher.java + src/share/classes/javax/net/ssl/SNIServerName.java ! src/share/classes/javax/net/ssl/SSLEngine.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLServerSocket.java ! src/share/classes/javax/net/ssl/SSLSocket.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java + src/share/classes/javax/net/ssl/StandardConstants.java ! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SunJSSE.java + src/share/classes/sun/security/ssl/Utilities.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/LargePacket.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/SSLEngineService.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorer.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerUnmatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithCli.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorerWithSrv.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketConsistentSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorer.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerFailure.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerMatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerUnmatchedSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithCliSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorerWithSrvSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketInconsistentSNI.java + test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java + test/sun/security/ssl/templates/SSLCapabilities.java + test/sun/security/ssl/templates/SSLExplorer.java Changeset: 27f854a1e5c5 Author: chegar Date: 2012-10-19 11:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/27f854a1e5c5 8000206: Uninitialized variable in PlainDatagramSocketImpl.c Reviewed-by: dsamersoff, khazra, chegar Contributed-by: John Zavgren ! src/solaris/native/java/net/PlainDatagramSocketImpl.c Changeset: 21f1b88e68ce Author: xuelei Date: 2012-10-19 20:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/21f1b88e68ce 8000954: Add final keyword to new method in SSLParameters Reviewed-by: wetmore ! src/share/classes/javax/net/ssl/SSLParameters.java Changeset: 93303f8a4a8e Author: alanb Date: 2012-10-20 21:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/93303f8a4a8e 8000941: Remove ftp from the required list of protocol handlers Reviewed-by: chegar ! src/share/classes/java/net/ProxySelector.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLStreamHandler.java ! src/share/classes/java/net/package.html Changeset: a40b0f51613b Author: jjh Date: 2012-10-20 22:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a40b0f51613b 7197401: Add a subset of the org.objectweb.asm packages to jdk8 Reviewed-by: ohair, briangoetz, erikj, iris ! THIRD_PARTY_README ! make/Makefile + make/jdk/Makefile + make/jdk/asm/Makefile + src/share/classes/jdk/internal/org/objectweb/asm/AnnotationVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/AnnotationWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Attribute.java + src/share/classes/jdk/internal/org/objectweb/asm/ByteVector.java + src/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java + src/share/classes/jdk/internal/org/objectweb/asm/ClassVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/ClassWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Edge.java + src/share/classes/jdk/internal/org/objectweb/asm/FieldVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/FieldWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Frame.java + src/share/classes/jdk/internal/org/objectweb/asm/Handle.java + src/share/classes/jdk/internal/org/objectweb/asm/Handler.java + src/share/classes/jdk/internal/org/objectweb/asm/Item.java + src/share/classes/jdk/internal/org/objectweb/asm/Label.java + src/share/classes/jdk/internal/org/objectweb/asm/MethodVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/MethodWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java + src/share/classes/jdk/internal/org/objectweb/asm/Type.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/AnalyzerAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/CodeSizeEvaluator.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/GeneratorAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/InstructionAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/JSRInlinerAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/LocalVariablesSorter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/Method.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/Remapper.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingAnnotationAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingClassAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingFieldAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingMethodAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/RemappingSignatureAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/SerialVersionUIDAdder.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/SimpleRemapper.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/StaticInitMerger.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/TableSwitchGenerator.java + src/share/classes/jdk/internal/org/objectweb/asm/commons/TryCatchBlockSorter.java + src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureReader.java + src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/signature/SignatureWriter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/AbstractInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/AnnotationNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/ClassNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/FieldNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/FrameNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/IincInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InnerClassNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnList.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/IntInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/InvokeDynamicInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/JumpInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LabelNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LdcInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LineNumberNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LocalVariableNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/LookupSwitchInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/MethodNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/MultiANewArrayInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TableSwitchInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TryCatchBlockNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/TypeInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/VarInsnNode.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Analyzer.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/AnalyzerException.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicInterpreter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicValue.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/BasicVerifier.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Frame.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Interpreter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SimpleVerifier.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SmallSet.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceInterpreter.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SourceValue.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Subroutine.java + src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/Value.java + src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifiable.java + src/share/classes/jdk/internal/org/objectweb/asm/util/ASMifier.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckAnnotationAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckClassAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckFieldAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckMethodAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/CheckSignatureAdapter.java + src/share/classes/jdk/internal/org/objectweb/asm/util/Printer.java + src/share/classes/jdk/internal/org/objectweb/asm/util/Textifiable.java + src/share/classes/jdk/internal/org/objectweb/asm/util/Textifier.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceAnnotationVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceClassVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceFieldVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceMethodVisitor.java + src/share/classes/jdk/internal/org/objectweb/asm/util/TraceSignatureVisitor.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/Makefile + test/jdk/asm/AsmSanity.java Changeset: b39ab9c6f4cb Author: weijun Date: 2012-10-22 09:59 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b39ab9c6f4cb 8001204: typo: Unable to obtain Princpal Name for authentication Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java Changeset: e19dc885da0d Author: weijun Date: 2012-10-22 17:01 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e19dc885da0d 8000624: Move MaxRetries.java to ProblemList for the moment Reviewed-by: alanb ! test/ProblemList.txt Changeset: 2048ce5a12ff Author: twisti Date: 2012-10-22 14:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2048ce5a12ff 6771058: TEST_BUG: java/lang/ref/Basic.java may fail with -server -Xcomp Reviewed-by: dholmes, mchung ! test/java/lang/ref/Basic.java Changeset: a1e77f7ed52b Author: weijun Date: 2012-10-23 10:02 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a1e77f7ed52b 8001208: Fix for KRB5CCNAME not complete Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! test/sun/security/krb5/ccache/EmptyCC.java Changeset: 29b58cb8e4fc Author: chegar Date: 2012-10-23 11:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/29b58cb8e4fc 8000204: Memory leak in com/sun/security/auth/module/Unix.c Reviewed-by: dsamersoff, wetmore, khazra, chegar Contributed-by: John Zavgren ! src/solaris/native/com/sun/security/auth/module/Unix.c Changeset: cdc7f9be3707 Author: lana Date: 2012-10-23 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cdc7f9be3707 Merge - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 0582dc4674c9 Author: wetmore Date: 2012-05-21 15:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0582dc4674c9 7167656: Multiple Seeders are being created Reviewed-by: smarks, mduigou, ahgross ! src/share/classes/sun/security/provider/SecureRandom.java Changeset: b4f35876d9b5 Author: mullan Date: 2012-06-08 11:02 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b4f35876d9b5 7163198: Tightened package accessibility 7169887: Tightened package accessibility Reviewed-by: vinnie, hawtin ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 89a0551b98d8 Author: weijun Date: 2012-06-15 09:51 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/89a0551b98d8 6631398: FilePermission improved path checking Reviewed-by: mullan, skoivu, jdn ! src/share/classes/java/io/FilePermission.java Changeset: 7439e8007e09 Author: mullan Date: 2012-06-18 10:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7439e8007e09 7172522: Improve DomainCombiner checking Reviewed-by: vinnie, ahgross ! src/share/classes/java/security/AccessController.java Changeset: 2a98c51549a8 Author: smarks Date: 2012-06-21 00:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2a98c51549a8 7093490: adjust package access in rmiregistry Reviewed-by: ahgross, coffeys, dmocek ! src/share/classes/sun/rmi/registry/RegistryImpl.java Changeset: 263f15439f4b Author: dsamersoff Date: 2012-06-22 16:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/263f15439f4b 7158796: Tighten properties checking in EnvHelp Summary: Move getProperty call out of computeBooleanFromString Reviewed-by: skoivu, sla ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java Changeset: 3a825f6cbc71 Author: dsamersoff Date: 2012-06-22 18:19 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3a825f6cbc71 7169888: Narrowing resource definitions in JMX RMI connector Summary: CPU bug, we can't put offending calls outside doPrivileged, but narrow granted permissions. Reviewed-by: ahgross, fparain ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java Changeset: 90498c1cc87c Author: xuelei Date: 2012-07-28 19:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/90498c1cc87c 7186286: TLS implementation to better adhere to RFC Summary: also reviewed by Alexander Fomin , Andrew Gross, Sean Coffey Reviewed-by: valeriep, wetmore ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java Changeset: 983c17aecdac Author: mullan Date: 2012-08-15 15:31 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/983c17aecdac 7189490: More improvements to DomainCombiner checking Reviewed-by: ahgross, jdn, vinnie ! src/share/classes/java/security/AccessController.java Changeset: 6cc28cc213b6 Author: chegar Date: 2012-08-16 15:02 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6cc28cc213b6 7189103: Executors needs to maintain state Reviewed-by: dholmes, hawtin ! src/share/classes/java/util/concurrent/Executors.java Changeset: a09b9ebb61b6 Author: chegar Date: 2012-08-29 14:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a09b9ebb61b6 7189567: java net obselete protocol Reviewed-by: alanb, ahgross ! make/sun/net/FILES_java.gmk - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java ! test/java/net/URL/Test.java Changeset: 2ac636f46c5b Author: alanb Date: 2012-09-08 20:31 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2ac636f46c5b 7169884: LogManager checks do not work correctly for sub-types Reviewed-by: mchung, ahgross ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/StreamHandler.java Changeset: 4488ea026532 Author: asaha Date: 2012-09-08 22:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4488ea026532 Merge Changeset: e869a8513cb7 Author: smarks Date: 2012-09-10 16:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e869a8513cb7 7195919: (sl) ServiceLoader can throw CCE without needing to create instance Reviewed-by: ahgross, alanb, dmeetry ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/sun/misc/Service.java Changeset: 9a7e2fa3c9c5 Author: malenkov Date: 2012-09-11 12:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9a7e2fa3c9c5 7195549: Better bean object persistence Reviewed-by: art, ahgross ! src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java Changeset: 1d1fcf0c1ce8 Author: rupashka Date: 2012-09-11 15:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1d1fcf0c1ce8 7195194: Better data validation for Swing Reviewed-by: art, ahgross ! src/share/classes/javax/swing/text/DefaultFormatter.java Changeset: 3b49bd3c392b Author: malenkov Date: 2012-09-19 21:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3b49bd3c392b 7195917: XMLDecoder parsing at close-time should be improved Reviewed-by: art, ahgross ! src/share/classes/com/sun/beans/decoder/DocumentHandler.java ! src/share/classes/java/beans/XMLDecoder.java Changeset: 762eee5e6e16 Author: jrose Date: 2012-09-20 14:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/762eee5e6e16 7196190: Improve method of handling MethodHandles Summary: Bind callers to caller-sensitive methods. Reviewed-by: twisti, jjh, vlivanov, ahgross ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/anon/AnonymousClassLoader.java ! src/share/classes/sun/invoke/util/ValueConversions.java + test/java/lang/invoke/7196190/ClassForNameTest.java + test/java/lang/invoke/7196190/GetUnsafeTest.java + test/java/lang/invoke/7196190/MHProxyTest.java + test/java/lang/invoke/7196190/jtreg.security.policy Changeset: e113ffde452a Author: dsamersoff Date: 2012-09-24 16:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e113ffde452a 7198296: Problem with classloader in JMX Summary: wb classes have to be available for hotspot tests Reviewed-by: ahgross, asaha Contributed-by: frederic.parain at oracle.com, daniel.fuchs at oracle.com, jean-francois.denise at oracle.com ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java Changeset: ca79b33a0731 Author: dsamersoff Date: 2012-09-24 17:00 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ca79b33a0731 7192975: Issue with JMX reflection Summary: Make security check unconditional Reviewed-by: ahgross, asaha Contributed-by: jaroslav.bachorik at oracle.com ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java Changeset: 74eec13c464e Author: asaha Date: 2012-09-25 11:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/74eec13c464e Merge - make/common/Defs-embedded.gmk - make/common/Release-embedded.gmk Changeset: e4ce54b79bb4 Author: asaha Date: 2012-10-10 14:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e4ce54b79bb4 Merge - src/macosx/classes/sun/awt/SunToolkitSubclass.java ! src/share/classes/java/io/FilePermission.java - src/share/classes/sun/management/LockDataConverter.java - src/share/classes/sun/management/LockDataConverterMXBean.java - src/share/classes/sun/security/x509/CertificateIssuerUniqueIdentity.java - src/share/classes/sun/security/x509/CertificateSubjectUniqueIdentity.java - test/sun/misc/URLClassPath/ClassnameCharTest.sh - test/sun/net/www/httptest/HttpServer.java - test/sun/security/ssl/sun/net/www/httpstest/HttpServer.java Changeset: 28fe37b50e3c Author: asaha Date: 2012-10-11 15:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/28fe37b50e3c Merge Changeset: d3b3fea7d1d7 Author: asaha Date: 2012-10-18 22:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d3b3fea7d1d7 Merge ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/util/ServiceLoader.java - src/share/classes/sun/util/xml/XMLUtils.java - src/share/test/pack200/pack.conf Changeset: e6fbbb2c610d Author: lana Date: 2012-10-23 11:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e6fbbb2c610d Merge ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/logging/LogManager.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: dfd509da3da6 Author: lana Date: 2012-10-25 20:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/dfd509da3da6 Merge ! make/common/Release.gmk ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/java/lang/invoke/MethodHandleStatics.java ! src/share/classes/sun/invoke/util/ValueConversions.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c ! test/ProblemList.txt - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 64dd2aba6d33 Author: ohair Date: 2012-10-26 14:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/64dd2aba6d33 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildJdk.gmk + makefiles/Bundles.gmk ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataFontConfig.gmk ! makefiles/GendataHtml32dtd.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateJavaSources.gmk ! makefiles/GensrcBuffer.gmk ! makefiles/GensrcCLDR.gmk ! makefiles/GensrcCharacterData.gmk ! makefiles/GensrcCharsetCoder.gmk ! makefiles/GensrcCharsetMapping.gmk ! makefiles/GensrcExceptions.gmk ! makefiles/GensrcIcons.gmk ! makefiles/GensrcJDWP.gmk ! makefiles/GensrcJObjC.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcSwing.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk ! makefiles/Makefile ! makefiles/Tools.gmk - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 + makefiles/sun/awt/X11/ToBin.java + makefiles/sun/osxapp/ToBin.java - makefiles/sun/xawt/ToBin.java Changeset: 5b29d6157504 Author: erikj Date: 2012-10-29 13:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5b29d6157504 8001887: build-infra: Correct mapfiles in build-infra area Reviewed-by: ohair ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris Changeset: dcee387cde81 Author: ohrstrom Date: 2012-10-29 13:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/dcee387cde81 8001891: build-infra: Adding X_CFLAGS and X_LIBS to lwawt and sizer compilation Reviewed-by: ohair ! makefiles/CompileNativeLibraries.gmk ! makefiles/GensrcX11Wrappers.gmk Changeset: 524d1a705f7b Author: erikj Date: 2012-10-29 13:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/524d1a705f7b 8001898: build-infra: correct exclusion lists for mac jar builds 8001896: build-infra: UNLIMITED_CRYPTO changes Reviewed-by: ohair ! makefiles/CreateJars.gmk Changeset: f117a3e06f78 Author: katleman Date: 2012-10-31 18:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f117a3e06f78 Merge ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java Changeset: 7ac292e57b5a Author: katleman Date: 2012-11-01 14:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7ac292e57b5a Added tag jdk8-b63 for changeset f117a3e06f78 ! .hgtags From john.coomes at oracle.com Thu Nov 1 21:35:27 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 02 Nov 2012 04:35:27 +0000 Subject: hg: hsx/hotspot-comp/langtools: 15 new changesets Message-ID: <20121102043601.4AA0247711@hg.openjdk.java.net> Changeset: c75be5bc5283 Author: jjg Date: 2012-10-09 19:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c75be5bc5283 8000663: clean up langtools imports Reviewed-by: darcy ! src/share/classes/com/sun/source/tree/CompilationUnitTree.java ! src/share/classes/com/sun/source/tree/Scope.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TreePath.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/api/WrappingJavaFileManager.java ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java ! src/share/classes/javax/annotation/processing/Completions.java ! src/share/classes/javax/annotation/processing/FilerException.java ! src/share/classes/javax/annotation/processing/ProcessingEnvironment.java ! src/share/classes/javax/lang/model/element/AnnotationValue.java ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/element/VariableElement.java ! src/share/classes/javax/lang/model/type/MirroredTypeException.java ! src/share/classes/javax/lang/model/type/MirroredTypesException.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor8.java ! src/share/classes/javax/lang/model/util/ElementFilter.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! src/share/classes/javax/lang/model/util/ElementScanner6.java ! src/share/classes/javax/lang/model/util/ElementScanner7.java ! src/share/classes/javax/lang/model/util/ElementScanner8.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor8.java ! src/share/classes/javax/tools/ForwardingJavaFileManager.java ! src/share/classes/javax/tools/JavaFileObject.java Changeset: fc123bdeddb8 Author: jjg Date: 2012-10-09 19:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/fc123bdeddb8 8000208: fix langtools javadoc comment issues Reviewed-by: bpatel, mcimadamore ! src/share/classes/com/sun/javadoc/Tag.java ! src/share/classes/com/sun/tools/classfile/BootstrapMethods_attribute.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Locations.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/nio/PathFileManager.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/ServiceProxy.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Position.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/ModifierFilter.java ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java ! src/share/classes/com/sun/tools/javah/NativeHeaderTool.java ! src/share/classes/com/sun/tools/javap/DisassemblerTool.java Changeset: 25e14ad23cef Author: jjg Date: 2012-10-10 16:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/25e14ad23cef 8000665: fix "internal API" comments on javadoc files Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlAttr.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlConstants.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeOptionalMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstructorWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/FieldWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MethodWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/NestedClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/WriterFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/XMLNode.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseExecutableMemberTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseInlineTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/BaseTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/CodeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DeprecatedTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/DocRootTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritableTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LegacyTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ParamTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ReturnTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SeeTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/SimpleTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletOutput.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ThrowsTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassDocCatalog.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/CommentedMethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DeprecatedAPIListBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Group.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ImplementedMethods.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/IndexBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MetaKeywords.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/TaggedMethodFinder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/TextTag.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/VisibleMemberMap.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkOutput.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationTypeElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/ConstructorDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocTodo.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Main.java ! src/share/classes/com/sun/tools/javadoc/MemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ModifierFilter.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerialFieldTagImpl.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/TagImpl.java ! src/share/classes/com/sun/tools/javadoc/ThrowsTagImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javadoc/WildcardTypeImpl.java Changeset: 560d4a5d14e6 Author: jjg Date: 2012-10-10 18:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/560d4a5d14e6 8000743: docencoding not available to stylesheet Reviewed-by: jjg Contributed-by: jviswana at linux.vnet.ibm.com ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java + test/com/sun/javadoc/testDocEncoding/TestDocEncoding.java + test/com/sun/javadoc/testDocEncoding/pkg/Test.java Changeset: 6517bf8e50d0 Author: jjg Date: 2012-10-10 18:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/6517bf8e50d0 8000418: javadoc should used a standard "generated by javadoc" string Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! test/com/sun/javadoc/VersionNumber/VersionNumber.java + test/com/sun/javadoc/testGeneratedBy/TestGeneratedBy.java + test/com/sun/javadoc/testGeneratedBy/pkg/MyClass.java Changeset: c46e0c9940d6 Author: jjg Date: 2012-10-10 18:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c46e0c9940d6 8000310: Clean up use of StringBuffer in langtools Reviewed-by: bpatel ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/LiteralTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/util/Convert.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Mangle.java Changeset: 0d1818e9d4ae Author: lana Date: 2012-10-12 14:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/0d1818e9d4ae Merge Changeset: 8db45b13526e Author: jjg Date: 2012-10-15 17:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/8db45b13526e 8000666: javadoc should write directly to Writer instead of composing strings Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: 2013982bee34 Author: jjg Date: 2012-10-16 21:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2013982bee34 8000673: remove dead code from HtmlWriter and subtypes Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java Changeset: 12cf6bfd8c05 Author: mcimadamore Date: 2012-10-17 16:43 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/12cf6bfd8c05 7192245: Add parser support for default methods Summary: Add support for 'default' keyword in modifier position Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java + test/tools/javac/diags/examples/DefaultMethodNotSupported.java Changeset: 5dde04b8bbb3 Author: lana Date: 2012-10-23 09:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/5dde04b8bbb3 Merge Changeset: 669468143a5e Author: lana Date: 2012-10-25 20:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/669468143a5e Merge Changeset: 741cce355ba6 Author: ohair Date: 2012-10-26 14:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/741cce355ba6 8000992: Update new build-infra makefiles Summary: Build-infra project integration. Multiple authors on this work: erikj and ihse primarily, also changes from ohair, tbell, and dholmes. Special credit to ohstrom for his smartjavac work. Reviewed-by: erikj, ihse, dholmes, tbell + makefiles/BuildLangtools.gmk ! makefiles/Makefile Changeset: 92e6f2190ca0 Author: katleman Date: 2012-10-31 18:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/92e6f2190ca0 Merge Changeset: 26831b6fcc4a Author: katleman Date: 2012-11-01 14:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/26831b6fcc4a Added tag jdk8-b63 for changeset 92e6f2190ca0 ! .hgtags From bharadwaj.yadavalli at oracle.com Fri Nov 2 07:21:58 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 02 Nov 2012 10:21:58 -0400 Subject: RFR (S) - 8001658: No need to pass resolved_references as argument to set_method_handle_common In-Reply-To: References: <5092D846.10804@oracle.com> <234E811F-E6E4-4DDE-9909-E9B973E53452@oracle.com> <5092FE25.3090706@oracle.com> Message-ID: <5093D706.7030101@oracle.com> Thanks for the reviews and for help with pushing the changes. Bharadwaj On 11/1/2012 7:11 PM, Christian Thalinger wrote: > On Nov 1, 2012, at 3:56 PM, Vladimir Kozlov wrote: > >> Christian, >> >> Can you push it? > Yes. -- Chris > >> Thanks, >> Vladimir >> >> Christian Thalinger wrote: >>> Looks good. Thanks for cleaning that up. -- Chris >>> On Nov 1, 2012, at 1:15 PM, Bharadwaj Yadavalli wrote: >>>> http://cr.openjdk.java.net/~bharadwaj/8001658/webrev_0/ >>>> >>>> ConstantPoolCacheEntry::set_method_handle_common gets passed in cpool and resolved_references. >>>> The latter is not required because it's the same as cpool->resolved_references(). I also reduced the number >>>> of arguments to pass to set_method_handle*() and set_dynamic_call() by passing CallInfo. >>>> >>>> Thanks, >>>> >>>> Bharadwaj >>>> From martin.doerr at sap.com Fri Nov 2 09:38:21 2012 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 2 Nov 2012 16:38:21 +0000 Subject: Critical JNI Native method lookup and thread state Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165606BB0A5F@DEWDFEMB13A.global.corp.sap> Hi everybody, I have a question about the thread state during lookup of Critical JNI Native methods (in NativeLookup::lookup_critical_style). What I observed is that the native lookup gets called via SharedRuntime::resolve_static_call_C and generate_native_wrapper and it seems like we are all the way in state "_thread_in_vm". This might be expected. However, a call to os::dll_load might take some time due to IO. So I would expect a transition to state "_thread_in_native" to avoid safepoint issues, but I didn't find such a transition. Did I miss anything or is it intended to go all the way in state "_thread_in_vm"? Or at which place should we transition to "_thread_in_native"? Kind regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121102/f6c93226/attachment.html From martin.doerr at sap.com Fri Nov 2 09:38:43 2012 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 2 Nov 2012 16:38:43 +0000 Subject: Problem with CHECK_NULL macro in return statements Message-ID: <7C9B87B351A4BA4AA9EC95BB4181165606BB0A68@DEWDFEMB13A.global.corp.sap> Hello everybody, I found many places at which the CHECK_NULL macro gets used in a return statement like the following one: return the_table()->basic_add(index, (u1*)buffer, len, hashValue, true, CHECK_NULL); However, this does not work as one would usually expect. The macro gets expanded to: __the_thread__); if ((((ThreadShadow*)__the_thread__)->has_pending_exception())) return NULL; (0 The return statement above prevents the code after "__the_thread__);" from ever getting evaluated. Kind regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121102/de165454/attachment.html From alejandro.murillo at oracle.com Fri Nov 2 11:25:37 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 02 Nov 2012 18:25:37 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 29 new changesets Message-ID: <20121102182637.3E3EA47747@hg.openjdk.java.net> Changeset: bf14ed159fb0 Author: kvn Date: 2012-05-23 12:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bf14ed159fb0 7158801: Improve VM CompileOnly option Summary: Fixed buffer overflow during parsing flags -XX:CompileCommand=, -XX:CompileOnly= and command lines in .hotspot_compiler file. Reviewed-by: never ! src/share/vm/compiler/compilerOracle.cpp Changeset: fe4a4ea5bed9 Author: kamg Date: 2012-06-08 12:49 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fe4a4ea5bed9 7158804: Improve config file parsing Summary: Check buffer length when reading Reviewed-by: dholmes, dcubed ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp + test/runtime/7158804/Test7158804.sh Changeset: 6b5a3d18fe0e Author: asaha Date: 2012-08-02 14:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6b5a3d18fe0e Merge ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 000352e00389 Author: asaha Date: 2012-08-02 22:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/000352e00389 Merge Changeset: defeb6dad7d5 Author: asaha Date: 2012-08-10 10:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/defeb6dad7d5 Merge Changeset: e4d10261499c Author: asaha Date: 2012-09-07 18:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e4d10261499c Merge - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 521c82b9cbf8 Author: kvn Date: 2012-09-19 13:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/521c82b9cbf8 7198606: Improve VM optimization Summary: Remove incorrect code in OptimizeFill optimization. Reviewed-by: roland, twisti ! src/share/vm/opto/loopTransform.cpp Changeset: 849cf0480cb9 Author: asaha Date: 2012-09-25 11:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/849cf0480cb9 Merge Changeset: 5a3a6dac85e2 Author: asaha Date: 2012-09-26 09:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5a3a6dac85e2 7199488: [TEST] runtime/7158800/InternTest.java failed due to false-positive on PID match. Reviewed-by: coleenp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: 218a94758fe7 Author: asaha Date: 2012-10-10 14:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/218a94758fe7 Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java - agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java - make/solaris/makefiles/reorder_COMPILER1_amd64 - make/solaris/makefiles/reorder_COMPILER1_i486 - make/solaris/makefiles/reorder_COMPILER1_sparc - make/solaris/makefiles/reorder_COMPILER1_sparcv9 - make/solaris/makefiles/reorder_COMPILER2_amd64 - make/solaris/makefiles/reorder_COMPILER2_i486 - make/solaris/makefiles/reorder_COMPILER2_sparc - make/solaris/makefiles/reorder_COMPILER2_sparcv9 - make/solaris/makefiles/reorder_CORE_i486 - make/solaris/makefiles/reorder_CORE_sparc - make/solaris/makefiles/reorder_CORE_sparcv9 - make/solaris/makefiles/reorder_TIERED_amd64 - make/solaris/makefiles/reorder_TIERED_i486 - make/solaris/makefiles/reorder_TIERED_sparc - make/solaris/makefiles/reorder_TIERED_sparcv9 - make/solaris/reorder.sh - src/cpu/sparc/vm/dump_sparc.cpp - src/cpu/x86/vm/dump_x86_32.cpp - src/cpu/x86/vm/dump_x86_64.cpp - src/cpu/zero/vm/dump_zero.cpp - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java - src/share/vm/ci/ciArrayKlassKlass.hpp - src/share/vm/ci/ciCPCache.cpp - src/share/vm/ci/ciCPCache.hpp - src/share/vm/ci/ciInstanceKlassKlass.cpp - src/share/vm/ci/ciInstanceKlassKlass.hpp - src/share/vm/ci/ciKlassKlass.cpp - src/share/vm/ci/ciKlassKlass.hpp - src/share/vm/ci/ciMethodKlass.cpp - src/share/vm/ci/ciMethodKlass.hpp - src/share/vm/ci/ciObjArrayKlassKlass.cpp - src/share/vm/ci/ciObjArrayKlassKlass.hpp - src/share/vm/ci/ciTypeArrayKlassKlass.cpp - src/share/vm/ci/ciTypeArrayKlassKlass.hpp ! src/share/vm/compiler/compilerOracle.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp - src/share/vm/memory/classify.cpp - src/share/vm/memory/classify.hpp - src/share/vm/memory/compactPermGen.hpp - src/share/vm/memory/compactingPermGenGen.cpp - src/share/vm/memory/compactingPermGenGen.hpp - src/share/vm/memory/dump.cpp - src/share/vm/memory/permGen.cpp - src/share/vm/memory/permGen.hpp - src/share/vm/memory/restore.cpp - src/share/vm/memory/serialize.cpp - src/share/vm/oops/arrayKlassKlass.cpp - src/share/vm/oops/arrayKlassKlass.hpp - src/share/vm/oops/compiledICHolderKlass.cpp - src/share/vm/oops/compiledICHolderKlass.hpp - src/share/vm/oops/compiledICHolderOop.cpp - src/share/vm/oops/compiledICHolderOop.hpp - src/share/vm/oops/constMethodKlass.cpp - src/share/vm/oops/constMethodKlass.hpp - src/share/vm/oops/constMethodOop.cpp - src/share/vm/oops/constMethodOop.hpp - src/share/vm/oops/constantPoolKlass.cpp - src/share/vm/oops/constantPoolKlass.hpp - src/share/vm/oops/constantPoolOop.cpp - src/share/vm/oops/constantPoolOop.hpp - src/share/vm/oops/cpCacheKlass.cpp - src/share/vm/oops/cpCacheKlass.hpp - src/share/vm/oops/cpCacheOop.cpp - src/share/vm/oops/cpCacheOop.hpp - src/share/vm/oops/instanceKlassKlass.cpp - src/share/vm/oops/instanceKlassKlass.hpp - src/share/vm/oops/klassKlass.cpp - src/share/vm/oops/klassKlass.hpp - src/share/vm/oops/klassOop.cpp - src/share/vm/oops/klassOop.hpp - src/share/vm/oops/methodDataKlass.cpp - src/share/vm/oops/methodDataKlass.hpp - src/share/vm/oops/methodDataOop.cpp - src/share/vm/oops/methodDataOop.hpp - src/share/vm/oops/methodKlass.cpp - src/share/vm/oops/methodKlass.hpp - src/share/vm/oops/methodOop.cpp - src/share/vm/oops/methodOop.hpp - src/share/vm/oops/objArrayKlassKlass.cpp - src/share/vm/oops/objArrayKlassKlass.hpp - src/share/vm/oops/typeArrayKlassKlass.cpp - src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 6ba00f89fbe1 Author: asaha Date: 2012-10-11 15:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6ba00f89fbe1 Merge ! src/share/vm/runtime/arguments.cpp Changeset: d2582a08fa5d Author: asaha Date: 2012-10-18 21:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d2582a08fa5d Merge ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: cb829aa4c98e Author: lana Date: 2012-10-25 20:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cb829aa4c98e Merge - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: acabb5c282f5 Author: lana Date: 2012-10-30 13:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/acabb5c282f5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 4d37eb50b9b1 Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4d37eb50b9b1 Added tag jdk8-b63 for changeset acabb5c282f5 ! .hgtags Changeset: 5ec0c42da025 Author: coleenp Date: 2012-10-25 16:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5ec0c42da025 7188234: Deprecate VM command line options Summary: Remove support for the UseVectoredExceptions flag Reviewed-by: jcoomes, kamg Contributed-by: harold.seigel at oracle.com ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: e81fbc04a942 Author: coleenp Date: 2012-10-25 16:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e81fbc04a942 7191817: -XX:+UseSerialGC -XX:+UseLargePages crashes with SIGFPE on MacOS X Summary: Disable -XX:+UseLargePages for MacOS X Reviewed-by: dholmes, coleenp, sla Contributed-by: harold.seigel at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: 0af5da0c9d9d Author: sla Date: 2012-10-29 21:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0af5da0c9d9d 8001619: Remove usage of _ALLBSD_SOURCE in bsd files Reviewed-by: coleenp, dholmes ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp Changeset: 39556eae08af Author: sspitsyn Date: 2012-10-29 11:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/39556eae08af 6533010: SPEC: A few broken links in jvmti.html Summary: Fix the incorrect links in jvmti.html reported by the LinkCheck tool Reviewed-by: jjh, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnvBase.hpp Changeset: 845129b692f6 Author: minqi Date: 2012-10-29 16:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/845129b692f6 Merge Changeset: a1b8cf9cf970 Author: sla Date: 2012-11-01 13:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a1b8cf9cf970 8002078: hs_err_pid file should report full JDK version string Reviewed-by: dholmes, sspitsyn, kmo ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/vmError.cpp Changeset: cae17c597196 Author: coleenp Date: 2012-11-01 11:57 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cae17c597196 Merge ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/globals.hpp Changeset: 3fadc0e8cffe Author: jmasa Date: 2012-10-30 10:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3fadc0e8cffe 8000988: VM deadlock when running btree006 on windows-i586 Reviewed-by: johnc, jcoomes, ysr ! src/share/vm/memory/collectorPolicy.cpp Changeset: 3dfffc8b9722 Author: brutisso Date: 2012-10-30 20:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3dfffc8b9722 8001564: The load balancing function steal_1_random in taskqueue is not random Summary: Removes the two unused functions GenericTaskQueueSet::steal_1_random and GenericTaskQueueSet::steal_best_of_all Reviewed-by: brutisso, stefank Contributed-by: erik.x.helin at oracle.com ! src/share/vm/utilities/taskqueue.hpp Changeset: ca6d147ed881 Author: jcoomes Date: 2012-11-01 23:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ca6d147ed881 Merge Changeset: d8f9034920f6 Author: amurillo Date: 2012-11-02 04:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d8f9034920f6 Merge Changeset: 8cb93eadfb6d Author: amurillo Date: 2012-11-02 07:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8cb93eadfb6d Merge ! src/share/vm/runtime/arguments.cpp Changeset: 5920f72e799c Author: amurillo Date: 2012-11-02 07:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5920f72e799c Added tag hs25-b08 for changeset 8cb93eadfb6d ! .hgtags Changeset: ca8168203393 Author: amurillo Date: 2012-11-02 07:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ca8168203393 8002181: new hotspot build - hs25-b09 Reviewed-by: jcoomes ! make/hotspot_version From christian.thalinger at oracle.com Fri Nov 2 16:08:55 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 02 Nov 2012 23:08:55 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8001658: No need to pass resolved_references as argument to ConstantPoolCacheEntry::set_method_handle_common Message-ID: <20121102230901.E69A04774F@hg.openjdk.java.net> Changeset: 64672b22ef05 Author: twisti Date: 2012-11-02 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/64672b22ef05 8001658: No need to pass resolved_references as argument to ConstantPoolCacheEntry::set_method_handle_common Reviewed-by: twisti Contributed-by: Bharadwaj Yadavalli ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp From vladimir.kozlov at oracle.com Fri Nov 2 16:34:19 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 02 Nov 2012 16:34:19 -0700 Subject: Request for reviews (S): 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity Message-ID: <5094587B.2070106@oracle.com> http://cr.openjdk.java.net/~kvn/8002069/webrev/ The reference to a field on a dead path (which is not eliminated yet) of bimorphic inlined call has different type (oop) instead of real (int) field type. Added missed type check: - if (store != NULL && store->is_Store()) { + if (store != NULL && store->is_Store() && + store->as_Store()->memory_type() == ft) { The rest of changes are additional verification and verbose output during failure which helped me to debug the problem. Added compiler regression test. Tested with CTW and compiler regression tests. Thanks, Vladimir From christian.thalinger at oracle.com Mon Nov 5 08:44:15 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 5 Nov 2012 08:44:15 -0800 Subject: Problem with CHECK_NULL macro in return statements In-Reply-To: <7C9B87B351A4BA4AA9EC95BB4181165606BB0A68@DEWDFEMB13A.global.corp.sap> References: <7C9B87B351A4BA4AA9EC95BB4181165606BB0A68@DEWDFEMB13A.global.corp.sap> Message-ID: <42ACE7D3-84A8-4CF7-B248-986EBF8FE699@oracle.com> On Nov 2, 2012, at 9:38 AM, "Doerr, Martin" wrote: > Hello everybody, > > I found many places at which the CHECK_NULL macro gets used in a return statement like the following one: > return the_table()->basic_add(index, (u1*)buffer, len, hashValue, true, CHECK_NULL); > > However, this does not work as one would usually expect. The macro gets expanded to: > __the_thread__); if ((((ThreadShadow*)__the_thread__)->has_pending_exception())) return NULL; (0 > > The return statement above prevents the code after ?__the_thread__);? from ever getting evaluated. There was a discussion with Volker about this issue some time ago. I can't remember what the outcome was. Do you guys have a fix to propose? -- Chris > > Kind regards, > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121105/6aecdc06/attachment.html From kumars at ncsu.edu Mon Nov 5 09:11:14 2012 From: kumars at ncsu.edu (Kumar Saurav) Date: Mon, 05 Nov 2012 12:11:14 -0500 Subject: Making changed to bytecodeInterpreter.cpp Message-ID: <5097F332.6030406@ncsu.edu> Hi, I have installed icedtea6-1.11.4 and am trying to modify bytecodeInterpreter.cpp to trap branch conditions. Once I make changes to trap branch conditions and try to do "make hotspot" in the icedtea6-1.11.4 main directory, it works. But when I try using just "make" the build stops with the following error: -def-build-bootstrap-tool: build-bootstrap-javac: mmap failed for CEN and END part of zip file [jar] error while reading original manifest in file: /home/icedtea6-1.11.4/openjdk.build/langtools/build/bootstrap/lib/javac.jarnull # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (malloc) failed to allocate 32756 bytes for ChunkPool::allocate # An error report file with more information is saved as: # /home/icedtea6-1.11.4/openjdk/langtools/make/hs_err_pid5811.log make[3]: *** [build] Error 1 make[3]: Leaving directory `/home/icedtea6-1.11.4/openjdk/langtools/make' make[2]: *** [langtools-build] Error 2 make[2]: Leaving directory `/home/icedtea6-1.11.4/openjdk' make[1]: *** [build_product_image] Error 2 make[1]: Leaving directory `/home/icedtea6-1.11.4/openjdk' make: *** [stamps/icedtea.stamp] Error 2 I read the log file and it mentioned that one of the things I should try is to reduce the Java heap size. So, I used the flag -Xmx256m in /acinclude.m4 but this didn't help. Can you suggest the build process to follow if we make changes to files like bytecodeInterpreter.cpp and bytecodeInterpreter.h? -- Best Regards, Sinc?res Salutations, Mit Freundlichen Gr??en, * *Kumar Saurav* * * ** ** Graduate Student-Computer Engineering, ECE Department * **Mobile +1 919 931 7626 North Carolina State University, Raleigh, NC, USA. /Privileged/Confidential Information may be contained in this message. If you are not an intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication and any attachments is strictly prohibited. If you have received this communication in error, please notify the sender by reply transmission and delete the message without copying and disclosing it./ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121105/024df899/attachment.html From volker.simonis at gmail.com Mon Nov 5 09:44:19 2012 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 5 Nov 2012 18:44:19 +0100 Subject: Problem with CHECK_NULL macro in return statements In-Reply-To: <42ACE7D3-84A8-4CF7-B248-986EBF8FE699@oracle.com> References: <7C9B87B351A4BA4AA9EC95BB4181165606BB0A68@DEWDFEMB13A.global.corp.sap> <42ACE7D3-84A8-4CF7-B248-986EBF8FE699@oracle.com> Message-ID: Hi, we indeed discussed this topic three years ago: http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-October/thread.html#2175 The general outcome of the discussion was to: Have a look at every single method which uses the check macro in a return statement: - if it only has callers which check for pending exceptions themselves we can safely replace CHECK with THREAD. This would eliminate the unreachable code and allow the compiler to emit tail calls. - if it has callers which don't check for pending exception, we should introduce a temporary variable. I promised to prepare a Webrev that time which I haven't done until now so I'm a little bit reluctant to promise it again:) But I'll try my best to fix it this time! Regards, Volker On Mon, Nov 5, 2012 at 5:44 PM, Christian Thalinger wrote: > > On Nov 2, 2012, at 9:38 AM, "Doerr, Martin" wrote: > > Hello everybody, > > > > I found many places at which the CHECK_NULL macro gets used in a return > statement like the following one: > > return the_table()->basic_add(index, (u1*)buffer, len, hashValue, true, > CHECK_NULL); > > > > However, this does not work as one would usually expect. The macro gets > expanded to: > > __the_thread__); if > ((((ThreadShadow*)__the_thread__)->has_pending_exception())) return NULL; (0 > > > > The return statement above prevents the code after ?__the_thread__);? from > ever getting evaluated. > > > There was a discussion with Volker about this issue some time ago. I can't > remember what the outcome was. Do you guys have a fix to propose? > > -- Chris > > > > Kind regards, > > Martin > > From rednaxelafx at gmail.com Mon Nov 5 09:54:32 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 6 Nov 2012 01:54:32 +0800 Subject: Making changed to bytecodeInterpreter.cpp In-Reply-To: <5097F332.6030406@ncsu.edu> References: <5097F332.6030406@ncsu.edu> Message-ID: Hi Kumar, Could you post the crash log (/home/icedtea6-1.11.4/openjdk/ langtools/make/hs_err_pid5811.log) somewhere to let people get more details? >From the log in your mail it doesn't look like a JIT compiler issue. This list (hotspot-compiler-dev) is for discussion on HotSpot VM's JIT compilers. The problem you're hitting looks more like a zlib problem, or you might be really running low on memory. It'll take more information on the problem to be able to redirect you to a more appropriate list. BTW, when you run "make" in the main directory, it'll build the whole JDK, where as running "make hotspot" will only build the VM. If the latter is sufficient for you to carry on your experiment, you might just want to build the VM alone and save the trouble of dealing with this crash. - Kris On Tue, Nov 6, 2012 at 1:11 AM, Kumar Saurav wrote: > Hi, > > I have installed icedtea6-1.11.4 and am trying to modify > bytecodeInterpreter.cpp to trap branch conditions. Once I make changes to > trap branch conditions and try to do "make hotspot" in the icedtea6-1.11.4 > main directory, it works. But when I try using just "make" the build stops > with the following error: > > -def-build-bootstrap-tool: > > build-bootstrap-javac: > mmap failed for CEN and END part of zip file > [jar] error while reading original manifest in file: > /home/icedtea6-1.11.4/openjdk.build/langtools/build/bootstrap/lib/javac.jarnull > # > # There is insufficient memory for the Java Runtime Environment to > continue. > # Native memory allocation (malloc) failed to allocate 32756 bytes for > ChunkPool::allocate > # An error report file with more information is saved as: > # /home/icedtea6-1.11.4/openjdk/langtools/make/hs_err_pid5811.log > make[3]: *** [build] Error 1 > make[3]: Leaving directory `/home/icedtea6-1.11.4/openjdk/langtools/make' > make[2]: *** [langtools-build] Error 2 > make[2]: Leaving directory `/home/icedtea6-1.11.4/openjdk' > make[1]: *** [build_product_image] Error 2 > make[1]: Leaving directory `/home/icedtea6-1.11.4/openjdk' > make: *** [stamps/icedtea.stamp] Error 2 > > I read the log file and it mentioned that one of the things I should try > is to reduce the Java heap size. So, I used the flag -Xmx256m in > /acinclude.m4 but this didn't help. > > Can you suggest the build process to follow if we make changes to files > like bytecodeInterpreter.cpp and bytecodeInterpreter.h? > -- > Best Regards, Sinc?res Salutations, Mit Freundlichen Gr??en, > * > > Kumar Saurav > * > * > > ** > > Graduate Student-Computer Engineering, > ECE Department > > > * > * * Mobile +1 919 931 7626 > North Carolina State University, > Raleigh, NC, USA. > > *Privileged/Confidential Information may be contained in this message. > If you are not an intended recipient, you are hereby notified that any > disclosure, reproduction, distribution or other use of this communication > and any attachments is strictly prohibited. If you have received this > communication in error, please notify the sender by reply transmission and > delete the message without copying and disclosing it.* > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121106/cf2db5aa/attachment-0001.html From bharadwaj.yadavalli at oracle.com Mon Nov 5 11:51:52 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Mon, 05 Nov 2012 14:51:52 -0500 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50916B78.7090207@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> Message-ID: <509818D8.8090007@oracle.com> As a consequence of keeping a more accurate track of live and dead ideal nodes, we have the following ideal node counts to report in various log messages: 1. number of nodes created (Compile::unique()) - access time O(1) 2. number of nodes live as tracked via proposed code additions (Compile::live_nodes()) - access time O(1) 3. number of nodes live computed by graph walk (Compile::count_live_nodes_by_graph_walk()) - O(N) where N is the number of nodes. We have the following command line options (existing and proposed) that would log one or more of the above ideal node counts: 1. LogCompilation - existing option 2. PrintIdealNodeCount - proposed to print to console (tty) 3. VerifyIdealNodeCount - proposed to verify that tracked live nodes is the same as live nodes computed by graph walk and emit a log message if they are not the same. After reading through all the review comments on my RFR, following is my proposed way to incorporate the responses. Move all the logging functionality into TracePhase so that it augments the information logged therein. 1. LogCompilation - existing option * Augment the current logging via TracePhase; currently we just print out the number of nodes created (unique()) 2. PrintIdealNodeCount - print number of nodes created, live as tracked to console (tty) 3. VerifyIdealNodeCount - if verification fails, print total nodes created, number of tracked live nodes and live nodes computed by graph walk. If this sounds reasonable, I'll send out an updated webrev. Thanks, Bharadwaj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121105/05edbe84/attachment.html From vladimir.kozlov at oracle.com Mon Nov 5 12:31:15 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 05 Nov 2012 12:31:15 -0800 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <509818D8.8090007@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> Message-ID: <50982213.3090602@oracle.com> Yes, your proposal looks reasonable. Thanks, Vladimir Bharadwaj Yadavalli wrote: > As a consequence of keeping a more accurate track of live and dead > ideal nodes, we have the following ideal node counts to report in > various log messages: > > 1. number of nodes created (Compile::unique()) - access time O(1) > 2. number of nodes live as tracked via proposed code additions > (Compile::live_nodes()) - access time O(1) > 3. number of nodes live computed by graph walk > (Compile::count_live_nodes_by_graph_walk()) - O(N) where N is the > number of nodes. > > We have the following command line options (existing and proposed) that > would log one or more of the above ideal node counts: > > 1. LogCompilation - existing option > 2. PrintIdealNodeCount - proposed to print to console (tty) > 3. VerifyIdealNodeCount - proposed to verify that tracked live nodes > is the same as live nodes computed by graph walk and emit a log > message if they are not the same. > > After reading through all the review comments on my RFR, following is my > proposed way to incorporate the responses. > Move all the logging functionality into TracePhase so that it augments > the information logged therein. > > 1. LogCompilation - existing option > * Augment the current logging via TracePhase; currently we > just print out the number of nodes created (unique()) > 2. PrintIdealNodeCount - print number of nodes created, live as > tracked to console (tty) > 3. VerifyIdealNodeCount - if verification fails, print total nodes > created, number of tracked live nodes and live nodes computed by > graph walk. > > If this sounds reasonable, I'll send out an updated webrev. > > Thanks, > > Bharadwaj > From kumars at ncsu.edu Mon Nov 5 11:52:28 2012 From: kumars at ncsu.edu (Kumar Saurav) Date: Mon, 05 Nov 2012 14:52:28 -0500 Subject: Making changed to bytecodeInterpreter.cpp In-Reply-To: References: <5097F332.6030406@ncsu.edu> Message-ID: <509818FC.9060605@ncsu.edu> The crash log is attached. I checked the memory using the command "top" and it shows "1174016k" as free. The "make hotspot" works if I just want to trap branches (i.e. changes made to bytecodeInterpreter.cpp), however, I also want to trap messages being printed to screen. I found that system.out.println("xyz") ultimately ends up in a function writeBytes, in io_util.c (path ./openjdk-ecj/jdk/src/share/native/java/io/io_util.c). So, I want to include a printf in this function to confirm that I can trap system.out.println. Once I include this, I will have to issue make (I could not find any other rule which would translate changes in io_util.c to other dependant files). Best Regards, Sinc?res Salutations, Mit Freundlichen Gr??en, * *Kumar Saurav* * On 11/05/2012 12:54 PM, Krystal Mok wrote: > Hi Kumar, > > Could you post the crash log > (/home/icedtea6-1.11.4/openjdk/langtools/make/hs_err_pid5811.log) > somewhere to let people get more details? > > From the log in your mail it doesn't look like a JIT compiler issue. > This list (hotspot-compiler-dev) is for discussion on HotSpot VM's JIT > compilers. The problem you're hitting looks more like a zlib problem, > or you might be really running low on memory. > It'll take more information on the problem to be able to redirect you > to a more appropriate list. > > BTW, when you run "make" in the main directory, it'll build the whole > JDK, where as running "make hotspot" will only build the VM. If the > latter is sufficient for you to carry on your experiment, you might > just want to build the VM alone and save the trouble of dealing with > this crash. > > - Kris > > On Tue, Nov 6, 2012 at 1:11 AM, Kumar Saurav > wrote: > > Hi, > > I have installed icedtea6-1.11.4 and am trying to modify > bytecodeInterpreter.cpp to trap branch conditions. Once I make > changes to trap branch conditions and try to do "make hotspot" in > the icedtea6-1.11.4 main directory, it works. But when I try using > just "make" the build stops with the following error: > > -def-build-bootstrap-tool: > > build-bootstrap-javac: > mmap failed for CEN and END part of zip file > [jar] error while reading original manifest in file: > /home/icedtea6-1.11.4/openjdk.build/langtools/build/bootstrap/lib/javac.jarnull > # > # There is insufficient memory for the Java Runtime Environment to > continue. > # Native memory allocation (malloc) failed to allocate 32756 bytes > for ChunkPool::allocate > # An error report file with more information is saved as: > # /home/icedtea6-1.11.4/openjdk/langtools/make/hs_err_pid5811.log > make[3]: *** [build] Error 1 > make[3]: Leaving directory > `/home/icedtea6-1.11.4/openjdk/langtools/make' > make[2]: *** [langtools-build] Error 2 > make[2]: Leaving directory `/home/icedtea6-1.11.4/openjdk' > make[1]: *** [build_product_image] Error 2 > make[1]: Leaving directory `/home/icedtea6-1.11.4/openjdk' > make: *** [stamps/icedtea.stamp] Error 2 > > I read the log file and it mentioned that one of the things I > should try is to reduce the Java heap size. So, I used the flag > -Xmx256m in /acinclude.m4 but this didn't help. > > Can you suggest the build process to follow if we make changes to > files like bytecodeInterpreter.cpp and bytecodeInterpreter.h? > -- > Best Regards, Sinc?res Salutations, Mit Freundlichen Gr??en, > * > > *Kumar Saurav* > > * > * > > ** > > ** > > Graduate Student-Computer Engineering, > ECE Department > > > * > **Mobile +1 919 931 7626 > North Carolina State University, > Raleigh, NC, USA. > > /Privileged/Confidential Information may be contained in this > message. If you are not an intended recipient, you are hereby > notified that any disclosure, reproduction, distribution or other > use of this communication and any attachments is strictly > prohibited. If you have received this communication in error, > please notify the sender by reply transmission and delete the > message without copying and disclosing it./ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121105/5036126c/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid5811.log Type: text/x-log Size: 102540 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121105/5036126c/hs_err_pid5811-0001.log From john.r.rose at oracle.com Mon Nov 5 12:59:19 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 5 Nov 2012 12:59:19 -0800 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50982213.3090602@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> Message-ID: <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> I agree with this design. Lets get this done so we can use it. It may be that when we compute additional derived metrics we can print them using the same general design. Maybe it would be good to use less specific option names like "graph size" instead of "node count". Someone should look into putting graph size metrics on byte code and compiled code, so we are using similar metrics in more places. -- John (on my iPhone) On Nov 5, 2012, at 12:31 PM, Vladimir Kozlov wrote: > Yes, your proposal looks reasonable. From vladimir.kozlov at oracle.com Mon Nov 5 18:22:44 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 05 Nov 2012 18:22:44 -0800 Subject: Request for reviews (XS): 002294: assert(VM_Version::supports_ssse3()) failed Message-ID: <50987474.4010907@oracle.com> http://cr.openjdk.java.net/~kvn/8002294/webrev/ 2 compiler regression tests failed after 7184394 changes. These test use -XX:UseSSE=0 flag for testing. AES intrinsic code uses ssse3 'pshufb' instruction but it does not check UseSSE value. Thanks, Vladimir From roland.westrelin at oracle.com Tue Nov 6 00:52:14 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 6 Nov 2012 09:52:14 +0100 Subject: Request for reviews (XS): 002294: assert(VM_Version::supports_ssse3()) failed In-Reply-To: <50987474.4010907@oracle.com> References: <50987474.4010907@oracle.com> Message-ID: <02BDA3AB-62D6-42B9-BC23-B2567DB5AB59@oracle.com> It looks good. Roland. From vladimir.kozlov at oracle.com Tue Nov 6 07:32:57 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 Nov 2012 07:32:57 -0800 Subject: Request for reviews (XS): 002294: assert(VM_Version::supports_ssse3()) failed In-Reply-To: <02BDA3AB-62D6-42B9-BC23-B2567DB5AB59@oracle.com> References: <50987474.4010907@oracle.com> <02BDA3AB-62D6-42B9-BC23-B2567DB5AB59@oracle.com> Message-ID: <50992DA9.50504@oracle.com> Thanks, Roland Vladimir On 11/6/12 12:52 AM, Roland Westrelin wrote: > It looks good. > > Roland. From christian.thalinger at oracle.com Tue Nov 6 08:18:27 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 6 Nov 2012 08:18:27 -0800 Subject: Problem with CHECK_NULL macro in return statements In-Reply-To: References: <7C9B87B351A4BA4AA9EC95BB4181165606BB0A68@DEWDFEMB13A.global.corp.sap> <42ACE7D3-84A8-4CF7-B248-986EBF8FE699@oracle.com> Message-ID: <22C6844B-D1A5-4508-8808-71193FC0424C@oracle.com> On Nov 5, 2012, at 9:44 AM, Volker Simonis wrote: > Hi, > > we indeed discussed this topic three years ago: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-October/thread.html#2175 > > The general outcome of the discussion was to: > > Have a look at every single method which uses the > check macro in a return statement: > - if it only has callers which check for pending exceptions themselves > we can safely replace CHECK with THREAD. This would eliminate the > unreachable code and allow the compiler to emit tail calls. > - if it has callers which don't check for pending exception, we should > introduce a temporary variable. > > I promised to prepare a Webrev that time which I haven't done until > now so I'm a little bit reluctant to promise it again:) > But I'll try my best to fix it this time! I knew the ball was in your court :-D -- Chris > > Regards, > Volker > > > > On Mon, Nov 5, 2012 at 5:44 PM, Christian Thalinger > wrote: >> >> On Nov 2, 2012, at 9:38 AM, "Doerr, Martin" wrote: >> >> Hello everybody, >> >> >> >> I found many places at which the CHECK_NULL macro gets used in a return >> statement like the following one: >> >> return the_table()->basic_add(index, (u1*)buffer, len, hashValue, true, >> CHECK_NULL); >> >> >> >> However, this does not work as one would usually expect. The macro gets >> expanded to: >> >> __the_thread__); if >> ((((ThreadShadow*)__the_thread__)->has_pending_exception())) return NULL; (0 >> >> >> >> The return statement above prevents the code after ?__the_thread__);? from >> ever getting evaluated. >> >> >> There was a discussion with Volker about this issue some time ago. I can't >> remember what the outcome was. Do you guys have a fix to propose? >> >> -- Chris >> >> >> >> Kind regards, >> >> Martin >> >> From vladimir.kozlov at oracle.com Tue Nov 6 11:33:18 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Tue, 06 Nov 2012 19:33:18 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8002294: assert(VM_Version::supports_ssse3()) failed Message-ID: <20121106193323.0ABA4477BF@hg.openjdk.java.net> Changeset: dbeaeee28bc2 Author: kvn Date: 2012-11-06 09:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/dbeaeee28bc2 8002294: assert(VM_Version::supports_ssse3()) failed Summary: Add missing UseSSE check for AES intrinsics. Reviewed-by: roland, twisti ! src/cpu/x86/vm/vm_version_x86.cpp From roland.westrelin at oracle.com Tue Nov 6 11:37:32 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 6 Nov 2012 20:37:32 +0100 Subject: Request for reviews (S): 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity In-Reply-To: <5094587B.2070106@oracle.com> References: <5094587B.2070106@oracle.com> Message-ID: It looks good. Roland. From vladimir.kozlov at oracle.com Tue Nov 6 11:41:32 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 Nov 2012 11:41:32 -0800 Subject: Request for reviews (S): 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity In-Reply-To: References: <5094587B.2070106@oracle.com> Message-ID: <509967EC.4070209@oracle.com> Thank you, Roland Vladimir Roland Westrelin wrote: > It looks good. > > Roland. From yumin.qi at oracle.com Tue Nov 6 12:41:58 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Tue, 06 Nov 2012 12:41:58 -0800 Subject: Fwd: Re: RFR: 6830717: replay of compilations would help with debugging Message-ID: <50997616.9030301@oracle.com> Forget to cc to open list. Thanks Yumin -------- Original Message -------- Subject: Re: RFR: 6830717: replay of compilations would help with debugging Date: Tue, 06 Nov 2012 10:53:26 -0800 From: yumin.qi at oracle.com Organization: Oracle Corporation To: serguei.spitsyn at oracle.com CC: Christian Thalinger , Vladimir Kozlov , Coleen Phillimore Hi, Serguei and all Made changes according to Serguei's suggestion, but could not change ci.dumpReplayData forward call to .dumpReplayData since there is some data is not consistent in compiler interface after runtime. Also changes to move dumpReplayData up to base class (not VMObject), so can save changes to subclasses. http://cr.openjdk.java.net/~minqi/6830717 Please have a look and comment. Thanks Yumin On 10/26/2012 3:57 PM, serguei.spitsyn at oracle.com wrote: > Continue for C++ files (VM code) ... > > *src/share/vm/utilities/utf8.cpp* > 165 // returns the quoted ascii length of a 0-terminated utf8 string > 166 int UTF8::quoted_ascii_length(const char* utf8_str, int utf8_length) { > 167 const char *ptr = (const char *)utf8_str; > . . . > 183 void UTF8::as_quoted_ascii(const char* utf8_str, char* buf, int buflen) { > 184 const char *ptr = (const char *)utf8_str; > . . . > 203 const char* UTF8::from_quoted_ascii(const char* quoted_ascii_str) { > 204 const char *ptr = (const char *)quoted_ascii_str; > No need to cast to (const char*) as arguments are already const char*. > > > || *src/share/vm/ci/ciReplay.cpp* > 603 if (field_signature[1] == 'B') { > 604 value = oopFactory::new_byteArray(length, CHECK); > 605 } else if (strcmp(field_signature, "[Z") == 0) { > 606 value = oopFactory::new_boolArray(length, CHECK); > 607 } else if (strcmp(field_signature, "[C") == 0) { > 608 value = oopFactory::new_charArray(length, CHECK); > 609 } else if (strcmp(field_signature, "[S") == 0) { > 610 value = oopFactory::new_shortArray(length, CHECK); > 611 } else if (strcmp(field_signature, "[F") == 0) { > 612 value = oopFactory::new_singleArray(length, CHECK); > 613 } else if (strcmp(field_signature, "[D") == 0) { > 614 value = oopFactory::new_doubleArray(length, CHECK); > 615 } else if (strcmp(field_signature, "[I") == 0) { > 616 value = oopFactory::new_intArray(length, CHECK); > 617 } else if (strcmp(field_signature, "[J") == 0) { > 618 value = oopFactory::new_longArray(length, CHECK); > 619 } else if (field_signature[0] == '['&& field_signature[1] == 'L') { > 620 KlassHandle kelem = resolve_klass(field_signature + 1, CHECK); > 621 value = oopFactory::new_objArray(kelem(), length, CHECK); > 622 } else { > 623 report_error("unhandled array staticfield"); > 624 } > 625 } > > As Christian already noted this can be rewritten like this: > > switch (field_signature[1]) { > case 'B': value = oopFactory::new_byteArray(length, CHECK); > case 'Z': value = oopFactory::new_boolArray(length, CHECK); > case 'C': value = oopFactory::new_charArray(length, CHECK); > case 'S': value = oopFactory::new_shortArray(length, CHECK); > case 'F': value = oopFactory::new_singleArray(length, CHECK); > case 'D': value = oopFactory::new_doubleArray(length, CHECK); > case 'I': value = oopFactory::new_intArray(length, CHECK); > case 'J': value = oopFactory::new_longArray(length, CHECK); > case 'L': > KlassHandle kelem = resolve_klass(field_signature + 1, CHECK); > value = oopFactory::new_objArray(kelem(), length, CHECK); > default: > report_error("unhandled array staticfield"); > } > > Almost the same comment about the lines 629-667. > > > These are the only comments I have. > > Thanks, > Serguei > > > On 10/26/12 12:37 PM, serguei.spitsyn at oracle.com wrote: >> Hi Yumin, >> >> *agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java >> * >> 778 // This is used to dump replay data from ciInstanceKlass, >> ciMehtodData etc >> Typo: ciMehtodData =>ciMethodData >> >> 777 new Command("dumpreplaydata", "dumpreplaydata {
| -a | >> id }", false) { >> What is id? Is it a thread name? If so, would it better to say: >> thread_name or thread_id? >> Also, do we need angle brackets: {
| -a | } ? >> >> || || *agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java* >> >> 137 sun.jvm.hotspot.oops.OopField bf = (OopField)f; >> The sun.jvm.hotspot.oops package os imported, so the short type >> name OopField can be used. >> No conflicts are expected, right? Otherwise, the "(OopField)f" >> would not be correct. >> >> || *agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java >> >> * 97 OopUtilities.escapeString(method.getName().asString()) + " " + >> method.getSignature().asString() + " " + >> 98 method.getInvocationCounter() + " " + >> 99 method.getBackedgeCounter() + " " + >> 100 interpreterInvocationCount() + " " + >> 101 interpreterThrowoutCount() + " " + >> >> It is better to break down the line 97 into two lines. >> It would be shorter and more consistent with the lines 98-101. >> >> >> || *agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java* >> >> 1055 sun.jvm.hotspot.oops.OopField bf = (OopField)f; >> The same as for ciInstanceKlass.java above. >> >> Could you introduce an utility method printFieldValue(Field f), so >> that the same code is shared with ciInstanceKlass.java? >> It feels that the code is the same. >> >> >> || *agent/src/share/classes/sun/jvm/hotspot/oops/Method.java >> >> *368 OopUtilities.escapeString(getName().asString()) + " " + >> getSignature().asString() + " " + >> The same as for the ciMethod.java above. >> >> >> || || *agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java* >> >> It looks like this new code can be shared with ciMethodData.java. >> You also may want to look at other files if similat sharing approach >> can be used. >> We can compare all ciXXX.java with XXX.java. >> >> >> || *agent/doc/clhsdb.html >> >> *52 dumpreplaydata
| -a | id [>replay.txt] > color="red">dump replay data into a file >> The same comment as for the *CommandProcessor.java*. >> >> >> || *agent/doc/c2replay.html >> >> *17 clhsdb>dumpreplaydata
| -a | id > replay.txt >> The same comment as for the *CommandProcessor.java*. >> >> >> I've reviewed only java files so far and decided to provide my >> feedback early. >> >> Thanks, >> Serguei >> >> >> On 10/26/12 9:33 AM, Yumin Qi wrote: >>> Hi, >>> >>> I need your help to have a second look at the changes based on >>> meta changes --- if OK will do push. >>> >>> Thanks >>> Yumin >>> >>> On 8/13/2012 5:02 PM, Christian Thalinger wrote: >>>> On Aug 6, 2012, at 2:40 PM, yumin.qi at oracle.com wrote: >>>> >>>>> Hi, >>>>> >>>>> Please give your comments of the changes about >>>>> 6830717: replay of compilations would help with debugging. >>>>> http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 >>>>> >>>>> Sometime jvm crashes in the process of compilation or in >>>>> compiled method. To reproduce the compilation process in debug JVM >>>>> is helpful for quickly identifying root cause. >>>>> To do recompilation, we collect data by using of SA >>>>> (Serviceability Agent) to extract application and system class >>>>> data from core file. Those information includes nmethod, >>>>> methodOop, methodDataOop, instanceKlass and corresponding ci >>>>> counterparts. >>>>> With reconfiguring similar (not exactly same) compiling >>>>> environment as in the core file, try to compile again the failed >>>>> java methods. >>>>> >>>>> contributed by Tom R (never). webrev: >>>>> >>>>> http://cr.openjdk.java.net/~minqi/6830717/ >>>>> >>>> src/share/vm/ci/ciReplay.cpp: >>>> >>>> 603 if (strcmp(field_signature, "[B") == 0) { >>>> 604 oop value = oopFactory::new_byteArray(length, CHECK); >>>> 605 java_mirror->obj_field_put(fd.offset(), value); >>>> 606 } else if (strcmp(field_signature, "[Z") == 0) { >>>> 607 oop value = oopFactory::new_boolArray(length, CHECK); >>>> 608 java_mirror->obj_field_put(fd.offset(), value); >>>> 609 } else if (strcmp(field_signature, "[C") == 0) { >>>> 610 oop value = oopFactory::new_charArray(length, CHECK); >>>> 611 java_mirror->obj_field_put(fd.offset(), value); >>>> 612 } else if (strcmp(field_signature, "[S") == 0) { >>>> 613 oop value = oopFactory::new_shortArray(length, CHECK); >>>> 614 java_mirror->obj_field_put(fd.offset(), value); >>>> 615 } else if (strcmp(field_signature, "[F") == 0) { >>>> 616 oop value = oopFactory::new_singleArray(length, >>>> CHECK); >>>> 617 java_mirror->obj_field_put(fd.offset(), value); >>>> 618 } else if (strcmp(field_signature, "[D") == 0) { >>>> 619 oop value = oopFactory::new_doubleArray(length, >>>> CHECK); >>>> 620 java_mirror->obj_field_put(fd.offset(), value); >>>> 621 } else if (strcmp(field_signature, "[I") == 0) { >>>> 622 oop value = oopFactory::new_intArray(length, CHECK); >>>> 623 java_mirror->obj_field_put(fd.offset(), value); >>>> 624 } else if (strcmp(field_signature, "[J") == 0) { >>>> 625 oop value = oopFactory::new_longArray(length, CHECK); >>>> 626 java_mirror->obj_field_put(fd.offset(), value); >>>> 627 } else if (field_signature[0] == '['&& >>>> field_signature[1] == 'L') { >>>> >>>> Can't we switch on the second character? And move this call: >>>> >>>> 630 java_mirror->obj_field_put(fd.offset(), value); >>>> >>>> out of the switch? >>>> >>>> 637 if (strcmp(field_signature, "I") == 0) { >>>> 638 int value = atoi(string_value); >>>> 639 java_mirror->int_field_put(fd.offset(), value); >>>> 640 } else if (strcmp(field_signature, "B") == 0) { >>>> 641 int value = atoi(string_value); >>>> 642 java_mirror->byte_field_put(fd.offset(), value); >>>> 643 } else if (strcmp(field_signature, "C") == 0) { >>>> 644 int value = atoi(string_value); >>>> 645 java_mirror->char_field_put(fd.offset(), value); >>>> 646 } else if (strcmp(field_signature, "S") == 0) { >>>> 647 int value = atoi(string_value); >>>> 648 java_mirror->short_field_put(fd.offset(), value); >>>> 649 } else if (strcmp(field_signature, "Z") == 0) { >>>> 650 int value = atol(string_value); >>>> 651 java_mirror->bool_field_put(fd.offset(), value); >>>> 652 } else if (strcmp(field_signature, "J") == 0) { >>>> 653 jlong value; >>>> 654 if (sscanf(string_value, INT64_FORMAT,&value) != 1) { >>>> 655 fprintf(stderr, "Error parsing long: %s\n", >>>> string_value); >>>> 656 return; >>>> 657 } >>>> 658 java_mirror->long_field_put(fd.offset(), value); >>>> 659 } else if (strcmp(field_signature, "F") == 0) { >>>> 660 float value = atof(string_value); >>>> 661 java_mirror->float_field_put(fd.offset(), value); >>>> 662 } else if (strcmp(field_signature, "D") == 0) { >>>> 663 double value = atof(string_value); >>>> 664 java_mirror->double_field_put(fd.offset(), value); >>>> 665 } else if (strcmp(field_signature, >>>> "Ljava/lang/String;") == 0) { >>>> 666 Handle value = >>>> java_lang_String::create_from_str(string_value, CHECK); >>>> 667 java_mirror->obj_field_put(fd.offset(), value()); >>>> 668 } else if (field_signature[0] == 'L') { >>>> >>>> Same here (not the put though)? >>>> >>>> Otherwise it looks good. >>>> >>>> -- Chris >>>> >>>>> Thanks >>>>> Yumin >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121106/2a279054/attachment-0001.html From vladimir.x.ivanov at oracle.com Tue Nov 6 13:57:46 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 07 Nov 2012 00:57:46 +0300 Subject: Request for reviews (S): 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity In-Reply-To: <5094587B.2070106@oracle.com> References: <5094587B.2070106@oracle.com> Message-ID: <509987DA.2040702@oracle.com> Vladimir K., I'd like to clarify one thing with code style. Why do you guard verification code with ASSERT? Isn't it enough to have VerifyConnectionGraph non-product [1], so compiler can just eliminate relevant code as dead? As a use case: it's much easier and less error-prone to enable non-product code guarded by a flag just by changing flag type rather than replacing all relevant asserts. I envision such situations be useful during development/testing/problem diagnostics. Otherwise, the fix looks good. Best regards, Vladimir Ivanov [1] src/share/vm/opto/c2_globals.hpp:460: notproduct(bool, VerifyConnectionGraph , true, On 11/3/12 2:34 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8002069/webrev/ > > The reference to a field on a dead path (which is not eliminated yet) of > bimorphic inlined call has different type (oop) instead of real (int) > field type. > > Added missed type check: > > - if (store != NULL && store->is_Store()) { > + if (store != NULL && store->is_Store() && > + store->as_Store()->memory_type() == ft) { > > The rest of changes are additional verification and verbose output > during failure which helped me to debug the problem. > > Added compiler regression test. > > Tested with CTW and compiler regression tests. > > Thanks, > Vladimir > From vladimir.kozlov at oracle.com Tue Nov 6 14:38:51 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 Nov 2012 14:38:51 -0800 Subject: Request for reviews (S): 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity In-Reply-To: <509987DA.2040702@oracle.com> References: <5094587B.2070106@oracle.com> <509987DA.2040702@oracle.com> Message-ID: <5099917B.4080909@oracle.com> Thank you, Vladimir There are 3 major kinds of flags: product - available in all versions of VM builds (debug, product, optimized) develop - also available in all versions of VM build, but declared as a constant value in non-debug builds (product, optimized) - you can change its value on command line only in debug build notproduct - declared only in non-product builds (debug, optimized), have to be enclosed by #ifdef ASSERT or #ifndef PRODUCT. Regards, Vladimir K. Vladimir Ivanov wrote: > Vladimir K., > > I'd like to clarify one thing with code style. > > Why do you guard verification code with ASSERT? > Isn't it enough to have VerifyConnectionGraph non-product [1], so > compiler can just eliminate relevant code as dead? > > As a use case: it's much easier and less error-prone to enable > non-product code guarded by a flag just by changing flag type rather > than replacing all relevant asserts. I envision such situations be > useful during development/testing/problem diagnostics. > > Otherwise, the fix looks good. > > Best regards, > Vladimir Ivanov > > [1] src/share/vm/opto/c2_globals.hpp:460: notproduct(bool, > VerifyConnectionGraph , true, > > On 11/3/12 2:34 AM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8002069/webrev/ >> >> The reference to a field on a dead path (which is not eliminated yet) of >> bimorphic inlined call has different type (oop) instead of real (int) >> field type. >> >> Added missed type check: >> >> - if (store != NULL && store->is_Store()) { >> + if (store != NULL && store->is_Store() && >> + store->as_Store()->memory_type() == ft) { >> >> The rest of changes are additional verification and verbose output >> during failure which helped me to debug the problem. >> >> Added compiler regression test. >> >> Tested with CTW and compiler regression tests. >> >> Thanks, >> Vladimir >> From christian.thalinger at oracle.com Tue Nov 6 15:00:35 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 6 Nov 2012 15:00:35 -0800 Subject: Request for reviews (S): 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity In-Reply-To: <5094587B.2070106@oracle.com> References: <5094587B.2070106@oracle.com> Message-ID: Looks good. -- Chris On Nov 2, 2012, at 4:34 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8002069/webrev/ > > The reference to a field on a dead path (which is not eliminated yet) of bimorphic inlined call has different type (oop) instead of real (int) field type. > > Added missed type check: > > - if (store != NULL && store->is_Store()) { > + if (store != NULL && store->is_Store() && > + store->as_Store()->memory_type() == ft) { > > The rest of changes are additional verification and verbose output during failure which helped me to debug the problem. > > Added compiler regression test. > > Tested with CTW and compiler regression tests. > > Thanks, > Vladimir > From vladimir.kozlov at oracle.com Tue Nov 6 15:12:00 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 06 Nov 2012 15:12:00 -0800 Subject: Request for reviews (S): 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity In-Reply-To: References: <5094587B.2070106@oracle.com> Message-ID: <50999940.5070103@oracle.com> Thank you, Christian Vladimir Christian Thalinger wrote: > Looks good. -- Chris > > On Nov 2, 2012, at 4:34 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8002069/webrev/ >> >> The reference to a field on a dead path (which is not eliminated yet) of bimorphic inlined call has different type (oop) instead of real (int) field type. >> >> Added missed type check: >> >> - if (store != NULL && store->is_Store()) { >> + if (store != NULL && store->is_Store() && >> + store->as_Store()->memory_type() == ft) { >> >> The rest of changes are additional verification and verbose output during failure which helped me to debug the problem. >> >> Added compiler regression test. >> >> Tested with CTW and compiler regression tests. >> >> Thanks, >> Vladimir >> > From vladimir.kozlov at oracle.com Tue Nov 6 17:29:36 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 07 Nov 2012 01:29:36 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity Message-ID: <20121107012938.7F515477D4@hg.openjdk.java.net> Changeset: f3da5ff1514c Author: kvn Date: 2012-11-06 15:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/f3da5ff1514c 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity Summary: Added missed type check of initializing store in ConnectionGraph::find_init_values(). Reviewed-by: roland, twisti, vlivanov ! src/share/vm/opto/escape.cpp + test/compiler/8002069/Test8002069.java From vladimir.x.ivanov at oracle.com Wed Nov 7 08:56:45 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 07 Nov 2012 19:56:45 +0300 Subject: Request for reviews (S): 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity In-Reply-To: <5099917B.4080909@oracle.com> References: <5094587B.2070106@oracle.com> <509987DA.2040702@oracle.com> <5099917B.4080909@oracle.com> Message-ID: <509A92CD.90001@oracle.com> Ah, I see. Missed that difference between develop vs notproduct flags. Are there any guidelines when a flag should be "notproduct" and when "develop"? Best regards, Vladimir Ivanov On 11/7/12 1:38 AM, Vladimir Kozlov wrote: > Thank you, Vladimir > > There are 3 major kinds of flags: > > product - available in all versions of VM builds (debug, product, > optimized) > develop - also available in all versions of VM build, but declared as > a constant value in non-debug builds (product, optimized) - > you can change its value on command line only in debug build > notproduct - declared only in non-product builds (debug, > optimized), have to be enclosed by #ifdef ASSERT or > #ifndef PRODUCT. > > Regards, > Vladimir K. > > Vladimir Ivanov wrote: >> Vladimir K., >> >> I'd like to clarify one thing with code style. >> >> Why do you guard verification code with ASSERT? >> Isn't it enough to have VerifyConnectionGraph non-product [1], so >> compiler can just eliminate relevant code as dead? >> >> As a use case: it's much easier and less error-prone to enable >> non-product code guarded by a flag just by changing flag type rather >> than replacing all relevant asserts. I envision such situations be >> useful during development/testing/problem diagnostics. >> >> Otherwise, the fix looks good. >> >> Best regards, >> Vladimir Ivanov >> >> [1] src/share/vm/opto/c2_globals.hpp:460: notproduct(bool, >> VerifyConnectionGraph , true, >> >> On 11/3/12 2:34 AM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/8002069/webrev/ >>> >>> The reference to a field on a dead path (which is not eliminated yet) of >>> bimorphic inlined call has different type (oop) instead of real (int) >>> field type. >>> >>> Added missed type check: >>> >>> - if (store != NULL && store->is_Store()) { >>> + if (store != NULL && store->is_Store() && >>> + store->as_Store()->memory_type() == ft) { >>> >>> The rest of changes are additional verification and verbose output >>> during failure which helped me to debug the problem. >>> >>> Added compiler regression test. >>> >>> Tested with CTW and compiler regression tests. >>> >>> Thanks, >>> Vladimir >>> From vladimir.kozlov at oracle.com Wed Nov 7 18:32:49 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 07 Nov 2012 18:32:49 -0800 Subject: Request for reviews (S): 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity In-Reply-To: <509A92CD.90001@oracle.com> References: <5094587B.2070106@oracle.com> <509987DA.2040702@oracle.com> <5099917B.4080909@oracle.com> <509A92CD.90001@oracle.com> Message-ID: <509B19D1.50705@oracle.com> Vladimir Ivanov wrote: > Ah, I see. Missed that difference between develop vs notproduct flags. > > Are there any guidelines when a flag should be "notproduct" and when > "develop"? Originally there were no notproduct flags. But we had a lot of cases like this: #ifdef ASSERT if (Flag) { n->dump(); // dump() is only defined in debug build // to reduce C++ vtable size (we have several // hundreds ideal+mach nodes) assert(check,""); } #endif Where Flag was used only in such cases in debug VM. So "notproduct" type was added to reduce size of product VM (7 years ago): 6258968: Global flags cleanup for C1 and C2 Vladimir K. > > Best regards, > Vladimir Ivanov > > On 11/7/12 1:38 AM, Vladimir Kozlov wrote: >> Thank you, Vladimir >> >> There are 3 major kinds of flags: >> >> product - available in all versions of VM builds (debug, product, >> optimized) >> develop - also available in all versions of VM build, but declared as >> a constant value in non-debug builds (product, optimized) - >> you can change its value on command line only in debug build >> notproduct - declared only in non-product builds (debug, >> optimized), have to be enclosed by #ifdef ASSERT or >> #ifndef PRODUCT. >> >> Regards, >> Vladimir K. >> >> Vladimir Ivanov wrote: >>> Vladimir K., >>> >>> I'd like to clarify one thing with code style. >>> >>> Why do you guard verification code with ASSERT? >>> Isn't it enough to have VerifyConnectionGraph non-product [1], so >>> compiler can just eliminate relevant code as dead? >>> >>> As a use case: it's much easier and less error-prone to enable >>> non-product code guarded by a flag just by changing flag type rather >>> than replacing all relevant asserts. I envision such situations be >>> useful during development/testing/problem diagnostics. >>> >>> Otherwise, the fix looks good. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] src/share/vm/opto/c2_globals.hpp:460: notproduct(bool, >>> VerifyConnectionGraph , true, >>> >>> On 11/3/12 2:34 AM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/8002069/webrev/ >>>> >>>> The reference to a field on a dead path (which is not eliminated >>>> yet) of >>>> bimorphic inlined call has different type (oop) instead of real (int) >>>> field type. >>>> >>>> Added missed type check: >>>> >>>> - if (store != NULL && store->is_Store()) { >>>> + if (store != NULL && store->is_Store() && >>>> + store->as_Store()->memory_type() == ft) { >>>> >>>> The rest of changes are additional verification and verbose output >>>> during failure which helped me to debug the problem. >>>> >>>> Added compiler regression test. >>>> >>>> Tested with CTW and compiler regression tests. >>>> >>>> Thanks, >>>> Vladimir >>>> From heinz at javaspecialists.eu Wed Nov 7 22:07:14 2012 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Thu, 08 Nov 2012 07:07:14 +0100 Subject: [Fwd: _interrupted field visibility bug in OpenJDK 7+] Message-ID: <509B4C12.5060705@javaspecialists.eu> In case you have not seen, there is a discussion on concurrency-interest (http://tinyurl.com/bofu46j) about a new bug that we discovered where code dealing with isInterrupted() is not correctly optimized, leading to issues where a thread does not see its interrupted status change. This has been submitted as a bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003135 Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion IEEE Certified Software Development Professional http://www.javaspecialists.eu Tel: +30 69 75 595 262 Skype: kabutz -------------- next part -------------- An embedded message was scrubbed... From: "Dr Heinz M. Kabutz" Subject: _interrupted field visibility bug in OpenJDK 7+ Date: Wed, 07 Nov 2012 23:00:06 +0100 Size: 4784 Url: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121108/b4f3707a/_interruptedfieldvisibilitybuginOpenJDK7.eml From vladimir.kozlov at oracle.com Wed Nov 7 22:24:15 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Nov 2012 22:24:15 -0800 Subject: [Fwd: _interrupted field visibility bug in OpenJDK 7+] In-Reply-To: <509B4C12.5060705@javaspecialists.eu> References: <509B4C12.5060705@javaspecialists.eu> Message-ID: Thank you, Heinz Yes, we are looking on this problem. Regards, Vladimir On Nov 7, 2012, at 10:07 PM, Dr Heinz M. Kabutz wrote: > In case you have not seen, there is a discussion on concurrency-interest (http://tinyurl.com/bofu46j) about a new bug that we discovered where code dealing with isInterrupted() is not correctly optimized, leading to issues where a thread does not see its interrupted status change. > > This has been submitted as a bug > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003135 > > Regards > > Heinz > -- > Dr Heinz M. Kabutz (PhD CompSci) > Author of "The Java(tm) Specialists' Newsletter" > Sun Java Champion > IEEE Certified Software Development Professional > http://www.javaspecialists.eu > Tel: +30 69 75 595 262 > Skype: kabutz > > From: "Dr Heinz M. Kabutz" > Subject: _interrupted field visibility bug in OpenJDK 7+ > Date: November 7, 2012 2:00:06 PM PST > To: concurrency-interest at cs.oswego.edu > > > During a hands-on session today of my new Concurrency Specialist Course, one of my students discovered what we think might be an interesting and potentially serious bug in the JVM. It seems that the Server HotSpot in OpenJDK 7 may sometimes hoist the value of the _interrupted field. This is interesting, since the value is not stored in Java, but rather in the OSThread.hpp file in the jint _interrupted field. It is also pretty serious, because it means we cannot rely on the interrupted status in order to shut down threads. This will affect Future.cancel(), ExecutorService.shutdownNow() and a whole bunch of other mechanisms that use interruptions to cooperatively cancel tasks. (Obviously the exercise was more involved than the code presented in this email, after all the course is aimed at intermediate to advanced Java developers. So please don't expect that this won't happen in your code - I've just taken away unnecessary code until we can see the bug without any of the paraphernalia that might distract.) > > First off, some code that works as expected. As soon as you interrupt the thread, it breaks out of the while() loop and exits: > > public void think() { > while (true) { > if (Thread.currentThread().isInterrupted()) break; > } > System.out.println("We're done thinking"); > } > > However, if you extract the "Thread.currentThread().isInterrupted()" into a separate method, then that might be optimized by HotSpot to always return false and the code then never ends: > > public void think() { > while (true) { > if (checkInterruptedStatus()) break; > } > System.out.println("We're done thinking"); > } > > private boolean checkInterruptedStatus() { > return Thread.currentThread().isInterrupted(); > } > > My assumption is that the checkInterruptedStatus() method is aggressively optimized and then the actual status is not read again. This does not happen with the client hotspot and also not with Java 1.6.0_37. It does happen with the 1.8 EA that I've got on my MacBook Pro. The student was using a Windows machine, so this not just a Mac problem. > Here is the complete code: > > public class InterruptedVisibilityTest { > public void think() { > while (true) { > if (checkInterruptedStatus()) break; > } > System.out.println("We're done thinking"); > } > > private boolean checkInterruptedStatus() { > return Thread.currentThread().isInterrupted(); > } > > public static void main(String[] args) throws InterruptedException { > final InterruptedVisibilityTest test = > new InterruptedVisibilityTest(); > Thread thinkerThread = new Thread("Thinker") { > public void run() { > test.think(); > } > }; > thinkerThread.start(); > Thread.sleep(500); > thinkerThread.interrupt(); > long timeOfInterruption = System.currentTimeMillis(); > thinkerThread.join(500); > if (thinkerThread.isAlive()) { > System.err.println("Thinker did not shut down within 500ms"); > System.err.println("Error in Java Virtual Machine!"); > System.err.println("Interrupted: " + thinkerThread.isInterrupted()); > System.err.println(); > System.err.println("(Let's see if the thread ever dies and how long it takes)"); > while (thinkerThread.isAlive()) { > thinkerThread.join(1000); > if (thinkerThread.isAlive()) { > System.err.println(" ... still waiting"); > } > } > } > System.err.println("Finally, the thread has died - that took " + > (System.currentTimeMillis() - timeOfInterruption) + "ms"); > } > } > > As I said, the original code was more involved, but this demonstrates the essentials. I hope some of you might be able to take a look at what's going on. > > Regards > > Heinz > -- > Dr Heinz M. Kabutz (PhD CompSci) > Author of "The Java(tm) Specialists' Newsletter" > Sun Java Champion > IEEE Certified Software Development Professional > http://www.javaspecialists.eu > Tel: +30 69 75 595 262 > Skype: kabutz > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121107/a15226d9/attachment-0001.html From nils.eliasson at oracle.com Thu Nov 8 07:15:26 2012 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 08 Nov 2012 16:15:26 +0100 Subject: Review Request (S): 8002364 - compile_id is not unique when CICountOSR is set Message-ID: <509BCC8E.600@oracle.com> When developing the compiler events for JFR i noticed that the compile IDs where not always unique. And that guarantee is needed. The CICountOSR flag (default in develop) makes the compile_id be used as an osr_id instead. This can cause confusion when used with JFR. And it is never wrong to have a dependable unique id. I suggest this change that makes us always have unique compile ID while keeping the osr_id separately. http://cr.openjdk.java.net/~neliasso/8002364/webrev.03/ This has the consequences: Flag CICountOSR is removed - the functionality is there always anyway. Flag CIBreakAtOSR, CIStartOSR and CIStopOSR is still in use but the osr ID isn't printed in the compilation log, so it may be a little harder to use. I considered removing the CIBreakAtOSR flag and then there was no need for saving the osr_id after the CIStart/StopOSR check. That would make the code a bit nicer (and save a field). I have kept the osr_id increment behavior making the code slightly more complex. //Nils From vladimir.kozlov at oracle.com Thu Nov 8 08:54:54 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 8 Nov 2012 08:54:54 -0800 Subject: Review Request (S): 8002364 - compile_id is not unique when CICountOSR is set In-Reply-To: <509BCC8E.600@oracle.com> References: <509BCC8E.600@oracle.com> Message-ID: <7A5782BB-F2B6-47C4-8622-FAA2836D8677@oracle.com> On Nov 8, 2012, at 7:15 AM, Nils Eliasson wrote: > When developing the compiler events for JFR i noticed that the compile IDs where not always unique. And that guarantee is needed. The CICountOSR flag (default in develop) makes the compile_id be used as an osr_id instead. This can cause confusion when used with JFR. And it is never wrong to have a dependable unique id. It is not true. Vladimir I. changed the flag default value to false in recent changes for 7177003. Also in our developing environment we will not use JFR but we want a functionality which help us debug problems. So I would like to keep the flag and have a separate number in output (tty and LogCompilation log) for osr_id if the flag is on. So I agree with your general changes but you need to add more code. To have separate osr_id is useful because usually it is more consistent between different runs than compile_id (OSR compilations are not frequent). Thanks, Vladimir > > I suggest this change that makes us always have unique compile ID while keeping the osr_id separately. > > http://cr.openjdk.java.net/~neliasso/8002364/webrev.03/ > > This has the consequences: > Flag CICountOSR is removed - the functionality is there always anyway. > Flag CIBreakAtOSR, CIStartOSR and CIStopOSR is still in use but the osr ID isn't printed in the compilation log, so it may be a little harder to use. > > I considered removing the CIBreakAtOSR flag and then there was no need for saving the osr_id after the CIStart/StopOSR check. That would make the code a bit nicer (and save a field). > I have kept the osr_id increment behavior making the code slightly more complex. > > //Nils From vladimir.kozlov at oracle.com Thu Nov 8 10:02:43 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 8 Nov 2012 10:02:43 -0800 Subject: Review Request (S): 8002364 - compile_id is not unique when CICountOSR is set In-Reply-To: <7A5782BB-F2B6-47C4-8622-FAA2836D8677@oracle.com> References: <509BCC8E.600@oracle.com> <7A5782BB-F2B6-47C4-8622-FAA2836D8677@oracle.com> Message-ID: <061ABEB6-981A-4ADF-9A22-D09B200B0BF7@oracle.com> On Nov 8, 2012, at 8:54 AM, Vladimir Kozlov wrote: > > On Nov 8, 2012, at 7:15 AM, Nils Eliasson wrote: > >> When developing the compiler events for JFR i noticed that the compile IDs where not always unique. And that guarantee is needed. The CICountOSR flag (default in develop) makes the compile_id be used as an osr_id instead. This can cause confusion when used with JFR. And it is never wrong to have a dependable unique id. > > It is not true. Vladimir I. changed the flag default value to false in recent changes for 7177003. > Also in our developing environment we will not use JFR but we want a functionality which help us debug problems. So I would like to keep the flag and have a separate number in output (tty and LogCompilation log) for osr_id if the flag is on. So I agree with your general changes but you need to add more code. After thinking about this more, maybe we should always print osr_id as an additional number then we don't need CICountOSR flag. In this case you only need to add code to print this number in PrintCompilation and LogCompilation. Vladimir > > To have separate osr_id is useful because usually it is more consistent between different runs than compile_id (OSR compilations are not frequent). > > Thanks, > Vladimir > >> >> I suggest this change that makes us always have unique compile ID while keeping the osr_id separately. >> >> http://cr.openjdk.java.net/~neliasso/8002364/webrev.03/ >> >> This has the consequences: >> Flag CICountOSR is removed - the functionality is there always anyway. >> Flag CIBreakAtOSR, CIStartOSR and CIStopOSR is still in use but the osr ID isn't printed in the compilation log, so it may be a little harder to use. >> >> I considered removing the CIBreakAtOSR flag and then there was no need for saving the osr_id after the CIStart/StopOSR check. That would make the code a bit nicer (and save a field). >> I have kept the osr_id increment behavior making the code slightly more complex. >> >> //Nils > From christian.thalinger at oracle.com Thu Nov 8 11:31:11 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 8 Nov 2012 11:31:11 -0800 Subject: RFR: 6830717: replay of compilations would help with debugging In-Reply-To: <50997616.9030301@oracle.com> References: <50997616.9030301@oracle.com> Message-ID: On Nov 6, 2012, at 12:41 PM, yumin.qi at oracle.com wrote: > Forget to cc to open list. > > Thanks > Yumin > > -------- Original Message -------- > Subject: Re: RFR: 6830717: replay of compilations would help with debugging > Date: Tue, 06 Nov 2012 10:53:26 -0800 > From: yumin.qi at oracle.com > Organization: Oracle Corporation > To: serguei.spitsyn at oracle.com > CC: Christian Thalinger , Vladimir Kozlov , Coleen Phillimore > > Hi, Serguei and all > > Made changes according to Serguei's suggestion, but could not change ci.dumpReplayData forward call to .dumpReplayData since there is some data is not consistent in compiler interface after runtime. > Also changes to move dumpReplayData up to base class (not VMObject), so can save changes to subclasses. > > http://cr.openjdk.java.net/~minqi/6830717 src/share/vm/utilities/array.hpp: ! T at(int i) const { assert(i >= 0 && i< _length, "Array out of range"); return _data[i]; } Could you change the asserts to: ! T at(int i) const { assert(i >= 0 && i< _length, err_msg_res("oob: 0 <= %d < %d", i, _length)); return _data[i]; } src/share/vm/utilities/vmError.cpp: + static bool skip_Replay = false; We try to use lowercase variable names: + static bool skip_replay = false; Otherwise this looks good. -- Chris > > Please have a look and comment. > > Thanks > Yumin > > > > On 10/26/2012 3:57 PM, serguei.spitsyn at oracle.com wrote: >> Continue for C++ files (VM code) ... >> >> src/share/vm/utilities/utf8.cpp >> 165 // returns the quoted ascii length of a 0-terminated utf8 string >> 166 int UTF8::quoted_ascii_length(const char* utf8_str, int utf8_length) { >> 167 const char *ptr = (const char *)utf8_str; >> >> . . . >> >> 183 void UTF8::as_quoted_ascii(const char* utf8_str, char* buf, int buflen) { >> 184 const char *ptr = (const char *)utf8_str; >> >> . . . >> >> 203 const char* UTF8::from_quoted_ascii(const char* quoted_ascii_str) { >> 204 const char *ptr = (const char *)quoted_ascii_str; >> No need to cast to (const char*) as arguments are already const char*. >> >> >> src/share/vm/ci/ciReplay.cpp >> 603 if (field_signature[1] == 'B') { >> 604 value = oopFactory::new_byteArray(length, CHECK); >> 605 } else if (strcmp(field_signature, "[Z") == 0) { >> 606 value = oopFactory::new_boolArray(length, CHECK); >> 607 } else if (strcmp(field_signature, "[C") == 0) { >> 608 value = oopFactory::new_charArray(length, CHECK); >> 609 } else if (strcmp(field_signature, "[S") == 0) { >> 610 value = oopFactory::new_shortArray(length, CHECK); >> 611 } else if (strcmp(field_signature, "[F") == 0) { >> 612 value = oopFactory::new_singleArray(length, CHECK); >> 613 } else if (strcmp(field_signature, "[D") == 0) { >> 614 value = oopFactory::new_doubleArray(length, CHECK); >> 615 } else if (strcmp(field_signature, "[I") == 0) { >> 616 value = oopFactory::new_intArray(length, CHECK); >> 617 } else if (strcmp(field_signature, "[J") == 0) { >> 618 value = oopFactory::new_longArray(length, CHECK); >> 619 } else if (field_signature[0] == '[' && field_signature[1] == 'L') { >> 620 KlassHandle kelem = resolve_klass(field_signature + 1, CHECK); >> 621 value = oopFactory::new_objArray(kelem(), length, CHECK); >> 622 } else { >> 623 report_error("unhandled array staticfield"); >> 624 } >> 625 } >> >> As Christian already noted this can be rewritten like this: >> >> switch (field_signature[1]) { >> case 'B': value = oopFactory::new_byteArray(length, CHECK); >> case 'Z': value = oopFactory::new_boolArray(length, CHECK); >> case 'C': value = oopFactory::new_charArray(length, CHECK); >> case 'S': value = oopFactory::new_shortArray(length, CHECK); >> case 'F': value = oopFactory::new_singleArray(length, CHECK); >> case 'D': value = oopFactory::new_doubleArray(length, CHECK); >> case 'I': value = oopFactory::new_intArray(length, CHECK); >> case 'J': value = oopFactory::new_longArray(length, CHECK); >> case 'L': >> KlassHandle kelem = resolve_klass(field_signature + 1, CHECK); >> value = oopFactory::new_objArray(kelem(), length, CHECK); >> default: >> report_error("unhandled array staticfield"); >> } >> >> Almost the same comment about the lines 629-667. >> >> >> These are the only comments I have. >> >> >> Thanks, >> Serguei >> >> >> On 10/26/12 12:37 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Yumin, >>> >>> agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java >>> >>> 778 // This is used to dump replay data from ciInstanceKlass, ciMehtodData etc >>> Typo: ciMehtodData =>ciMethodData >>> >>> 777 new Command("dumpreplaydata", "dumpreplaydata {
| -a | id }", false) { >>> What is id? Is it a thread name? If so, would it better to say: thread_name or thread_id? >>> Also, do we need angle brackets: {
| -a | } ? >>> >>> agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java >>> >>> 137 sun.jvm.hotspot.oops.OopField bf = (OopField)f; >>> The sun.jvm.hotspot.oops package os imported, so the short type name OopField can be used. >>> No conflicts are expected, right? Otherwise, the "(OopField)f" would not be correct. >>> >>> agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java >>> >>> 97 OopUtilities.escapeString(method.getName().asString()) + " " + method.getSignature().asString() + " " + >>> 98 method.getInvocationCounter() + " " + >>> 99 method.getBackedgeCounter() + " " + >>> 100 interpreterInvocationCount() + " " + >>> 101 interpreterThrowoutCount() + " " + >>> >>> It is better to break down the line 97 into two lines. >>> It would be shorter and more consistent with the lines 98-101. >>> >>> >>> agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java >>> >>> 1055 sun.jvm.hotspot.oops.OopField bf = (OopField)f; >>> The same as for ciInstanceKlass.java above. >>> >>> Could you introduce an utility method printFieldValue(Field f), so that the same code is shared with ciInstanceKlass.java? >>> It feels that the code is the same. >>> >>> >>> agent/src/share/classes/sun/jvm/hotspot/oops/Method.java >>> >>> 368 OopUtilities.escapeString(getName().asString()) + " " + getSignature().asString() + " " + >>> The same as for the ciMethod.java above. >>> >>> >>> agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java >>> >>> It looks like this new code can be shared with ciMethodData.java. >>> You also may want to look at other files if similat sharing approach can be used. >>> We can compare all ciXXX.java with XXX.java. >>> >>> >>> agent/doc/clhsdb.html >>> >>> 52 dumpreplaydata
| -a | id [>replay.txt] dump replay data into a file >>> The same comment as for the CommandProcessor.java. >>> >>> >>> agent/doc/c2replay.html >>> >>> 17 clhsdb>dumpreplaydata
| -a | id > replay.txt >>> The same comment as for the CommandProcessor.java. >>> >>> >>> I've reviewed only java files so far and decided to provide my feedback early. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/26/12 9:33 AM, Yumin Qi wrote: >>>> Hi, >>>> >>>> I need your help to have a second look at the changes based on meta changes --- if OK will do push. >>>> >>>> Thanks >>>> Yumin >>>> >>>> On 8/13/2012 5:02 PM, Christian Thalinger wrote: >>>>> On Aug 6, 2012, at 2:40 PM, yumin.qi at oracle.com wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Please give your comments of the changes about >>>>>> 6830717: replay of compilations would help with debugging. >>>>>> http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 >>>>>> >>>>>> Sometime jvm crashes in the process of compilation or in compiled method. To reproduce the compilation process in debug JVM is helpful for quickly identifying root cause. >>>>>> To do recompilation, we collect data by using of SA (Serviceability Agent) to extract application and system class data from core file. Those information includes nmethod, methodOop, methodDataOop, instanceKlass and corresponding ci counterparts. >>>>>> With reconfiguring similar (not exactly same) compiling environment as in the core file, try to compile again the failed java methods. >>>>>> >>>>>> contributed by Tom R (never). webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~minqi/6830717/ >>>>> src/share/vm/ci/ciReplay.cpp: >>>>> >>>>> 603 if (strcmp(field_signature, "[B") == 0) { >>>>> 604 oop value = oopFactory::new_byteArray(length, CHECK); >>>>> 605 java_mirror->obj_field_put(fd.offset(), value); >>>>> 606 } else if (strcmp(field_signature, "[Z") == 0) { >>>>> 607 oop value = oopFactory::new_boolArray(length, CHECK); >>>>> 608 java_mirror->obj_field_put(fd.offset(), value); >>>>> 609 } else if (strcmp(field_signature, "[C") == 0) { >>>>> 610 oop value = oopFactory::new_charArray(length, CHECK); >>>>> 611 java_mirror->obj_field_put(fd.offset(), value); >>>>> 612 } else if (strcmp(field_signature, "[S") == 0) { >>>>> 613 oop value = oopFactory::new_shortArray(length, CHECK); >>>>> 614 java_mirror->obj_field_put(fd.offset(), value); >>>>> 615 } else if (strcmp(field_signature, "[F") == 0) { >>>>> 616 oop value = oopFactory::new_singleArray(length, CHECK); >>>>> 617 java_mirror->obj_field_put(fd.offset(), value); >>>>> 618 } else if (strcmp(field_signature, "[D") == 0) { >>>>> 619 oop value = oopFactory::new_doubleArray(length, CHECK); >>>>> 620 java_mirror->obj_field_put(fd.offset(), value); >>>>> 621 } else if (strcmp(field_signature, "[I") == 0) { >>>>> 622 oop value = oopFactory::new_intArray(length, CHECK); >>>>> 623 java_mirror->obj_field_put(fd.offset(), value); >>>>> 624 } else if (strcmp(field_signature, "[J") == 0) { >>>>> 625 oop value = oopFactory::new_longArray(length, CHECK); >>>>> 626 java_mirror->obj_field_put(fd.offset(), value); >>>>> 627 } else if (field_signature[0] == '['&& field_signature[1] == 'L') { >>>>> >>>>> Can't we switch on the second character? And move this call: >>>>> >>>>> 630 java_mirror->obj_field_put(fd.offset(), value); >>>>> >>>>> out of the switch? >>>>> >>>>> 637 if (strcmp(field_signature, "I") == 0) { >>>>> 638 int value = atoi(string_value); >>>>> 639 java_mirror->int_field_put(fd.offset(), value); >>>>> 640 } else if (strcmp(field_signature, "B") == 0) { >>>>> 641 int value = atoi(string_value); >>>>> 642 java_mirror->byte_field_put(fd.offset(), value); >>>>> 643 } else if (strcmp(field_signature, "C") == 0) { >>>>> 644 int value = atoi(string_value); >>>>> 645 java_mirror->char_field_put(fd.offset(), value); >>>>> 646 } else if (strcmp(field_signature, "S") == 0) { >>>>> 647 int value = atoi(string_value); >>>>> 648 java_mirror->short_field_put(fd.offset(), value); >>>>> 649 } else if (strcmp(field_signature, "Z") == 0) { >>>>> 650 int value = atol(string_value); >>>>> 651 java_mirror->bool_field_put(fd.offset(), value); >>>>> 652 } else if (strcmp(field_signature, "J") == 0) { >>>>> 653 jlong value; >>>>> 654 if (sscanf(string_value, INT64_FORMAT,&value) != 1) { >>>>> 655 fprintf(stderr, "Error parsing long: %s\n", string_value); >>>>> 656 return; >>>>> 657 } >>>>> 658 java_mirror->long_field_put(fd.offset(), value); >>>>> 659 } else if (strcmp(field_signature, "F") == 0) { >>>>> 660 float value = atof(string_value); >>>>> 661 java_mirror->float_field_put(fd.offset(), value); >>>>> 662 } else if (strcmp(field_signature, "D") == 0) { >>>>> 663 double value = atof(string_value); >>>>> 664 java_mirror->double_field_put(fd.offset(), value); >>>>> 665 } else if (strcmp(field_signature, "Ljava/lang/String;") == 0) { >>>>> 666 Handle value = java_lang_String::create_from_str(string_value, CHECK); >>>>> 667 java_mirror->obj_field_put(fd.offset(), value()); >>>>> 668 } else if (field_signature[0] == 'L') { >>>>> >>>>> Same here (not the put though)? >>>>> >>>>> Otherwise it looks good. >>>>> >>>>> -- Chris >>>>> >>>>>> Thanks >>>>>> Yumin >>> >> From yumin.qi at oracle.com Thu Nov 8 12:29:48 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Thu, 08 Nov 2012 12:29:48 -0800 Subject: RFR: 6830717: replay of compilations would help with debugging In-Reply-To: References: <50997616.9030301@oracle.com> Message-ID: <509C163C.7030702@oracle.com> Thanks for the review. Yumin On 11/8/2012 11:31 AM, Christian Thalinger wrote: > On Nov 6, 2012, at 12:41 PM, yumin.qi at oracle.com wrote: > >> Forget to cc to open list. >> >> Thanks >> Yumin >> >> -------- Original Message -------- >> Subject: Re: RFR: 6830717: replay of compilations would help with debugging >> Date: Tue, 06 Nov 2012 10:53:26 -0800 >> From: yumin.qi at oracle.com >> Organization: Oracle Corporation >> To: serguei.spitsyn at oracle.com >> CC: Christian Thalinger, Vladimir Kozlov, Coleen Phillimore >> >> Hi, Serguei and all >> >> Made changes according to Serguei's suggestion, but could not change ci.dumpReplayData forward call to.dumpReplayData since there is some data is not consistent in compiler interface after runtime. >> Also changes to move dumpReplayData up to base class (not VMObject), so can save changes to subclasses. >> >> http://cr.openjdk.java.net/~minqi/6830717 > src/share/vm/utilities/array.hpp: > > ! T at(int i) const { assert(i>= 0&& i< _length, "Array out of range"); return _data[i]; } > > Could you change the asserts to: > > ! T at(int i) const { assert(i>= 0&& i< _length, err_msg_res("oob: 0<= %d< %d", i, _length)); return _data[i]; } > > src/share/vm/utilities/vmError.cpp: > > + static bool skip_Replay = false; > > We try to use lowercase variable names: > > + static bool skip_replay = false; > > Otherwise this looks good. > > -- Chris > >> Please have a look and comment. >> >> Thanks >> Yumin >> >> >> >> On 10/26/2012 3:57 PM, serguei.spitsyn at oracle.com wrote: >>> Continue for C++ files (VM code) ... >>> >>> src/share/vm/utilities/utf8.cpp >>> 165 // returns the quoted ascii length of a 0-terminated utf8 string >>> 166 int UTF8::quoted_ascii_length(const char* utf8_str, int utf8_length) { >>> 167 const char *ptr = (const char *)utf8_str; >>> >>> . . . >>> >>> 183 void UTF8::as_quoted_ascii(const char* utf8_str, char* buf, int buflen) { >>> 184 const char *ptr = (const char *)utf8_str; >>> >>> . . . >>> >>> 203 const char* UTF8::from_quoted_ascii(const char* quoted_ascii_str) { >>> 204 const char *ptr = (const char *)quoted_ascii_str; >>> No need to cast to (const char*) as arguments are already const char*. >>> >>> >>> src/share/vm/ci/ciReplay.cpp >>> 603 if (field_signature[1] == 'B') { >>> 604 value = oopFactory::new_byteArray(length, CHECK); >>> 605 } else if (strcmp(field_signature, "[Z") == 0) { >>> 606 value = oopFactory::new_boolArray(length, CHECK); >>> 607 } else if (strcmp(field_signature, "[C") == 0) { >>> 608 value = oopFactory::new_charArray(length, CHECK); >>> 609 } else if (strcmp(field_signature, "[S") == 0) { >>> 610 value = oopFactory::new_shortArray(length, CHECK); >>> 611 } else if (strcmp(field_signature, "[F") == 0) { >>> 612 value = oopFactory::new_singleArray(length, CHECK); >>> 613 } else if (strcmp(field_signature, "[D") == 0) { >>> 614 value = oopFactory::new_doubleArray(length, CHECK); >>> 615 } else if (strcmp(field_signature, "[I") == 0) { >>> 616 value = oopFactory::new_intArray(length, CHECK); >>> 617 } else if (strcmp(field_signature, "[J") == 0) { >>> 618 value = oopFactory::new_longArray(length, CHECK); >>> 619 } else if (field_signature[0] == '['&& field_signature[1] == 'L') { >>> 620 KlassHandle kelem = resolve_klass(field_signature + 1, CHECK); >>> 621 value = oopFactory::new_objArray(kelem(), length, CHECK); >>> 622 } else { >>> 623 report_error("unhandled array staticfield"); >>> 624 } >>> 625 } >>> >>> As Christian already noted this can be rewritten like this: >>> >>> switch (field_signature[1]) { >>> case 'B': value = oopFactory::new_byteArray(length, CHECK); >>> case 'Z': value = oopFactory::new_boolArray(length, CHECK); >>> case 'C': value = oopFactory::new_charArray(length, CHECK); >>> case 'S': value = oopFactory::new_shortArray(length, CHECK); >>> case 'F': value = oopFactory::new_singleArray(length, CHECK); >>> case 'D': value = oopFactory::new_doubleArray(length, CHECK); >>> case 'I': value = oopFactory::new_intArray(length, CHECK); >>> case 'J': value = oopFactory::new_longArray(length, CHECK); >>> case 'L': >>> KlassHandle kelem = resolve_klass(field_signature + 1, CHECK); >>> value = oopFactory::new_objArray(kelem(), length, CHECK); >>> default: >>> report_error("unhandled array staticfield"); >>> } >>> >>> Almost the same comment about the lines 629-667. >>> >>> >>> These are the only comments I have. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/26/12 12:37 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Yumin, >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java >>>> >>>> 778 // This is used to dump replay data from ciInstanceKlass, ciMehtodData etc >>>> Typo: ciMehtodData =>ciMethodData >>>> >>>> 777 new Command("dumpreplaydata", "dumpreplaydata {
| -a | id }", false) { >>>> What is id? Is it a thread name? If so, would it better to say: thread_name or thread_id? >>>> Also, do we need angle brackets: {
| -a | } ? >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java >>>> >>>> 137 sun.jvm.hotspot.oops.OopField bf = (OopField)f; >>>> The sun.jvm.hotspot.oops package os imported, so the short type name OopField can be used. >>>> No conflicts are expected, right? Otherwise, the "(OopField)f" would not be correct. >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java >>>> >>>> 97 OopUtilities.escapeString(method.getName().asString()) + " " + method.getSignature().asString() + " " + >>>> 98 method.getInvocationCounter() + " " + >>>> 99 method.getBackedgeCounter() + " " + >>>> 100 interpreterInvocationCount() + " " + >>>> 101 interpreterThrowoutCount() + " " + >>>> >>>> It is better to break down the line 97 into two lines. >>>> It would be shorter and more consistent with the lines 98-101. >>>> >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java >>>> >>>> 1055 sun.jvm.hotspot.oops.OopField bf = (OopField)f; >>>> The same as for ciInstanceKlass.java above. >>>> >>>> Could you introduce an utility method printFieldValue(Field f), so that the same code is shared with ciInstanceKlass.java? >>>> It feels that the code is the same. >>>> >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/oops/Method.java >>>> >>>> 368 OopUtilities.escapeString(getName().asString()) + " " + getSignature().asString() + " " + >>>> The same as for the ciMethod.java above. >>>> >>>> >>>> agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java >>>> >>>> It looks like this new code can be shared with ciMethodData.java. >>>> You also may want to look at other files if similat sharing approach can be used. >>>> We can compare all ciXXX.java with XXX.java. >>>> >>>> >>>> agent/doc/clhsdb.html >>>> >>>> 52 dumpreplaydata
| -a | id [>replay.txt]dump replay data into a file >>>> The same comment as for the CommandProcessor.java. >>>> >>>> >>>> agent/doc/c2replay.html >>>> >>>> 17 clhsdb>dumpreplaydata
| -a | id> replay.txt >>>> The same comment as for the CommandProcessor.java. >>>> >>>> >>>> I've reviewed only java files so far and decided to provide my feedback early. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/26/12 9:33 AM, Yumin Qi wrote: >>>>> Hi, >>>>> >>>>> I need your help to have a second look at the changes based on meta changes --- if OK will do push. >>>>> >>>>> Thanks >>>>> Yumin >>>>> >>>>> On 8/13/2012 5:02 PM, Christian Thalinger wrote: >>>>>> On Aug 6, 2012, at 2:40 PM, yumin.qi at oracle.com wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Please give your comments of the changes about >>>>>>> 6830717: replay of compilations would help with debugging. >>>>>>> http://monaco.sfbay.sun.com/detail.jsf?cr=6830717 >>>>>>> >>>>>>> Sometime jvm crashes in the process of compilation or in compiled method. To reproduce the compilation process in debug JVM is helpful for quickly identifying root cause. >>>>>>> To do recompilation, we collect data by using of SA (Serviceability Agent) to extract application and system class data from core file. Those information includes nmethod, methodOop, methodDataOop, instanceKlass and corresponding ci counterparts. >>>>>>> With reconfiguring similar (not exactly same) compiling environment as in the core file, try to compile again the failed java methods. >>>>>>> >>>>>>> contributed by Tom R (never). webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~minqi/6830717/ >>>>>> src/share/vm/ci/ciReplay.cpp: >>>>>> >>>>>> 603 if (strcmp(field_signature, "[B") == 0) { >>>>>> 604 oop value = oopFactory::new_byteArray(length, CHECK); >>>>>> 605 java_mirror->obj_field_put(fd.offset(), value); >>>>>> 606 } else if (strcmp(field_signature, "[Z") == 0) { >>>>>> 607 oop value = oopFactory::new_boolArray(length, CHECK); >>>>>> 608 java_mirror->obj_field_put(fd.offset(), value); >>>>>> 609 } else if (strcmp(field_signature, "[C") == 0) { >>>>>> 610 oop value = oopFactory::new_charArray(length, CHECK); >>>>>> 611 java_mirror->obj_field_put(fd.offset(), value); >>>>>> 612 } else if (strcmp(field_signature, "[S") == 0) { >>>>>> 613 oop value = oopFactory::new_shortArray(length, CHECK); >>>>>> 614 java_mirror->obj_field_put(fd.offset(), value); >>>>>> 615 } else if (strcmp(field_signature, "[F") == 0) { >>>>>> 616 oop value = oopFactory::new_singleArray(length, CHECK); >>>>>> 617 java_mirror->obj_field_put(fd.offset(), value); >>>>>> 618 } else if (strcmp(field_signature, "[D") == 0) { >>>>>> 619 oop value = oopFactory::new_doubleArray(length, CHECK); >>>>>> 620 java_mirror->obj_field_put(fd.offset(), value); >>>>>> 621 } else if (strcmp(field_signature, "[I") == 0) { >>>>>> 622 oop value = oopFactory::new_intArray(length, CHECK); >>>>>> 623 java_mirror->obj_field_put(fd.offset(), value); >>>>>> 624 } else if (strcmp(field_signature, "[J") == 0) { >>>>>> 625 oop value = oopFactory::new_longArray(length, CHECK); >>>>>> 626 java_mirror->obj_field_put(fd.offset(), value); >>>>>> 627 } else if (field_signature[0] == '['&& field_signature[1] == 'L') { >>>>>> >>>>>> Can't we switch on the second character? And move this call: >>>>>> >>>>>> 630 java_mirror->obj_field_put(fd.offset(), value); >>>>>> >>>>>> out of the switch? >>>>>> >>>>>> 637 if (strcmp(field_signature, "I") == 0) { >>>>>> 638 int value = atoi(string_value); >>>>>> 639 java_mirror->int_field_put(fd.offset(), value); >>>>>> 640 } else if (strcmp(field_signature, "B") == 0) { >>>>>> 641 int value = atoi(string_value); >>>>>> 642 java_mirror->byte_field_put(fd.offset(), value); >>>>>> 643 } else if (strcmp(field_signature, "C") == 0) { >>>>>> 644 int value = atoi(string_value); >>>>>> 645 java_mirror->char_field_put(fd.offset(), value); >>>>>> 646 } else if (strcmp(field_signature, "S") == 0) { >>>>>> 647 int value = atoi(string_value); >>>>>> 648 java_mirror->short_field_put(fd.offset(), value); >>>>>> 649 } else if (strcmp(field_signature, "Z") == 0) { >>>>>> 650 int value = atol(string_value); >>>>>> 651 java_mirror->bool_field_put(fd.offset(), value); >>>>>> 652 } else if (strcmp(field_signature, "J") == 0) { >>>>>> 653 jlong value; >>>>>> 654 if (sscanf(string_value, INT64_FORMAT,&value) != 1) { >>>>>> 655 fprintf(stderr, "Error parsing long: %s\n", string_value); >>>>>> 656 return; >>>>>> 657 } >>>>>> 658 java_mirror->long_field_put(fd.offset(), value); >>>>>> 659 } else if (strcmp(field_signature, "F") == 0) { >>>>>> 660 float value = atof(string_value); >>>>>> 661 java_mirror->float_field_put(fd.offset(), value); >>>>>> 662 } else if (strcmp(field_signature, "D") == 0) { >>>>>> 663 double value = atof(string_value); >>>>>> 664 java_mirror->double_field_put(fd.offset(), value); >>>>>> 665 } else if (strcmp(field_signature, "Ljava/lang/String;") == 0) { >>>>>> 666 Handle value = java_lang_String::create_from_str(string_value, CHECK); >>>>>> 667 java_mirror->obj_field_put(fd.offset(), value()); >>>>>> 668 } else if (field_signature[0] == 'L') { >>>>>> >>>>>> Same here (not the put though)? >>>>>> >>>>>> Otherwise it looks good. >>>>>> >>>>>> -- Chris >>>>>> >>>>>>> Thanks >>>>>>> Yumin From bharadwaj.yadavalli at oracle.com Thu Nov 8 13:20:21 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 08 Nov 2012 16:20:21 -0500 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> Message-ID: <509C2215.4010302@oracle.com> Addressed comments on my previous RFR. Changes athttp://cr.openjdk.java.net/~bharadwaj/7092905/webrev_02/ These changes are made to keep an (almost) accurate running count of the reachable (live) flow graph nodes. This will result in a more realistic node count for various phases of C2 to decide on whether to proceed with optimizations or not. Prior to these changes, C2 bails out of compilation based on the number of nodes created which typically larger than the number of reachable (live) nodes. From vladimir.kozlov at oracle.com Thu Nov 8 16:54:56 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 08 Nov 2012 16:54:56 -0800 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <509C2215.4010302@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> Message-ID: <509C5460.4050608@oracle.com> VerifyIdealNodeCount flag should be also notproduct since it is used only in debug VM. The next assert is not needed because it duplicates assert in live_nodes(): bool check_node_count(uint margin, const char* reason) { if (unique() + margin > (uint)MaxNodeLimit) { + assert(dead_node_count() <= unique(), "number of dead nodes more than created"); Also don't split the assert in live_nodes() into 2 lines and maybe use err_msg_res() to print _unique and _dead_node_count values. Also I think it should return unsigned int type value as unique() method. Second Compile() constructor does not set _dead_node_count(0). count_live_nodes_by_graph_walk() and NotANode() methods are now used only in debug code so put them under #ifdef ASSERT. print_missing_nodes() should call count_live_nodes_by_graph_walk() instead of duplicating code. And it should print to _log itself. TracePhase() code will have only call to it: 3133 if (VerifyIdealNodeCount) { 3134 Compile::current()->print_missing_nodes(); 3135 } And do not check VerifyIdealNodeCount in print_missing_nodes() to allow call it in debugger without VerifyIdealNodeCount set. I think VerifyIdealNodeCount code should be in ~TracePhase() (end of phase). Thanks, Vladimir Bharadwaj Yadavalli wrote: > Addressed comments on my previous RFR. Changes > at > http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_02/ > > These changes are made to keep an (almost) accurate running count of the > reachable (live) flow graph nodes. This will result in a more realistic > node count for various phases of C2 to decide on whether to proceed with > optimizations or not. Prior to these changes, C2 bails out of > compilation based on the number of nodes created which typically larger > than the number of reachable (live) nodes. > From john.coomes at oracle.com Fri Nov 9 01:51:15 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 09 Nov 2012 09:51:15 +0000 Subject: hg: hsx/hotspot-comp: 7 new changesets Message-ID: <20121109095116.39AFC4788F@hg.openjdk.java.net> Changeset: dd1a80efa7cf Author: anthony Date: 2012-10-30 15:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/dd1a80efa7cf 8001764: vsvars.sh should support VS2012 Summary: Update the vsvars.sh script to support VS2012 Reviewed-by: ohair, tbell ! make/scripts/vsvars.sh Changeset: fc61be4ff6ae Author: lana Date: 2012-10-31 09:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/fc61be4ff6ae Merge ! make/scripts/vsvars.sh Changeset: 65dca75b2a26 Author: lana Date: 2012-11-02 17:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/65dca75b2a26 Merge Changeset: e20ffc02e437 Author: erikj Date: 2012-11-03 16:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/e20ffc02e437 8002183: Increased max number of paths to list in ListPathsSafely to 16000. Reviewed-by: ohair ! common/makefiles/MakeBase.gmk Changeset: ed9e5635fc80 Author: erikj Date: 2012-11-03 16:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/ed9e5635fc80 8002220: build-infra: update for mac, solaris 11 issues 8002184: Fixed exclude and includes for jarsigner in new build Reviewed-by: ohair ! common/autoconf/basics.m4 ! common/autoconf/basics_windows.m4 ! common/autoconf/compare.sh.in ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl ! common/makefiles/JavaCompilation.gmk Changeset: 1c8370a55b30 Author: katleman Date: 2012-11-07 15:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/1c8370a55b30 Merge Changeset: 838a64965131 Author: katleman Date: 2012-11-08 11:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/838a64965131 Added tag jdk8-b64 for changeset 1c8370a55b30 ! .hgtags From john.coomes at oracle.com Fri Nov 9 01:51:20 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 09 Nov 2012 09:51:20 +0000 Subject: hg: hsx/hotspot-comp/corba: 4 new changesets Message-ID: <20121109095123.E122E47890@hg.openjdk.java.net> Changeset: 643e7612cf6d Author: ohrstrom Date: 2012-10-29 14:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/643e7612cf6d 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK. Reviewed-by: alanb, wetmore ! src/share/classes/com/sun/corba/se/impl/util/IdentityHashtable.java + src/share/classes/com/sun/corba/se/impl/util/IdentityHashtableEntry.java Changeset: aac74d377a03 Author: lana Date: 2012-10-30 23:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/aac74d377a03 Merge Changeset: 54d599a5b4aa Author: lana Date: 2012-11-02 17:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/54d599a5b4aa Merge Changeset: 5132f7900a8f Author: katleman Date: 2012-11-08 11:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/5132f7900a8f Added tag jdk8-b64 for changeset 54d599a5b4aa ! .hgtags From john.coomes at oracle.com Fri Nov 9 01:51:27 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 09 Nov 2012 09:51:27 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b64 for changeset 27ab79568c34 Message-ID: <20121109095132.D77E447891@hg.openjdk.java.net> Changeset: 5cf3c69a93d6 Author: katleman Date: 2012-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/5cf3c69a93d6 Added tag jdk8-b64 for changeset 27ab79568c34 ! .hgtags From john.coomes at oracle.com Fri Nov 9 01:51:36 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 09 Nov 2012 09:51:36 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b64 for changeset 5ded18a14bcc Message-ID: <20121109095140.1942347892@hg.openjdk.java.net> Changeset: fbe54291c9d3 Author: katleman Date: 2012-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/fbe54291c9d3 Added tag jdk8-b64 for changeset 5ded18a14bcc ! .hgtags From john.coomes at oracle.com Fri Nov 9 02:04:38 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 09 Nov 2012 10:04:38 +0000 Subject: hg: hsx/hotspot-comp/langtools: 17 new changesets Message-ID: <20121109100516.22C5A47894@hg.openjdk.java.net> Changeset: 78962d89f283 Author: jjg Date: 2012-10-23 13:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/78962d89f283 8000741: refactor javadoc to use abstraction to handle relative paths Reviewed-by: darcy ! src/share/classes/com/sun/javadoc/SerialFieldTag.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletConstants.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/SerializedForm.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testPackagePage/TestPackagePage.java Changeset: 4a1c57a1c410 Author: jjg Date: 2012-10-23 13:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/4a1c57a1c410 8000416: refactor javadoc to provide and use an abstraction for relative URIs Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocLink.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java Changeset: c002fdee76fd Author: jjg Date: 2012-10-25 11:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c002fdee76fd 7200915: convert TypeTags from a series of small ints to an enum Reviewed-by: jjg, mcimadamore Contributed-by: vicente.romero at oracle.com ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java + src/share/classes/com/sun/tools/javac/code/TypeTag.java - src/share/classes/com/sun/tools/javac/code/TypeTags.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/UninitializedType.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/util/Constants.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/AnnotationValueImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterizedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! test/tools/javac/6889255/T6889255.java ! test/tools/javac/tree/MakeLiteralTest.java Changeset: ea2616a6bd01 Author: jjg Date: 2012-10-25 13:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ea2616a6bd01 6725230: Java Compilation with Jsr199 ignores Class-Path in manifest Reviewed-by: jjg, mcimadamore Contributed-by: vicente.romero at oracle.com ! src/share/classes/com/sun/tools/javac/file/Locations.java + test/tools/javac/Paths/TestCompileJARInClassPath.java Changeset: 217c265158fe Author: jjg Date: 2012-10-26 13:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/217c265158fe 8001219: Clean up use of URLs in javadoc Extern class Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java Changeset: e6cb81683ffe Author: jjg Date: 2012-10-26 16:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/e6cb81683ffe 8001229: refactor javac so that ct.sym is just used for javac, not all clients of JavacFileManager Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javah/JavahFileManager.java ! src/share/classes/com/sun/tools/javah/JavahTask.java ! src/share/classes/com/sun/tools/javap/JavapFileManager.java Changeset: 64fce9f95b1d Author: jjg Date: 2012-10-26 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/64fce9f95b1d 8001714: add missing tests for 7199925 Reviewed-by: darcy + test/tools/javac/annotations/repeatingAnnotations/ClassReaderDefault.java + test/tools/javac/annotations/repeatingAnnotations/SeparateCompile.java Changeset: 384f7a4beae7 Author: jjg Date: 2012-10-26 18:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/384f7a4beae7 8001717: TypeTags cleanup breaks GenStubs Reviewed-by: jjh ! make/tools/genstubs/GenStubs.java Changeset: a65971893c50 Author: rfield Date: 2012-10-29 10:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a65971893c50 8000694: Add generation of lambda implementation code: invokedynamic call, lambda method, adaptor methods Summary: Add lambda implementation code with calling/supporting code elsewhere in the compiler Reviewed-by: mcimadamore, jjg ! src/share/classes/com/sun/tools/javac/code/Symtab.java + src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: 23fe1a96bc0f Author: jjg Date: 2012-10-30 10:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/23fe1a96bc0f 8001929: fix doclint errors in langtools doc comments Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java Changeset: 27f7952eea3c Author: lana Date: 2012-10-31 08:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/27f7952eea3c Merge Changeset: b980e8e6aabf Author: jjg Date: 2012-10-31 13:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b980e8e6aabf 8001664: refactor javadoc to use abstraction to handle files Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! test/com/sun/javadoc/testDocFileDir/TestDocFileDir.java Changeset: bf54daa9dcd8 Author: ohrstrom Date: 2012-11-01 10:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/bf54daa9dcd8 7153951: Add new lint option -Xlint:auxiliaryclass Reviewed-by: jjg, mcimadamore, forax ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/AuxiliaryClassWarning/ClassUsingAuxiliary.java + test/tools/javac/diags/examples/AuxiliaryClassWarning/ClassWithAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAnotherAuxiliary.out + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary1.out + test/tools/javac/warnings/AuxiliaryClass/ClassUsingAuxiliary2.out + test/tools/javac/warnings/AuxiliaryClass/ClassWithAuxiliary.java + test/tools/javac/warnings/AuxiliaryClass/NotAClassName.java + test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java Changeset: 75c936d14c6a Author: vromero Date: 2012-11-01 12:47 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/75c936d14c6a 8000483: cryptic error message when source file contains hash Summary: cryptic error message when source file contains hash Reviewed-by: jjg, mcimadamore Contributed-by: vicente.romero at oracle.com ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/quid/T6999438.out Changeset: bf76f4190ef8 Author: jjg Date: 2012-11-02 14:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/bf76f4190ef8 7169362: JDK8: Write compiler tests for repeating annotations for JDK8 Reviewed-by: darcy, jjg Contributed-by: sonali.goel at oracle.com + test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java + test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.out + test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.java + test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.out + test/tools/javac/annotations/repeatingAnnotations/DefaultCasePresent.java + test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.java + test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.out + test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.java + test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.out + test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java + test/tools/javac/annotations/repeatingAnnotations/MissingContainer.out + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java + test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out + test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.java + test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.out + test/tools/javac/annotations/repeatingAnnotations/MultiLevelRepeatableAnno.java + test/tools/javac/annotations/repeatingAnnotations/MultipleAnnoMixedOrder.java + test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.java + test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out + test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.java + test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.out Changeset: e6ee43b3e247 Author: lana Date: 2012-11-02 17:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/e6ee43b3e247 Merge - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java - src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourcePath.java - src/share/classes/com/sun/tools/javac/code/TypeTags.java Changeset: 056d828ac1e1 Author: katleman Date: 2012-11-08 11:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/056d828ac1e1 Added tag jdk8-b64 for changeset e6ee43b3e247 ! .hgtags From nils.eliasson at oracle.com Fri Nov 9 05:00:49 2012 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 09 Nov 2012 14:00:49 +0100 Subject: Review Request (S): 8002364 - compile_id is not unique when CICountOSR is set In-Reply-To: <061ABEB6-981A-4ADF-9A22-D09B200B0BF7@oracle.com> References: <509BCC8E.600@oracle.com> <7A5782BB-F2B6-47C4-8622-FAA2836D8677@oracle.com> <061ABEB6-981A-4ADF-9A22-D09B200B0BF7@oracle.com> Message-ID: <509CFE81.5080105@oracle.com> Vladimir Kozlov skrev 2012-11-08 19:02: > It is not true. Vladimir I. changed the flag default value to false in recent changes for 7177003. > Also in our developing environment we will not use JFR but we want a functionality which help us debug problems. So I would like to keep the flag and have a separate number in output (tty and LogCompilation log) for osr_id if the flag is on. So I agree with your general changes but you need to add more code. True, that change hadn't propagated to the branch where I originally did the work. Yes, and thats exactly why I kept the functionality by extracting it to a separate id and took great care to keep its behavior. > After thinking about this more, maybe we should always print osr_id as an additional number then we don't need CICountOSR flag. In this case you only need to add code to print this number in PrintCompilation and LogCompilation. > > Vladimir > Is there any parser or tool that will break if I add the osr_id as an additional number? //N From john.coomes at oracle.com Fri Nov 9 01:53:38 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 09 Nov 2012 09:53:38 +0000 Subject: hg: hsx/hotspot-comp/jdk: 47 new changesets Message-ID: <20121109100257.A2E3847893@hg.openjdk.java.net> Changeset: cc998992dc32 Author: bae Date: 2012-10-24 05:30 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cc998992dc32 7053526: Upgrade JDK 8 to use Little CMS 2.4 Reviewed-by: prr, jgodinez ! make/sun/cmm/lcms/FILES_c_unix.gmk ! make/sun/cmm/lcms/FILES_c_windows.gmk ! src/share/native/sun/java2d/cmm/lcms/cmscam02.c ! src/share/native/sun/java2d/cmm/lcms/cmscgats.c ! src/share/native/sun/java2d/cmm/lcms/cmscnvrt.c ! src/share/native/sun/java2d/cmm/lcms/cmserr.c ! src/share/native/sun/java2d/cmm/lcms/cmsgamma.c ! src/share/native/sun/java2d/cmm/lcms/cmsgmt.c + src/share/native/sun/java2d/cmm/lcms/cmshalf.c ! src/share/native/sun/java2d/cmm/lcms/cmsintrp.c ! src/share/native/sun/java2d/cmm/lcms/cmsio0.c ! src/share/native/sun/java2d/cmm/lcms/cmsio1.c ! src/share/native/sun/java2d/cmm/lcms/cmslut.c ! src/share/native/sun/java2d/cmm/lcms/cmsmd5.c ! src/share/native/sun/java2d/cmm/lcms/cmsmtrx.c ! src/share/native/sun/java2d/cmm/lcms/cmsnamed.c ! src/share/native/sun/java2d/cmm/lcms/cmsopt.c ! src/share/native/sun/java2d/cmm/lcms/cmspack.c ! src/share/native/sun/java2d/cmm/lcms/cmspcs.c ! src/share/native/sun/java2d/cmm/lcms/cmsplugin.c ! src/share/native/sun/java2d/cmm/lcms/cmsps2.c ! src/share/native/sun/java2d/cmm/lcms/cmssamp.c ! src/share/native/sun/java2d/cmm/lcms/cmssm.c ! src/share/native/sun/java2d/cmm/lcms/cmstypes.c ! src/share/native/sun/java2d/cmm/lcms/cmsvirt.c ! src/share/native/sun/java2d/cmm/lcms/cmswtpnt.c ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c ! src/share/native/sun/java2d/cmm/lcms/lcms2.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_internal.h ! src/share/native/sun/java2d/cmm/lcms/lcms2_plugin.h Changeset: 00c8ea9ef1cf Author: lana Date: 2012-10-31 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/00c8ea9ef1cf Merge - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: c9523d220bc3 Author: lana Date: 2012-11-02 17:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c9523d220bc3 Merge Changeset: 3b889d1218f5 Author: alitvinov Date: 2012-10-24 18:27 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3b889d1218f5 7193219: JComboBox serialization fails in JDK 1.7 Reviewed-by: rupashka, anthony ! src/share/classes/javax/swing/AncestorNotifier.java + test/javax/swing/AncestorNotifier/7193219/bug7193219.java Changeset: c27efe7615f8 Author: bagiras Date: 2012-10-25 09:55 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c27efe7615f8 8000486: REGRESSION: Three java2d tests fail since jdk8b58 on Windows 7 with NullPointerException Reviewed-by: flar, art ! src/windows/classes/sun/java2d/ScreenUpdateManager.java Changeset: 9fb5db444365 Author: bagiras Date: 2012-10-25 19:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9fb5db444365 7082294: nsk/regression/b4265661 crashes on windows Reviewed-by: art, anthony ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 7ead109417f0 Author: serb Date: 2012-10-29 23:10 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7ead109417f0 7198229: Painting during resizing of the frame should be more smooth Reviewed-by: anthony, denis, skovatch ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/java2d/opengl/CGLLayer.m Changeset: 884402437aad Author: kshefov Date: 2012-10-30 12:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/884402437aad 7072120: No mac os x support in several regression tests Reviewed-by: anthony, serb ! test/java/awt/Toolkit/AutoShutdown/ShowExitTest/ShowExitTest.sh ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh Changeset: 6652efb69459 Author: lana Date: 2012-10-31 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6652efb69459 Merge - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/share/classes/sun/security/tools/CertAndKeyGen.java - src/share/classes/sun/security/tools/JarSigner.java - src/share/classes/sun/security/tools/JarSignerResources.java - src/share/classes/sun/security/tools/JarSignerResources_ja.java - src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java - src/share/classes/sun/security/tools/KeyTool.java - src/share/classes/sun/security/tools/TimestampedSigner.java - src/windows/classes/java/io/Win32FileSystem.java - src/windows/native/java/io/Win32FileSystem_md.c - test/com/sun/jndi/ldap/LdapsReadTimeoutTest.java - test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 9b5c596a2920 Author: VKARNAUK Date: 2012-11-02 15:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9b5c596a2920 2229575: Swing HTML parser can't properly decode codepoints outside the Unicode Plane 0 into a surrogate pair Reviewed-by: rupashka ! src/share/classes/javax/swing/text/html/parser/Parser.java + test/javax/swing/text/html/parser/Parser/6836089/bug6836089.java Changeset: 3d22bd7d6678 Author: alexp Date: 2012-11-02 16:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3d22bd7d6678 8001633: Wrong alt processing during switching between windows. Reviewed-by: ant, leonidr Contributed-by: Mikhail Cherkasov ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java ! src/share/classes/java/awt/event/KeyEvent.java ! src/share/classes/sun/awt/AWTAccessor.java + test/javax/swing/plaf/windows/WindowsRootPaneUI/WrongAltProcessing/WrongAltProcessing.java Changeset: 094c963dca1b Author: leonidr Date: 2012-11-02 19:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/094c963dca1b 7124310: [macosx] "opposite" seems always null in focus events Reviewed-by: anthony ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m Changeset: f4a11601680b Author: leonidr Date: 2012-11-02 19:47 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f4a11601680b 8002114: fix failed for JDK-7160951: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar Reviewed-by: serb ! src/macosx/native/sun/awt/CMenuItem.m Changeset: 509b3b4910ef Author: kshefov Date: 2012-11-02 17:05 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/509b3b4910ef 8001808: Create a test for 8000327 Reviewed-by: alexsch, serb + test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 706056a4a6d9 Author: kshefov Date: 2012-11-02 17:07 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/706056a4a6d9 8001876: Create regtest for 8000283 Reviewed-by: alexsch, serb + test/javax/swing/JMenuItem/ShortcutNotDiplayed/ShortcutNotDisplayedTest.java Changeset: ebd8f16bae1b Author: lana Date: 2012-11-02 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ebd8f16bae1b Merge Changeset: 940c8cc5a5c4 Author: wetmore Date: 2012-10-23 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/940c8cc5a5c4 7197071: Makefiles for various security providers aren't including the default manifest Reviewed-by: valeriep, mullan, katleman ! make/com/oracle/security/ucrypto/Makefile ! make/javax/crypto/Defs-jce.gmk ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile + test/javax/crypto/sanity/CheckManifestForRelease.java Changeset: 13b46e8eda33 Author: ohrstrom Date: 2012-10-23 15:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/13b46e8eda33 8001419: Build the JCE portion of JDK-8000970 Summary: Original code done by Fredrik Ohrstrom, separated/pushed by wetmore Reviewed-by: wetmore ! src/share/classes/com/sun/crypto/provider/KeyProtector.java + src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java Changeset: e782f3c383fe Author: xuelei Date: 2012-10-24 08:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e782f3c383fe 8001466: Nightly regression test failure of SSLSocketSNISensitive.java Reviewed-by: weijun ! test/sun/security/ssl/javax/net/ssl/ServerName/SSLSocketSNISensitive.java Changeset: 8e8fcd44b963 Author: jbachorik Date: 2012-10-24 20:44 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8e8fcd44b963 6976971: TEST: javax/management/remote/mandatory/URLTest.java should be re-integrated Reviewed-by: alanb ! test/javax/management/remote/mandatory/URLTest.java Changeset: 909676adaefd Author: chegar Date: 2012-10-24 21:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/909676adaefd 8000203: File descriptor leak in src/solaris/native/java/net/net_util_md.c Reviewed-by: dsamersoff, khazra, chegar Contributed-by: John Zavgren ! src/solaris/native/java/net/net_util_md.c Changeset: 37a4b4892e8e Author: jgish Date: 2012-10-25 15:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/37a4b4892e8e 7159567: inconsistent configuration of MemoryHandler Reviewed-by: mchung, alanb ! src/share/classes/java/util/logging/ConsoleHandler.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/SocketHandler.java ! src/share/classes/java/util/logging/StreamHandler.java + test/java/util/logging/MemoryHandlerTest.java + test/java/util/logging/MemoryHandlerTest.props Changeset: 27677928a937 Author: dxu Date: 2012-10-25 15:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/27677928a937 8001565: (fs) Typo Path.endsWith(String) javadoc Reviewed-by: mchung, jgish, lancea ! src/share/classes/java/nio/file/Path.java Changeset: 6302932b7380 Author: rfield Date: 2012-10-25 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6302932b7380 8000806: Implement runtime lambda metafactory Summary: Implement lambda invokedynamic bootstrap by generating at runtime an inner class that implements the functional interface Reviewed-by: twisti + src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java + src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java + src/share/classes/java/lang/invoke/LambdaConversionException.java + src/share/classes/java/lang/invoke/LambdaMetafactory.java + src/share/classes/java/lang/invoke/MagicLambdaImpl.java + src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java Changeset: 0b52c87c39da Author: dxu Date: 2012-10-26 11:21 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0b52c87c39da 4239752: FileSystem should be a platform-specific class to avoid native code Reviewed-by: alanb, dholmes, erikj, jgish ! make/java/java/Exportedfiles.gmk ! make/java/java/FILES_c.gmk ! make/java/java/FILES_java.gmk ! make/java/java/mapfile-vers ! makefiles/CompileJavaClasses.gmk ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileSystem.java + src/solaris/classes/java/io/DefaultFileSystem.java - src/solaris/native/java/io/FileSystem_md.c + src/windows/classes/java/io/DefaultFileSystem.java - src/windows/native/java/io/FileSystem_md.c Changeset: 3fc5457cf779 Author: dl Date: 2012-10-26 21:34 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3fc5457cf779 8001575: Minor/sync/cleanup j.u.c with Dougs CVS - Oct 2012 Reviewed-by: chegar, dholmes ! src/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/share/classes/java/util/concurrent/BlockingQueue.java ! src/share/classes/java/util/concurrent/BrokenBarrierException.java ! src/share/classes/java/util/concurrent/CompletionService.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentMap.java ! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ! src/share/classes/java/util/concurrent/CountDownLatch.java ! src/share/classes/java/util/concurrent/CyclicBarrier.java ! src/share/classes/java/util/concurrent/Delayed.java ! src/share/classes/java/util/concurrent/ExecutionException.java ! src/share/classes/java/util/concurrent/Executor.java ! src/share/classes/java/util/concurrent/ExecutorService.java ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/concurrent/Future.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/RecursiveAction.java ! src/share/classes/java/util/concurrent/RejectedExecutionException.java ! src/share/classes/java/util/concurrent/ScheduledExecutorService.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/Semaphore.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! src/share/classes/java/util/concurrent/ThreadFactory.java ! src/share/classes/java/util/concurrent/TimeUnit.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/package-info.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ! src/share/classes/java/util/concurrent/locks/Condition.java ! src/share/classes/java/util/concurrent/locks/Lock.java ! src/share/classes/java/util/concurrent/locks/LockSupport.java ! src/share/classes/java/util/concurrent/locks/ReentrantLock.java ! src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ! src/share/classes/java/util/concurrent/package-info.java Changeset: 615af31cfccc Author: alanb Date: 2012-10-27 09:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/615af31cfccc 7176225: Remove JDBC-ODBC Bridge Reviewed-by: lancea, ohair, tbell ! make/common/Sanity.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Sanity.gmk ! make/sun/Makefile - make/sun/jdbc/Makefile ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk Changeset: 33e29fbc3e5b Author: weijun Date: 2012-10-29 14:14 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/33e29fbc3e5b 7184246: Simplify Config.get() of krb5 Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Checksum.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/share/classes/sun/security/krb5/internal/KDCOptions.java ! src/share/classes/sun/security/krb5/internal/KerberosTime.java ! src/share/classes/sun/security/krb5/internal/crypto/CksumType.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! test/sun/security/krb5/ConfPlusProp.java ! test/sun/security/krb5/DnsFallback.java ! test/sun/security/krb5/ParseConfig.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/MaxRetries.java + test/sun/security/krb5/config/Duplicates.java + test/sun/security/krb5/config/SCDynamicConfigTest.java + test/sun/security/krb5/config/k1.conf Changeset: cb70077c6370 Author: weijun Date: 2012-10-29 14:14 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cb70077c6370 7195426: kdc_default_options not supported correctly Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/internal/KDCOptions.java + test/sun/security/krb5/config/KdcDefaultOptions.java + test/sun/security/krb5/config/kdc_default_options.conf Changeset: d1ffbdf7e3c6 Author: sla Date: 2012-10-29 09:23 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d1ffbdf7e3c6 8001621: Update awk scripts that check output from jps/jcmd Reviewed-by: alanb ! test/sun/tools/jcmd/jcmd_Output1.awk ! test/sun/tools/jps/jps-l_Output1.awk ! test/sun/tools/jps/jps_Output1.awk Changeset: 17384fc6b31f Author: ohrstrom Date: 2012-10-29 14:12 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/17384fc6b31f 8000970: break out auxiliary classes that will prevent multi-core compilation of the JDK Reviewed-by: alanb, wetmore + make/tools/src/build/tools/generatenimbus/AbstractGradient.java + make/tools/src/build/tools/generatenimbus/Border.java + make/tools/src/build/tools/generatenimbus/Canvas.java + make/tools/src/build/tools/generatenimbus/ComponentColor.java + make/tools/src/build/tools/generatenimbus/Dimension.java + make/tools/src/build/tools/generatenimbus/Ellipse.java + make/tools/src/build/tools/generatenimbus/Gradient.java + make/tools/src/build/tools/generatenimbus/GradientStop.java + make/tools/src/build/tools/generatenimbus/Insets.java + make/tools/src/build/tools/generatenimbus/Layer.java + make/tools/src/build/tools/generatenimbus/Matte.java ! make/tools/src/build/tools/generatenimbus/Paint.java + make/tools/src/build/tools/generatenimbus/Path.java + make/tools/src/build/tools/generatenimbus/Point.java + make/tools/src/build/tools/generatenimbus/RadialGradient.java + make/tools/src/build/tools/generatenimbus/Rectangle.java ! make/tools/src/build/tools/generatenimbus/Shape.java ! make/tools/src/build/tools/generatenimbus/SynthModel.java + make/tools/src/build/tools/generatenimbus/Typeface.java + make/tools/src/build/tools/generatenimbus/UIColor.java + make/tools/src/build/tools/generatenimbus/UIComponent.java ! make/tools/src/build/tools/generatenimbus/UIDefault.java + make/tools/src/build/tools/generatenimbus/UIFont.java + make/tools/src/build/tools/generatenimbus/UIIconRegion.java + make/tools/src/build/tools/generatenimbus/UIProperty.java + make/tools/src/build/tools/generatenimbus/UIRegion.java + make/tools/src/build/tools/generatenimbus/UIState.java + make/tools/src/build/tools/generatenimbus/UIStateType.java ! make/tools/src/build/tools/generatenimbus/UIStyle.java ! src/share/classes/javax/management/timer/Timer.java + src/share/classes/javax/management/timer/TimerAlarmClock.java + src/share/classes/sun/awt/im/ExecutableInputMethodManager.java ! src/share/classes/sun/awt/im/InputMethodManager.java + src/share/classes/sun/misc/FDBigInt.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/net/httpserver/Event.java + src/share/classes/sun/net/httpserver/WriteFinishedEvent.java + src/share/classes/sun/net/www/http/KeepAliveCleanerEntry.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java + src/share/classes/sun/security/ssl/ExtensionType.java + src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/HelloExtensions.java + src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java + src/share/classes/sun/security/ssl/ServerNameExtension.java + src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java + src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java + src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java + src/share/classes/sun/security/ssl/UnknownExtension.java ! src/solaris/classes/sun/awt/X11/XChoicePeer.java + src/solaris/classes/sun/awt/X11/XChoicePeerListener.java + src/solaris/classes/sun/font/DelegateStrike.java ! src/solaris/classes/sun/font/NativeStrike.java ! src/solaris/classes/sun/java2d/jules/JulesAATileGenerator.java + src/solaris/classes/sun/java2d/jules/TileTrapContainer.java Changeset: 7fa45c455034 Author: naoto Date: 2012-10-29 10:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7fa45c455034 8000997: Multiple locale sensitive services cannot be loaded Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/barprovider.jar + test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/java.util.spi.CurrencyNameProvider Changeset: e2f976a73afb Author: jgish Date: 2012-10-29 16:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e2f976a73afb 6206780: (str) Forwarding append methods in String{Buffer,Builder} are inconsistent Summary: update StringBuilder & StringBuffer to consistently handle forwarding to AbstractStringBuilder. Some additional cleanup (removal of refs to sub-classes from AbstractStringBuilder) Reviewed-by: chegar, alanb, mduigou ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java + test/java/lang/StringBuffer/AppendStringBuilder.java + test/java/lang/StringBuffer/BufferForwarding.java + test/java/lang/StringBuffer/TestSynchronization.java + test/java/lang/StringBuilder/AppendStringBuffer.java + test/java/lang/StringBuilder/BuilderForwarding.java Changeset: ac97b1cfc0ea Author: lana Date: 2012-10-31 08:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ac97b1cfc0ea Merge ! make/common/shared/Sanity.gmk ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/MemoryHandler.java ! src/share/classes/java/util/logging/StreamHandler.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java Changeset: 178618fb4300 Author: naoto Date: 2012-10-31 11:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/178618fb4300 8001231: Move locale data out of rt.jar (except the US locale) Reviewed-by: alanb, erikj ! make/java/java/genlocales.gmk ! make/java/java/localegen.sh ! make/java/text/base/FILES_java.gmk ! make/java/util/FILES_java.gmk ! make/java/util/FILES_properties.gmk ! make/sun/text/FILES_java.gmk ! make/sun/text/FILES_properties.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleDataMetaInfo-XLocales.java.template Changeset: 8b944ebef8a7 Author: ohrstrom Date: 2012-11-01 10:33 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8b944ebef8a7 8002101: break out auxiliary classes that will prevent multi-core compilation of the JDK Reviewed-by: alanb, sla + src/share/classes/com/sun/jmx/snmp/agent/AcmChecker.java + src/share/classes/com/sun/jmx/snmp/agent/LongList.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java Changeset: 6420fcd61c10 Author: naoto Date: 2012-11-01 13:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6420fcd61c10 8001440: CLDR adapter: Invalid number extension in language tag causes exception in NumberFormat.format() Reviewed-by: okutsu ! src/share/classes/java/text/DecimalFormatSymbols.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh Changeset: 8748331f63cf Author: lancea Date: 2012-11-01 17:35 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8748331f63cf 8001536: Added readObject,writeObject,clone, equals, hashcode to SerialXLob Reviewed-by: alanb, forax ! src/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/share/classes/javax/sql/rowset/serial/SerialClob.java Changeset: 79774104a1f4 Author: alanb Date: 2012-11-01 21:59 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/79774104a1f4 8002120: ProblemList.txt updates (11/2012) Reviewed-by: lancea ! test/ProblemList.txt ! test/TEST.ROOT Changeset: 9b3867244eec Author: dholmes Date: 2012-11-01 18:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9b3867244eec 7198815: Add the minimal VM as "known" in jvm.cfg Reviewed-by: alanb, forax, mchung ! src/solaris/bin/arm/jvm.cfg ! src/solaris/bin/i586/jvm.cfg ! src/solaris/bin/ppc/jvm.cfg ! src/solaris/bin/sparc/jvm.cfg Changeset: 36f962518499 Author: weijun Date: 2012-11-02 10:48 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/36f962518499 7110803: SASL service for multiple hostnames Reviewed-by: mullan ! src/share/classes/com/sun/security/ntlm/Server.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslServerFactory.java + test/com/sun/security/sasl/digest/Unbound.java + test/sun/security/krb5/auto/SaslBasic.java Changeset: 98a47dc23296 Author: peytoia Date: 2012-11-02 23:17 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/98a47dc23296 8001209: Evaluate findbugs reprot for java.text.ChoiceFormat Reviewed-by: okutsu ! src/share/classes/java/text/ChoiceFormat.java + test/java/text/Format/ChoiceFormat/Bug8001209.java Changeset: cea72c2bf071 Author: alanb Date: 2012-11-02 15:50 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cea72c2bf071 7197491: update copyright year to match last edit in jdk8 jdk repository Reviewed-by: chegar, ksrini ! make/apple/Makefile ! make/apple/applescript/Makefile ! make/com/Makefile ! make/com/apple/Makefile ! make/com/apple/osx/Makefile ! make/com/apple/osxui/Makefile ! make/com/oracle/jfr/Makefile ! make/com/sun/Makefile ! make/com/sun/demo/jvmti/hprof/Makefile ! make/com/sun/java/browser/net/Makefile ! make/com/sun/java/pack/Makefile ! make/com/sun/net/ssl/Makefile ! make/com/sun/nio/Makefile ! make/com/sun/nio/sctp/Exportedfiles.gmk ! make/com/sun/nio/sctp/FILES_java.gmk ! make/com/sun/nio/sctp/Makefile ! make/com/sun/nio/sctp/mapfile-vers ! make/com/sun/security/auth/module/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tools/attach/Exportedfiles.gmk ! make/com/sun/tools/attach/FILES_c.gmk ! make/com/sun/tools/attach/FILES_java.gmk ! make/com/sun/tools/attach/mapfile-bsd ! make/com/sun/tracing/Makefile ! make/com/sun/tracing/dtrace/Makefile ! make/common/Demo.gmk ! make/common/Mapfile-vers.gmk ! make/common/Release-macosx.gmk ! make/common/Rules.gmk ! make/common/Sanity.gmk ! make/common/internal/Defs-jaxws.gmk ! make/common/internal/NativeCompileRules.gmk ! make/common/internal/Resources.gmk ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-llvm.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-macosx.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/docs/CORE_PKGS.gmk ! make/java/Makefile ! make/java/awt/Makefile ! make/java/fdlibm/FILES_c.gmk ! make/java/java/genlocales.gmk ! make/java/java/reflect/Makefile ! make/java/jobjc/Makefile ! make/java/jvm/Makefile ! make/java/management/mapfile-vers ! make/java/net/FILES_c.gmk ! make/java/net/Makefile ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/java/nio/mapfile-bsd ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! make/java/rmi/Makefile ! make/java/security/Makefile ! make/java/sun_nio/FILES_java.gmk ! make/java/text/bidi/Makefile ! make/java/zip/FILES_c.gmk ! make/java/zip/Makefile ! make/java/zip/mapfile-vers ! make/javax/accessibility/Makefile ! make/javax/crypto/Makefile ! make/javax/sound/FILES_c.gmk ! make/javax/sound/SoundDefs.gmk ! make/javax/sound/jsoundalsa/Makefile ! make/jdk_generic_profile.sh ! make/jpda/back/Makefile ! make/jpda/jdwp/jdwp.spec ! make/jprt.properties ! make/mksample/Makefile ! make/netbeans/common/architectures/name-Bsd.properties ! make/netbeans/common/closed-share-view.ent ! make/netbeans/common/jtreg-view.ent ! make/netbeans/common/sample-view.ent ! make/netbeans/common/share-view.ent ! make/netbeans/common/unix-view.ent ! make/netbeans/common/windows-view.ent ! make/netbeans/jconsole/build.xml ! make/org/ietf/jgss/Makefile ! make/sun/Makefile ! make/sun/awt/FILES_c_macosx.gmk ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_export_macosx.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/mapfile-vers-bsd ! make/sun/awt/mawt.gmk ! make/sun/cmm/lcms/Makefile ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/image/generic/Makefile ! make/sun/image/vis/Makefile ! make/sun/jawt/Makefile ! make/sun/jconsole/FILES.gmk ! make/sun/jconsole/Makefile ! make/sun/jdga/Makefile ! make/sun/lwawt/FILES_c_macosx.gmk ! make/sun/lwawt/FILES_export_macosx.gmk ! make/sun/lwawt/Makefile ! make/sun/net/FILES_java.gmk ! make/sun/net/spi/Makefile ! make/sun/nio/cs/FILES_java.gmk ! make/sun/osxapp/Makefile ! make/sun/rmi/cgi/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmi/Makefile ! make/sun/rmi/rmi/mapfile-vers ! make/sun/rmi/rmid/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/other/Makefile ! make/sun/security/smartcardio/Makefile ! make/sun/splashscreen/FILES_c.gmk ! make/sun/splashscreen/Makefile ! make/sun/tools/Makefile ! make/sun/util/Makefile ! make/tools/CharsetMapping/DoubleByte-X.java.template ! make/tools/CharsetMapping/SingleByte-X.java.template ! make/tools/GenerateCharacter/CharacterData01.java.template ! make/tools/GenerateCharacter/CharacterData02.java.template ! make/tools/GenerateCharacter/CharacterData0E.java.template ! make/tools/GenerateCharacter/CharacterDataLatin1.java.template ! make/tools/freetypecheck/Makefile ! make/tools/reorder/Makefile ! make/tools/src/build/tools/charsetmapping/DBCS.java ! make/tools/src/build/tools/charsetmapping/SBCS.java ! make/tools/src/build/tools/compileproperties/CompileProperties.java ! make/tools/src/build/tools/generatenimbus/AbstractGradient.java ! make/tools/src/build/tools/generatenimbus/Border.java ! make/tools/src/build/tools/generatenimbus/Canvas.java ! make/tools/src/build/tools/generatenimbus/ComponentColor.java ! make/tools/src/build/tools/generatenimbus/Dimension.java ! make/tools/src/build/tools/generatenimbus/Ellipse.java ! make/tools/src/build/tools/generatenimbus/Gradient.java ! make/tools/src/build/tools/generatenimbus/GradientStop.java ! make/tools/src/build/tools/generatenimbus/Insets.java ! make/tools/src/build/tools/generatenimbus/Layer.java ! make/tools/src/build/tools/generatenimbus/Matte.java ! make/tools/src/build/tools/generatenimbus/Paint.java ! make/tools/src/build/tools/generatenimbus/Path.java ! make/tools/src/build/tools/generatenimbus/Point.java ! make/tools/src/build/tools/generatenimbus/RadialGradient.java ! make/tools/src/build/tools/generatenimbus/Rectangle.java ! make/tools/src/build/tools/generatenimbus/Shape.java ! make/tools/src/build/tools/generatenimbus/SynthModel.java ! make/tools/src/build/tools/generatenimbus/Typeface.java ! make/tools/src/build/tools/generatenimbus/UIColor.java ! make/tools/src/build/tools/generatenimbus/UIComponent.java ! make/tools/src/build/tools/generatenimbus/UIDefault.java ! make/tools/src/build/tools/generatenimbus/UIFont.java ! make/tools/src/build/tools/generatenimbus/UIIconRegion.java ! make/tools/src/build/tools/generatenimbus/UIProperty.java ! make/tools/src/build/tools/generatenimbus/UIRegion.java ! make/tools/src/build/tools/generatenimbus/UIState.java ! make/tools/src/build/tools/generatenimbus/UIStateType.java ! make/tools/src/build/tools/generatenimbus/UIStyle.java ! make/tools/src/build/tools/jdwpgen/ArrayRegionTypeNode.java ! make/tools/src/build/tools/stripproperties/StripProperties.java ! makefiles/GendataBreakIterator.gmk ! makefiles/GendataTimeZone.gmk ! makefiles/GensrcSwing.gmk ! makefiles/docs/CORE_PKGS.gmk ! makefiles/jpda/jdwp/jdwp.spec ! makefiles/jprt.gmk ! makefiles/jprt.properties ! makefiles/mapfiles/launchers/mapfile-amd64 ! makefiles/mapfiles/launchers/mapfile-i586 ! makefiles/mapfiles/launchers/mapfile-sparc ! makefiles/mapfiles/launchers/mapfile-sparcv9 ! makefiles/mapfiles/launchers/mapfile-x86 ! makefiles/mapfiles/launchers/mapfile-x86_64 ! makefiles/mapfiles/libattach/mapfile-linux ! makefiles/mapfiles/libattach/mapfile-solaris ! makefiles/mapfiles/libawt/mapfile-mawt-vers ! makefiles/mapfiles/libawt/mapfile-vers ! makefiles/mapfiles/libawt/mapfile-vers-linux ! makefiles/mapfiles/libawt_headless/mapfile-vers ! makefiles/mapfiles/libawt_xawt/mapfile-vers ! makefiles/mapfiles/libdcpr/mapfile-vers ! makefiles/mapfiles/libdt_socket/mapfile-vers ! makefiles/mapfiles/libfontmanager/mapfile-vers ! makefiles/mapfiles/libfontmanager/mapfile-vers.openjdk ! makefiles/mapfiles/libhprof/mapfile-vers ! makefiles/mapfiles/libinstrument/mapfile-vers ! makefiles/mapfiles/libj2gss/mapfile-vers ! makefiles/mapfiles/libj2pcsc/mapfile-vers ! makefiles/mapfiles/libjaas/mapfile-vers ! makefiles/mapfiles/libjava_crw_demo/mapfile-vers ! makefiles/mapfiles/libjawt/mapfile-vers ! makefiles/mapfiles/libjdga/mapfile-vers ! makefiles/mapfiles/libjdwp/mapfile-vers ! makefiles/mapfiles/libjli/mapfile-vers ! makefiles/mapfiles/libjpeg/mapfile-vers ! makefiles/mapfiles/libjpeg/mapfile-vers-closed ! makefiles/mapfiles/libjsdt/mapfile-vers ! makefiles/mapfiles/libjsound/mapfile-vers ! makefiles/mapfiles/libjsoundalsa/mapfile-vers ! makefiles/mapfiles/libkcms/mapfile-vers ! makefiles/mapfiles/liblcms/mapfile-vers ! makefiles/mapfiles/libmanagement/mapfile-vers ! makefiles/mapfiles/libmlib_image/mapfile-vers ! makefiles/mapfiles/libnet/mapfile-vers ! makefiles/mapfiles/libnio/mapfile-bsd ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris ! makefiles/mapfiles/libnpt/mapfile-vers ! makefiles/mapfiles/libsctp/mapfile-vers ! makefiles/mapfiles/libsplashscreen/mapfile-vers ! makefiles/mapfiles/libsunec/mapfile-vers ! makefiles/mapfiles/libt2k/mapfile-vers ! makefiles/mapfiles/libunpack/mapfile-vers ! makefiles/mapfiles/libunpack/mapfile-vers-unpack200 ! makefiles/mapfiles/libverify/mapfile-vers ! makefiles/mapfiles/libzip/mapfile-vers ! makefiles/scripts/addNotices.sh ! makefiles/scripts/genCharsetProvider.sh ! makefiles/scripts/genExceptions.sh ! makefiles/scripts/localelist.sh ! makefiles/sun/xawt/ToBin.java ! src/bsd/doc/man/appletviewer.1 ! src/bsd/doc/man/apt.1 ! src/bsd/doc/man/extcheck.1 ! src/bsd/doc/man/idlj.1 ! src/bsd/doc/man/ja/appletviewer.1 ! src/bsd/doc/man/ja/apt.1 ! src/bsd/doc/man/ja/extcheck.1 ! src/bsd/doc/man/ja/idlj.1 ! src/bsd/doc/man/ja/jar.1 ! src/bsd/doc/man/ja/jarsigner.1 ! src/bsd/doc/man/ja/java.1 ! src/bsd/doc/man/ja/javac.1 ! src/bsd/doc/man/ja/javadoc.1 ! src/bsd/doc/man/ja/javah.1 ! src/bsd/doc/man/ja/javap.1 ! src/bsd/doc/man/ja/javaws.1 ! src/bsd/doc/man/ja/jconsole.1 ! src/bsd/doc/man/ja/jdb.1 ! src/bsd/doc/man/ja/jhat.1 ! src/bsd/doc/man/ja/jinfo.1 ! src/bsd/doc/man/ja/jmap.1 ! src/bsd/doc/man/ja/jps.1 ! src/bsd/doc/man/ja/jrunscript.1 ! src/bsd/doc/man/ja/jsadebugd.1 ! src/bsd/doc/man/ja/jstack.1 ! src/bsd/doc/man/ja/jstat.1 ! src/bsd/doc/man/ja/jstatd.1 ! src/bsd/doc/man/ja/keytool.1 ! src/bsd/doc/man/ja/native2ascii.1 ! src/bsd/doc/man/ja/orbd.1 ! src/bsd/doc/man/ja/pack200.1 ! src/bsd/doc/man/ja/policytool.1 ! src/bsd/doc/man/ja/rmic.1 ! src/bsd/doc/man/ja/rmid.1 ! src/bsd/doc/man/ja/rmiregistry.1 ! src/bsd/doc/man/ja/schemagen.1 ! src/bsd/doc/man/ja/serialver.1 ! src/bsd/doc/man/ja/servertool.1 ! src/bsd/doc/man/ja/tnameserv.1 ! src/bsd/doc/man/ja/unpack200.1 ! src/bsd/doc/man/ja/wsgen.1 ! src/bsd/doc/man/ja/wsimport.1 ! src/bsd/doc/man/ja/xjc.1 ! src/bsd/doc/man/jar.1 ! src/bsd/doc/man/java.1 ! src/bsd/doc/man/javac.1 ! src/bsd/doc/man/javah.1 ! src/bsd/doc/man/javap.1 ! src/bsd/doc/man/javaws.1 ! src/bsd/doc/man/jconsole.1 ! src/bsd/doc/man/jdb.1 ! src/bsd/doc/man/jhat.1 ! src/bsd/doc/man/jinfo.1 ! src/bsd/doc/man/jmap.1 ! src/bsd/doc/man/jps.1 ! src/bsd/doc/man/jrunscript.1 ! src/bsd/doc/man/jsadebugd.1 ! src/bsd/doc/man/jstack.1 ! src/bsd/doc/man/jstatd.1 ! src/bsd/doc/man/native2ascii.1 ! src/bsd/doc/man/orbd.1 ! src/bsd/doc/man/pack200.1 ! src/bsd/doc/man/policytool.1 ! src/bsd/doc/man/rmic.1 ! src/bsd/doc/man/rmid.1 ! src/bsd/doc/man/rmiregistry.1 ! src/bsd/doc/man/schemagen.1 ! src/bsd/doc/man/serialver.1 ! src/bsd/doc/man/servertool.1 ! src/bsd/doc/man/tnameserv.1 ! src/bsd/doc/man/unpack200.1 ! src/bsd/doc/man/xjc.1 ! src/linux/doc/man/jcmd.1 ! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.h ! src/macosx/bundle/JavaAppLauncher/src/JVMArgs.m ! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.h ! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher.m ! src/macosx/bundle/JavaAppLauncher/src/JavaAppLauncher_Prefix.pch ! src/macosx/bundle/JavaAppLauncher/src/main.m ! src/macosx/classes/apple/applescript/AppleScriptEngineFactory.java ! src/macosx/classes/apple/launcher/JavaAppLauncher.java ! src/macosx/classes/apple/security/AppleProvider.java ! src/macosx/classes/apple/security/KeychainStore.java ! src/macosx/classes/com/apple/concurrent/Dispatch.java ! src/macosx/classes/com/apple/concurrent/LibDispatchConcurrentQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchMainQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchNative.java ! src/macosx/classes/com/apple/concurrent/LibDispatchQueue.java ! src/macosx/classes/com/apple/concurrent/LibDispatchRetainedResource.java ! src/macosx/classes/com/apple/concurrent/LibDispatchSerialQueue.java ! src/macosx/classes/com/apple/eio/FileManager.java ! src/macosx/classes/com/apple/resources/MacOSXResourceBundle.java ! src/macosx/classes/java/net/DefaultInterface.java ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFactory.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorProvider.java ! src/macosx/native/apple/applescript/AS_NS_ConversionUtils.h ! src/macosx/native/apple/applescript/AS_NS_ConversionUtils.m ! src/macosx/native/apple/applescript/AppleScriptEngine.m ! src/macosx/native/apple/applescript/AppleScriptExecutionContext.h ! src/macosx/native/apple/applescript/AppleScriptExecutionContext.m ! src/macosx/native/apple/applescript/NS_Java_ConversionUtils.h ! src/macosx/native/apple/applescript/NS_Java_ConversionUtils.m ! src/macosx/native/apple/launcher/JavaAppLauncher.m ! src/macosx/native/com/apple/concurrent/Dispatch.m ! src/macosx/native/com/apple/eio/CFileManager.m ! src/macosx/native/com/apple/resources/MacOSXResourceBundle.m ! src/macosx/native/java/util/MacOSXPreferencesFile.m ! src/macosx/native/java/util/SCDynamicStoreConfig.m ! src/macosx/native/jobjc/JObjC.xcodeproj/default.pbxuser ! src/macosx/native/jobjc/README.txt ! src/macosx/native/jobjc/TODOS ! src/macosx/native/jobjc/bridgesupport.gmk ! src/macosx/native/jobjc/build.xml ! src/macosx/native/jobjc/extract_classes.pl ! src/macosx/native/jobjc/run-and-write-if-okay ! src/macosx/native/jobjc/rungen ! src/macosx/native/jobjc/runjava ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CFType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/CIF.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Coder.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/FFIType.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Function.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/ID.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Invoke.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/JObjCRuntime.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/MacOSXFramework.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NSClass.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeArgumentBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeBuffer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/NativeObjectLifecycleManager.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Opaque.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Pointer.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/SEL.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Struct.java ! src/macosx/native/jobjc/src/core/java/com/apple/jobjc/Subclassing.java ! src/macosx/native/jobjc/src/core/native/CIF.m ! src/macosx/native/jobjc/src/core/native/Coder.m ! src/macosx/native/jobjc/src/core/native/FFIType.m ! src/macosx/native/jobjc/src/core/native/Function.m ! src/macosx/native/jobjc/src/core/native/ID.m ! src/macosx/native/jobjc/src/core/native/Invoke.m ! src/macosx/native/jobjc/src/core/native/JObjCRuntime.m ! src/macosx/native/jobjc/src/core/native/MacOSXFramework.m ! src/macosx/native/jobjc/src/core/native/NSClass.m ! src/macosx/native/jobjc/src/core/native/NativeBuffer.h ! src/macosx/native/jobjc/src/core/native/NativeBuffer.m ! src/macosx/native/jobjc/src/core/native/NativeObjectLifecycleManager.m ! src/macosx/native/jobjc/src/core/native/SEL.m ! src/macosx/native/jobjc/src/core/native/Subclassing.m ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/BootClassPathMinus.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/ClassConsolidator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/ClassGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FileCopier.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FrameworkGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/FunctionGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/Generator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/MethodDisambiguator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/RestrictedKeywords.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/Utils.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/AbstractObjCClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CFTypeClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CategoryClassClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CategoryClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/CopiedFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/FrameworkClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/GeneratedClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/JObjCClassClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/JObjCClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/MixedPrimitiveCoderClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/OpaqueClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/OutputFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/RootJObjCClass.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/classes/StructClassFile.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Arg.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/CFType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Category.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Clazz.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Constant.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Element.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/ElementWType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Framework.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Function.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/FunctionAlias.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/InformalProtocol.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Method.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/NativeEnum.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Opaque.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/OutputFileGenerator.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Protocol.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/ReturnValue.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/StringConstant.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/Struct.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/TypeElement.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/CoderDescriptor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/ComplexCoderDescriptor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/coders/PrimitiveCoderDescriptor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/JType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/NType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/Type.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/TypeCache.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/model/types/TypeToJType.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/Fp.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/JavaLang.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypeMerger.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypeParser.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/NTypePrinter.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/ObjectInspector.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/QA.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StringStream.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StructOffsetResolver.java ! src/macosx/native/jobjc/src/generator/java/com/apple/internal/jobjc/generator/utils/StructOffsetResolverBigBang.java ! src/macosx/native/jobjc/src/generator/java/com/apple/jobjc/SuperClassExtractor.java ! src/macosx/native/jobjc/src/generator/java/com/apple/jobjc/UnsafeRuntimeAccess.java ! src/macosx/native/jobjc/src/runtime-additions/java/com/apple/jobjc/Utils.java ! src/macosx/native/jobjc/src/runtime-additions/native/NativeNumber.m ! src/macosx/native/jobjc/src/runtime-additions/native/NativeString.m ! src/macosx/native/jobjc/src/runtime-additions/native/NativeThread.m ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BaseBench.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchFunCall.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchIDPop.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchStructCoding.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/BenchUnsafe.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/CategoryTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/FunctionTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/GUIDemo.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/IBDemo.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/IntroTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NSClassTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NativeBufferTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/NativeTypeTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/PooledTestCase.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/SELTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/StructTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/SubclassingTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/TestUtils.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/UtilsTest.java ! src/macosx/native/jobjc/src/tests/java/com/apple/jobjc/VarArgsTest.java ! src/macosx/native/jobjc/src/tests/native/FunCallBench.m ! src/macosx/native/sun/nio/ch/KQueueArrayWrapper.c ! src/macosx/native/sun/osxapp/AWT_debug.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.h ! src/macosx/native/sun/osxapp/NSApplicationAWT.m ! src/macosx/native/sun/osxapp/PropertiesUtilities.h ! src/macosx/native/sun/osxapp/PropertiesUtilities.m ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.h ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m ! src/share/back/commonRef.c ! src/share/back/error_messages.h ! src/share/back/log_messages.h ! src/share/bin/emessages.h ! src/share/classes/com/sun/crypto/provider/PBEKey.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/NativeUnpack.java ! src/share/classes/com/sun/java/util/jar/pack/package.html ! src/share/classes/com/sun/jdi/AbsentInformationException.java ! src/share/classes/com/sun/jdi/Accessible.java ! src/share/classes/com/sun/jdi/ArrayType.java ! src/share/classes/com/sun/jdi/ClassLoaderReference.java ! src/share/classes/com/sun/jdi/ClassNotLoadedException.java ! src/share/classes/com/sun/jdi/ClassNotPreparedException.java ! src/share/classes/com/sun/jdi/ClassType.java ! src/share/classes/com/sun/jdi/IncompatibleThreadStateException.java ! src/share/classes/com/sun/jdi/InconsistentDebugInfoException.java ! src/share/classes/com/sun/jdi/InternalException.java ! src/share/classes/com/sun/jdi/InvalidCodeIndexException.java ! src/share/classes/com/sun/jdi/InvalidLineNumberException.java ! src/share/classes/com/sun/jdi/InvalidStackFrameException.java ! src/share/classes/com/sun/jdi/InvalidTypeException.java ! src/share/classes/com/sun/jdi/InvocationException.java ! src/share/classes/com/sun/jdi/JDIPermission.java ! src/share/classes/com/sun/jdi/LocalVariable.java ! src/share/classes/com/sun/jdi/Method.java ! src/share/classes/com/sun/jdi/NativeMethodException.java ! src/share/classes/com/sun/jdi/ObjectCollectedException.java ! src/share/classes/com/sun/jdi/ObjectReference.java ! src/share/classes/com/sun/jdi/ReferenceType.java ! src/share/classes/com/sun/jdi/TypeComponent.java ! src/share/classes/com/sun/jdi/VMCannotBeModifiedException.java ! src/share/classes/com/sun/jdi/VMDisconnectedException.java ! src/share/classes/com/sun/jdi/VMMismatchException.java ! src/share/classes/com/sun/jdi/VMOutOfMemoryException.java ! src/share/classes/com/sun/jdi/connect/IllegalConnectorArgumentsException.java ! src/share/classes/com/sun/jdi/connect/TransportTimeoutException.java ! src/share/classes/com/sun/jdi/connect/VMStartException.java ! src/share/classes/com/sun/jdi/connect/spi/ClosedConnectionException.java ! src/share/classes/com/sun/jdi/request/DuplicateRequestException.java ! src/share/classes/com/sun/jdi/request/InvalidRequestStateException.java ! src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanMapping.java ! src/share/classes/com/sun/jmx/remote/internal/IIOPHelper.java ! src/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/com/sun/jmx/snmp/SnmpCounter64.java ! src/share/classes/com/sun/jmx/snmp/SnmpInt.java ! src/share/classes/com/sun/jmx/snmp/SnmpNull.java ! src/share/classes/com/sun/jmx/snmp/SnmpString.java ! src/share/classes/com/sun/jmx/snmp/agent/AcmChecker.java ! src/share/classes/com/sun/jmx/snmp/agent/LongList.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jndi/toolkit/url/UrlUtil.java ! src/share/classes/com/sun/management/OperatingSystemMXBean.java ! src/share/classes/com/sun/management/VMOption.java ! src/share/classes/com/sun/net/httpserver/spi/HttpServerProvider.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java ! src/share/classes/com/sun/nio/sctp/MessageInfo.java ! src/share/classes/com/sun/nio/sctp/SctpChannel.java ! src/share/classes/com/sun/nio/sctp/SctpMultiChannel.java ! src/share/classes/com/sun/nio/sctp/SctpServerChannel.java ! src/share/classes/com/sun/nio/sctp/SctpSocketOption.java ! src/share/classes/com/sun/nio/sctp/SctpStandardSocketOptions.java ! src/share/classes/com/sun/rmi/rmid/ExecOptionPermission.java ! src/share/classes/com/sun/rmi/rmid/ExecPermission.java ! src/share/classes/com/sun/rowset/JdbcRowSetResourceBundle.java ! src/share/classes/com/sun/rowset/JoinRowSetImpl.java ! src/share/classes/com/sun/rowset/internal/CachedRowSetReader.java ! src/share/classes/com/sun/rowset/internal/SyncResolverImpl.java ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/com/sun/security/ntlm/Client.java ! src/share/classes/com/sun/security/ntlm/NTLM.java ! src/share/classes/com/sun/security/ntlm/Server.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Base.java ! src/share/classes/com/sun/security/sasl/digest/DigestMD5Server.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java ! src/share/classes/com/sun/security/sasl/ntlm/NTLMServer.java ! src/share/classes/com/sun/security/sasl/util/AbstractSaslImpl.java ! src/share/classes/com/sun/servicetag/BrowserSupport.java ! src/share/classes/com/sun/servicetag/Installer.java ! src/share/classes/com/sun/servicetag/RegistrationDocument.java ! src/share/classes/com/sun/servicetag/SunConnection.java ! src/share/classes/com/sun/tools/example/debug/bdi/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/bdi/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ChildSession.java ! src/share/classes/com/sun/tools/example/debug/bdi/EvaluationException.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ExecutionManager.java ! src/share/classes/com/sun/tools/example/debug/bdi/FrameIndexOutOfBoundsException.java ! src/share/classes/com/sun/tools/example/debug/bdi/InputListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/JDIEventSource.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodBreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/MethodNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/bdi/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoSessionException.java ! src/share/classes/com/sun/tools/example/debug/bdi/NoThreadException.java ! src/share/classes/com/sun/tools/example/debug/bdi/OutputListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/ParseException.java ! src/share/classes/com/sun/tools/example/debug/bdi/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/Session.java ! src/share/classes/com/sun/tools/example/debug/bdi/SessionListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/SourceNameReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecErrorEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecEvent.java ! src/share/classes/com/sun/tools/example/debug/bdi/SpecListener.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/bdi/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/bdi/Utils.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMLaunchFailureException.java ! src/share/classes/com/sun/tools/example/debug/bdi/VMNotInterruptedException.java ! src/share/classes/com/sun/tools/example/debug/bdi/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/event/AbstractEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/AccessWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassPrepareEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ClassUnloadEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ExceptionEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/JDIAdapter.java ! src/share/classes/com/sun/tools/example/debug/event/JDIListener.java ! src/share/classes/com/sun/tools/example/debug/event/LocatableEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/LocationTriggerEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ModificationWatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/ThreadStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDeathEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMDisconnectEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/VMStartEventSet.java ! src/share/classes/com/sun/tools/example/debug/event/WatchpointEventSet.java ! src/share/classes/com/sun/tools/example/debug/expr/ASCII_UCodeESC_CharStream.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserConstants.java ! src/share/classes/com/sun/tools/example/debug/expr/ExpressionParserTokenManager.java ! src/share/classes/com/sun/tools/example/debug/expr/LValue.java ! src/share/classes/com/sun/tools/example/debug/expr/ParseException.java ! src/share/classes/com/sun/tools/example/debug/expr/Token.java ! src/share/classes/com/sun/tools/example/debug/expr/TokenMgrError.java ! src/share/classes/com/sun/tools/example/debug/gui/ApplicationTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassManager.java ! src/share/classes/com/sun/tools/example/debug/gui/ClassTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandInterpreter.java ! src/share/classes/com/sun/tools/example/debug/gui/CommandTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextListener.java ! src/share/classes/com/sun/tools/example/debug/gui/ContextManager.java ! src/share/classes/com/sun/tools/example/debug/gui/CurrentFrameChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/Environment.java ! src/share/classes/com/sun/tools/example/debug/gui/GUI.java ! src/share/classes/com/sun/tools/example/debug/gui/Icons.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBFileFilter.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBMenuBar.java ! src/share/classes/com/sun/tools/example/debug/gui/JDBToolBar.java ! src/share/classes/com/sun/tools/example/debug/gui/LaunchTool.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorListModel.java ! src/share/classes/com/sun/tools/example/debug/gui/MonitorTool.java ! src/share/classes/com/sun/tools/example/debug/gui/OutputSink.java ! src/share/classes/com/sun/tools/example/debug/gui/SearchPath.java ! src/share/classes/com/sun/tools/example/debug/gui/SingleLeafTreeSelectionModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceListener.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceManager.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceModel.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourceTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/SourcepathChangedEvent.java ! src/share/classes/com/sun/tools/example/debug/gui/StackTraceTool.java ! src/share/classes/com/sun/tools/example/debug/gui/ThreadTreeTool.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScript.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptOutputListener.java ! src/share/classes/com/sun/tools/example/debug/gui/TypeScriptWriter.java ! src/share/classes/com/sun/tools/example/debug/tty/AccessWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/AmbiguousMethodException.java ! src/share/classes/com/sun/tools/example/debug/tty/BreakpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/share/classes/com/sun/tools/example/debug/tty/EventHandler.java ! src/share/classes/com/sun/tools/example/debug/tty/EventNotifier.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/EventRequestSpecList.java ! src/share/classes/com/sun/tools/example/debug/tty/ExceptionSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/LineNotFoundException.java ! src/share/classes/com/sun/tools/example/debug/tty/MalformedMemberNameException.java ! src/share/classes/com/sun/tools/example/debug/tty/MessageOutput.java ! src/share/classes/com/sun/tools/example/debug/tty/ModificationWatchpointSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/PatternReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/ReferenceTypeSpec.java ! src/share/classes/com/sun/tools/example/debug/tty/SourceMapper.java ! src/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadGroupIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadInfo.java ! src/share/classes/com/sun/tools/example/debug/tty/ThreadIterator.java ! src/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/share/classes/com/sun/tools/example/debug/tty/VMNotConnectedException.java ! src/share/classes/com/sun/tools/example/debug/tty/WatchpointSpec.java ! src/share/classes/com/sun/tools/example/trace/EventThread.java ! src/share/classes/com/sun/tools/example/trace/StreamRedirectThread.java ! src/share/classes/com/sun/tools/example/trace/Trace.java ! src/share/classes/com/sun/tools/jdi/ArrayReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ArrayTypeImpl.java ! src/share/classes/com/sun/tools/jdi/BooleanValueImpl.java ! src/share/classes/com/sun/tools/jdi/CharValueImpl.java ! src/share/classes/com/sun/tools/jdi/ClassLoaderReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java ! src/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/share/classes/com/sun/tools/jdi/DoubleValueImpl.java ! src/share/classes/com/sun/tools/jdi/EventRequestManagerImpl.java ! src/share/classes/com/sun/tools/jdi/EventSetImpl.java ! src/share/classes/com/sun/tools/jdi/FloatValueImpl.java ! src/share/classes/com/sun/tools/jdi/GenericAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/IntegerValueImpl.java ! src/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/InternalEventHandler.java ! src/share/classes/com/sun/tools/jdi/JDWPException.java ! src/share/classes/com/sun/tools/jdi/LongValueImpl.java ! src/share/classes/com/sun/tools/jdi/MethodImpl.java ! src/share/classes/com/sun/tools/jdi/MirrorImpl.java ! src/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ProcessAttachingConnector.java ! src/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/share/classes/com/sun/tools/jdi/ShortValueImpl.java ! src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/share/classes/com/sun/tools/jdi/TargetVM.java ! src/share/classes/com/sun/tools/jdi/ThreadAction.java ! src/share/classes/com/sun/tools/jdi/ThreadGroupReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/share/classes/com/sun/tools/jdi/VMAction.java ! src/share/classes/com/sun/tools/jdi/VMState.java ! src/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/share/classes/java/applet/Applet.java ! src/share/classes/java/io/Closeable.java ! src/share/classes/java/io/ExpiringCache.java ! src/share/classes/java/io/InputStream.java ! src/share/classes/java/io/LineNumberReader.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/io/Reader.java ! src/share/classes/java/io/SequenceInputStream.java ! src/share/classes/java/io/Writer.java ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/lang/CharacterData.java ! src/share/classes/java/lang/CharacterName.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassValue.java ! src/share/classes/java/lang/ConditionalSpecialCasing.java ! src/share/classes/java/lang/Enum.java ! src/share/classes/java/lang/EnumConstantNotPresentException.java ! src/share/classes/java/lang/InheritableThreadLocal.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/Object.java ! src/share/classes/java/lang/Override.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/SecurityManager.java ! src/share/classes/java/lang/StrictMath.java ! src/share/classes/java/lang/StringBuilder.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/lang/ThreadLocal.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/lang/Void.java ! src/share/classes/java/lang/annotation/Annotation.java ! src/share/classes/java/lang/instrument/ClassDefinition.java ! src/share/classes/java/lang/instrument/ClassFileTransformer.java ! src/share/classes/java/lang/instrument/Instrumentation.java ! src/share/classes/java/lang/invoke/CallSite.java ! src/share/classes/java/lang/invoke/DirectMethodHandle.java ! src/share/classes/java/lang/invoke/Invokers.java ! src/share/classes/java/lang/invoke/MemberName.java ! src/share/classes/java/lang/invoke/MethodHandle.java ! src/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/share/classes/java/lang/invoke/MethodTypeForm.java ! src/share/classes/java/lang/invoke/SimpleMethodHandle.java ! src/share/classes/java/lang/invoke/WrongMethodTypeException.java ! src/share/classes/java/lang/invoke/package-info.java ! src/share/classes/java/lang/management/BufferPoolMXBean.java ! src/share/classes/java/lang/management/LockInfo.java ! src/share/classes/java/lang/management/ManagementPermission.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/lang/management/PlatformLoggingMXBean.java ! src/share/classes/java/lang/management/PlatformManagedObject.java ! src/share/classes/java/lang/management/ThreadInfo.java ! src/share/classes/java/lang/management/package.html ! src/share/classes/java/lang/ref/Reference.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/Array.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/GenericDeclaration.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/TypeVariable.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/DatagramPacket.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/InMemoryCookieStore.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/ProxySelector.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/SocketImpl.java ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocketOption.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/StandardSocketOptions.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/net/URLStreamHandler.java ! src/share/classes/java/net/package.html ! src/share/classes/java/nio/MappedByteBuffer.java ! src/share/classes/java/nio/X-Buffer.java.template ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/Channels.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/MulticastChannel.java ! src/share/classes/java/nio/channels/NetworkChannel.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/StandardWatchEventKinds.java ! src/share/classes/java/nio/file/Watchable.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/rmi/MarshalledObject.java ! src/share/classes/java/rmi/dgc/VMID.java ! src/share/classes/java/rmi/server/LogStream.java ! src/share/classes/java/rmi/server/RemoteObject.java ! src/share/classes/java/security/AllPermission.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/KeyRep.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/CollectionCertStoreParameters.java ! src/share/classes/java/security/cert/LDAPCertStoreParameters.java ! src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java ! src/share/classes/java/security/cert/PKIXParameters.java ! src/share/classes/java/security/cert/X509CRL.java ! src/share/classes/java/security/cert/X509Certificate.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/Date.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/sql/Time.java ! src/share/classes/java/text/AttributedCharacterIterator.java ! src/share/classes/java/text/AttributedString.java ! src/share/classes/java/text/BreakIterator.java ! src/share/classes/java/text/CharacterIteratorFieldDelegate.java ! src/share/classes/java/text/ChoiceFormat.java ! src/share/classes/java/text/CollationElementIterator.java ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DigitList.java ! src/share/classes/java/text/Format.java ! src/share/classes/java/text/MergeCollation.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/ParseException.java ! src/share/classes/java/text/RBCollationTables.java ! src/share/classes/java/text/RBTableBuilder.java ! src/share/classes/java/text/StringCharacterIterator.java ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/AbstractSet.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/EnumMap.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/IllegalFormatConversionException.java ! src/share/classes/java/util/InvalidPropertiesFormatException.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/ListIterator.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Observable.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/RegularEnumSet.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedMap.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/UUID.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/logging/Handler.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/logging/LoggingMXBean.java ! src/share/classes/java/util/logging/LoggingProxyImpl.java ! src/share/classes/java/util/logging/SimpleFormatter.java ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/prefs/XmlSupport.java ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/spi/CurrencyNameProvider.java ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/DeflaterOutputStream.java ! src/share/classes/java/util/zip/GZIPInputStream.java ! src/share/classes/java/util/zip/Inflater.java ! src/share/classes/java/util/zip/ZipCoder.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/javax/accessibility/AccessibleContext.java ! src/share/classes/javax/crypto/CryptoAllPermission.java ! src/share/classes/javax/crypto/CryptoPermission.java ! src/share/classes/javax/crypto/CryptoPolicyParser.java ! src/share/classes/javax/crypto/NullCipherSpi.java ! src/share/classes/javax/imageio/metadata/IIOMetadataNode.java ! src/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java ! src/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/management/openmbean/TabularDataSupport.java ! src/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/timer/Timer.java ! src/share/classes/javax/management/timer/TimerAlarmClock.java ! src/share/classes/javax/naming/spi/NamingManager.java ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java ! src/share/classes/javax/script/ScriptEngineManager.java ! src/share/classes/javax/script/ScriptException.java ! src/share/classes/javax/security/auth/Subject.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/javax/security/auth/login/LoginContext.java ! src/share/classes/javax/security/cert/CertificateEncodingException.java ! src/share/classes/javax/security/cert/CertificateException.java ! src/share/classes/javax/security/cert/CertificateExpiredException.java ! src/share/classes/javax/security/cert/CertificateNotYetValidException.java ! src/share/classes/javax/security/cert/X509Certificate.java ! src/share/classes/javax/security/sasl/Sasl.java ! src/share/classes/javax/security/sasl/SaslServerFactory.java ! src/share/classes/javax/smartcardio/TerminalFactory.java ! src/share/classes/javax/sql/ConnectionPoolDataSource.java ! src/share/classes/javax/sql/PooledConnection.java ! src/share/classes/javax/sql/StatementEvent.java ! src/share/classes/javax/sql/rowset/RowSetMetaDataImpl.java ! src/share/classes/javax/sql/rowset/RowSetProvider.java ! src/share/classes/javax/sql/rowset/package.html ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/spi/SyncProvider.java ! src/share/classes/javax/xml/crypto/NodeSetData.java ! src/share/classes/javax/xml/crypto/dom/DOMCryptoContext.java ! src/share/classes/javax/xml/crypto/dsig/Manifest.java ! src/share/classes/javax/xml/crypto/dsig/Reference.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperties.java ! src/share/classes/javax/xml/crypto/dsig/SignatureProperty.java ! src/share/classes/javax/xml/crypto/dsig/SignedInfo.java ! src/share/classes/javax/xml/crypto/dsig/TransformService.java ! src/share/classes/javax/xml/crypto/dsig/XMLObject.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignature.java ! src/share/classes/javax/xml/crypto/dsig/XMLSignatureFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfo.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/KeyInfoFactory.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/PGPData.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/RetrievalMethod.java ! src/share/classes/javax/xml/crypto/dsig/keyinfo/X509Data.java ! src/share/classes/javax/xml/crypto/dsig/spec/ExcC14NParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilter2ParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathFilterParameterSpec.java ! src/share/classes/javax/xml/crypto/dsig/spec/XPathType.java ! src/share/classes/org/ietf/jgss/Oid.java ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/instrument/InstrumentationImpl.java ! src/share/classes/sun/instrument/TransformerManager.java ! src/share/classes/sun/invoke/util/VerifyAccess.java ! src/share/classes/sun/invoke/util/VerifyType.java ! src/share/classes/sun/invoke/util/Wrapper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/management/ConnectorAddressLink.java ! src/share/classes/sun/management/Flag.java ! src/share/classes/sun/management/GarbageCollectionNotifInfoCompositeData.java ! src/share/classes/sun/management/GarbageCollectorImpl.java ! src/share/classes/sun/management/GcInfoBuilder.java ! src/share/classes/sun/management/GcInfoCompositeData.java ! src/share/classes/sun/management/HotspotCompilation.java ! src/share/classes/sun/management/HotspotThread.java ! src/share/classes/sun/management/LazyCompositeData.java ! src/share/classes/sun/management/ManagementFactoryHelper.java ! src/share/classes/sun/management/MappedMXBeanType.java ! src/share/classes/sun/management/MonitorInfoCompositeData.java ! src/share/classes/sun/management/NotificationEmitterSupport.java ! src/share/classes/sun/management/RuntimeImpl.java ! src/share/classes/sun/management/ThreadInfoCompositeData.java ! src/share/classes/sun/management/counter/perf/PerfDataEntry.java ! src/share/classes/sun/management/counter/perf/PerfDataType.java ! src/share/classes/sun/management/counter/perf/PerfInstrumentation.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java ! src/share/classes/sun/management/snmp/jvminstr/JVM_MANAGEMENT_MIB_IMPL.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemGCTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemManagerTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemMgrPoolRelTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemPoolTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmMemoryMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmOSImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTBootClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTClassPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTInputArgsTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRTLibraryPathTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmRuntimeMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceEntryImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadInstanceTableMetaImpl.java ! src/share/classes/sun/management/snmp/jvminstr/JvmThreadingMetaImpl.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmClassesVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmJITCompilerTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemManagerState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolCollectThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolState.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolThreshdSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemPoolType.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCCall.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmMemoryGCVerboseLevel.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmRTBootClassPathSupport.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadContentionMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/EnumJvmThreadCpuTimeMonitoring.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIB.java ! src/share/classes/sun/management/snmp/jvmmib/JVM_MANAGEMENT_MIBOidTable.java ! src/share/classes/sun/management/snmp/jvmmib/JvmClassLoadingMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmCompilationMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemGCTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemManagerTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemMgrPoolRelTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmMemPoolTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmOSMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTBootClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTClassPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTInputArgsTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRTLibraryPathTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmRuntimeMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceEntryMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadInstanceTableMeta.java ! src/share/classes/sun/management/snmp/jvmmib/JvmThreadingMeta.java ! src/share/classes/sun/management/snmp/util/MibLogger.java ! src/share/classes/sun/management/snmp/util/SnmpListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpNamedListTableCache.java ! src/share/classes/sun/management/snmp/util/SnmpTableCache.java ! src/share/classes/sun/misc/BASE64Decoder.java ! src/share/classes/sun/misc/CEFormatException.java ! src/share/classes/sun/misc/CEStreamExhausted.java ! src/share/classes/sun/misc/ClassLoaderUtil.java ! src/share/classes/sun/misc/CompoundEnumeration.java ! src/share/classes/sun/misc/ExtensionDependency.java ! src/share/classes/sun/misc/ExtensionInstallationException.java ! src/share/classes/sun/misc/FDBigInt.java ! src/share/classes/sun/misc/FloatingDecimal.java ! src/share/classes/sun/misc/InvalidJarIndexException.java ! src/share/classes/sun/misc/JarIndex.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/misc/LRUCache.java ! src/share/classes/sun/misc/MetaIndex.java ! src/share/classes/sun/misc/ProxyGenerator.java ! src/share/classes/sun/misc/Queue.java ! src/share/classes/sun/misc/REException.java ! src/share/classes/sun/misc/RequestProcessor.java ! src/share/classes/sun/misc/Service.java ! src/share/classes/sun/misc/ServiceConfigurationError.java ! src/share/classes/sun/misc/Signal.java ! src/share/classes/sun/misc/Unsafe.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/NetworkServer.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/httpserver/Event.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/WriteFinishedEvent.java ! src/share/classes/sun/net/sdp/SdpSupport.java ! src/share/classes/sun/net/smtp/SmtpClient.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java ! src/share/classes/sun/net/www/http/ChunkedOutputStream.java ! src/share/classes/sun/net/www/http/KeepAliveCleanerEntry.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java ! src/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/share/classes/sun/net/www/protocol/mailto/Handler.java ! src/share/classes/sun/nio/ch/AbstractPollArrayWrapper.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/ExtendedSocketOption.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/NativeThreadSet.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/SelChImpl.java ! src/share/classes/sun/nio/ch/SelectionKeyImpl.java ! src/share/classes/sun/nio/ch/SelectorImpl.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/nio/ch/sctp/MessageInfoImpl.java ! src/share/classes/sun/nio/ch/sctp/SctpStdSocketOption.java ! src/share/classes/sun/nio/cs/AbstractCharsetProvider.java ! src/share/classes/sun/nio/cs/SingleByte.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/HKSCS.java ! src/share/classes/sun/nio/cs/ext/IBM33722.java ! src/share/classes/sun/nio/cs/ext/IBM834.java ! src/share/classes/sun/nio/cs/ext/IBM964.java ! src/share/classes/sun/nio/cs/ext/ISCII91.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP.java ! src/share/classes/sun/nio/cs/ext/ISO2022_JP_2.java ! src/share/classes/sun/nio/cs/ext/MS50220.java ! src/share/classes/sun/nio/cs/ext/MS50221.java ! src/share/classes/sun/nio/cs/ext/MSISO2022JP.java ! src/share/classes/sun/nio/cs/standard-charsets ! src/share/classes/sun/print/RasterPrinterJob.java ! src/share/classes/sun/print/ServiceDialog.java ! src/share/classes/sun/reflect/AccessorGenerator.java ! src/share/classes/sun/reflect/BootstrapConstructorAccessorImpl.java ! src/share/classes/sun/reflect/ClassDefiner.java ! src/share/classes/sun/reflect/ConstantPool.java ! src/share/classes/sun/reflect/Label.java ! src/share/classes/sun/reflect/MethodAccessorGenerator.java ! src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java ! src/share/classes/sun/reflect/Reflection.java ! src/share/classes/sun/reflect/ReflectionFactory.java ! src/share/classes/sun/reflect/UTF8.java ! src/share/classes/sun/reflect/UnsafeFieldAccessorFactory.java ! src/share/classes/sun/reflect/UnsafeFieldAccessorImpl.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/classes/sun/reflect/generics/repository/GenericDeclRepository.java ! src/share/classes/sun/reflect/generics/scope/AbstractScope.java ! src/share/classes/sun/reflect/generics/scope/ConstructorScope.java ! src/share/classes/sun/reflect/generics/tree/ClassSignature.java ! src/share/classes/sun/reflect/generics/tree/MethodTypeSignature.java ! src/share/classes/sun/reflect/misc/ReflectUtil.java ! src/share/classes/sun/rmi/log/ReliableLog.java ! src/share/classes/sun/rmi/registry/RegistryImpl.java ! src/share/classes/sun/rmi/rmic/BatchEnvironment.java ! src/share/classes/sun/rmi/rmic/Main.java ! src/share/classes/sun/rmi/rmic/RMIGenerator.java ! src/share/classes/sun/rmi/rmic/newrmic/Main.java ! src/share/classes/sun/rmi/rmic/newrmic/Resources.java ! src/share/classes/sun/rmi/server/ActivatableRef.java ! src/share/classes/sun/rmi/server/ActivationGroupImpl.java ! src/share/classes/sun/rmi/server/LoaderHandler.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/classes/sun/rmi/server/UnicastRef.java ! src/share/classes/sun/rmi/server/UnicastRef2.java ! src/share/classes/sun/rmi/server/UnicastServerRef.java ! src/share/classes/sun/rmi/server/Util.java ! src/share/classes/sun/rmi/server/WeakClassHashMap.java ! src/share/classes/sun/rmi/transport/ConnectionInputStream.java ! src/share/classes/sun/rmi/transport/DGCAckHandler.java ! src/share/classes/sun/rmi/transport/DGCClient.java ! src/share/classes/sun/rmi/transport/DGCImpl.java ! src/share/classes/sun/rmi/transport/LiveRef.java ! src/share/classes/sun/rmi/transport/ObjectTable.java ! src/share/classes/sun/rmi/transport/StreamRemoteCall.java ! src/share/classes/sun/rmi/transport/Target.java ! src/share/classes/sun/rmi/transport/Transport.java ! src/share/classes/sun/rmi/transport/WeakRef.java ! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java ! src/share/classes/sun/rmi/transport/proxy/HttpInputStream.java ! src/share/classes/sun/rmi/transport/proxy/HttpSendSocket.java ! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java ! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java ! src/share/classes/sun/rmi/transport/tcp/TCPChannel.java ! src/share/classes/sun/rmi/transport/tcp/TCPEndpoint.java ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java ! src/share/classes/sun/security/ec/ECPublicKeyImpl.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/jgss/krb5/AcceptSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java ! src/share/classes/sun/security/jgss/spi/GSSContextSpi.java ! src/share/classes/sun/security/krb5/Checksum.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! src/share/classes/sun/security/krb5/KrbAsReq.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/KrbCred.java ! src/share/classes/sun/security/krb5/KrbException.java ! src/share/classes/sun/security/krb5/KrbPriv.java ! src/share/classes/sun/security/krb5/KrbSafe.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/RealmException.java ! src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/NetClient.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/CksumType.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTabInputStream.java ! src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java ! src/share/classes/sun/security/pkcs11/Config.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/provider/DigestBase.java ! src/share/classes/sun/security/provider/JavaKeyStore.java ! src/share/classes/sun/security/provider/MD2.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/MD5.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/SHA.java ! src/share/classes/sun/security/provider/SHA5.java ! src/share/classes/sun/security/smartcardio/PCSC.java ! src/share/classes/sun/security/smartcardio/TerminalImpl.java ! src/share/classes/sun/security/ssl/ExtensionType.java ! src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java ! src/share/classes/sun/security/ssl/ServerNameExtension.java ! src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java ! src/share/classes/sun/security/ssl/UnknownExtension.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! src/share/classes/sun/security/util/Debug.java ! src/share/classes/sun/security/util/HostnameChecker.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/classes/sun/security/x509/CRLExtensions.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/DNSName.java ! src/share/classes/sun/security/x509/RFC822Name.java ! src/share/classes/sun/security/x509/URIName.java ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/security/x509/X509CertInfo.java ! src/share/classes/sun/text/CompactByteArray.java ! src/share/classes/sun/text/IntHashtable.java ! src/share/classes/sun/text/bidi/BidiBase.java ! src/share/classes/sun/text/normalizer/ICUData.java ! src/share/classes/sun/text/normalizer/NormalizerBase.java ! src/share/classes/sun/text/normalizer/NormalizerImpl.java ! src/share/classes/sun/text/normalizer/SymbolTable.java ! src/share/classes/sun/text/normalizer/UnicodeSet.java ! src/share/classes/sun/text/normalizer/UnicodeSetIterator.java ! src/share/classes/sun/text/normalizer/VersionInfo.java ! src/share/classes/sun/tools/attach/HotSpotVirtualMachine.java ! src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider ! src/share/classes/sun/tools/jar/CommandLine.java ! src/share/classes/sun/tools/jar/Manifest.java ! src/share/classes/sun/tools/jar/SignatureFile.java ! src/share/classes/sun/tools/javac/resources/javac.properties ! src/share/classes/sun/tools/jcmd/Arguments.java ! src/share/classes/sun/tools/jconsole/AboutDialog.java ! src/share/classes/sun/tools/jconsole/BorderedComponent.java ! src/share/classes/sun/tools/jconsole/ClassTab.java ! src/share/classes/sun/tools/jconsole/ConnectDialog.java ! src/share/classes/sun/tools/jconsole/CreateMBeanDialog.java ! src/share/classes/sun/tools/jconsole/Formatter.java ! src/share/classes/sun/tools/jconsole/HTMLPane.java ! src/share/classes/sun/tools/jconsole/InternalDialog.java ! src/share/classes/sun/tools/jconsole/JConsole.java ! src/share/classes/sun/tools/jconsole/LabeledComponent.java ! src/share/classes/sun/tools/jconsole/LocalVirtualMachine.java ! src/share/classes/sun/tools/jconsole/MBeansTab.java ! src/share/classes/sun/tools/jconsole/MaximizableInternalFrame.java ! src/share/classes/sun/tools/jconsole/MemoryPoolProxy.java ! src/share/classes/sun/tools/jconsole/MemoryPoolStat.java ! src/share/classes/sun/tools/jconsole/MemoryTab.java ! src/share/classes/sun/tools/jconsole/OverviewPanel.java ! src/share/classes/sun/tools/jconsole/OverviewTab.java ! src/share/classes/sun/tools/jconsole/Plotter.java ! src/share/classes/sun/tools/jconsole/PlotterPanel.java ! src/share/classes/sun/tools/jconsole/ProxyClient.java ! src/share/classes/sun/tools/jconsole/Resources.java ! src/share/classes/sun/tools/jconsole/SummaryTab.java ! src/share/classes/sun/tools/jconsole/Tab.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/VMInternalFrame.java ! src/share/classes/sun/tools/jconsole/VMPanel.java ! src/share/classes/sun/tools/jconsole/VariableGridLayout.java ! src/share/classes/sun/tools/jconsole/Version.java.template ! src/share/classes/sun/tools/jconsole/inspector/OperationEntry.java ! src/share/classes/sun/tools/jconsole/inspector/TableSorter.java ! src/share/classes/sun/tools/jconsole/inspector/ThreadDialog.java ! src/share/classes/sun/tools/jconsole/inspector/Utils.java ! src/share/classes/sun/tools/jconsole/inspector/XArrayDataViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XDataViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanInfo.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanNotifications.java ! src/share/classes/sun/tools/jconsole/inspector/XObject.java ! src/share/classes/sun/tools/jconsole/inspector/XOpenTypeViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XOperations.java ! src/share/classes/sun/tools/jconsole/inspector/XPlotter.java ! src/share/classes/sun/tools/jconsole/inspector/XPlottingViewer.java ! src/share/classes/sun/tools/jconsole/inspector/XSheet.java ! src/share/classes/sun/tools/jconsole/inspector/XTable.java ! src/share/classes/sun/tools/jconsole/inspector/XTextField.java ! src/share/classes/sun/tools/jconsole/inspector/XTree.java ! src/share/classes/sun/tools/jconsole/inspector/XTreeRenderer.java ! src/share/classes/sun/tools/jinfo/JInfo.java ! src/share/classes/sun/tools/jmap/JMap.java ! src/share/classes/sun/tools/jstack/JStack.java ! src/share/classes/sun/tools/serialver/SerialVer.java ! src/share/classes/sun/tools/tree/Node.java ! src/share/classes/sun/tracing/dtrace/DTraceProvider.java ! src/share/classes/sun/tracing/dtrace/JVM.java ! src/share/classes/sun/util/PreHashedMap.java ! src/share/classes/sun/util/calendar/CalendarDate.java ! src/share/classes/sun/util/locale/LocaleUtils.java ! src/share/classes/sun/util/logging/LoggingProxy.java ! src/share/classes/sun/util/logging/LoggingSupport.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/share/classes/sun/util/resources/OpenListResourceBundle.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/ar/CalendarData_ar.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_AE.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_BH.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_DZ.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_EG.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_IQ.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_JO.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_KW.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LB.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_LY.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_MA.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_OM.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_QA.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SA.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SD.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_SY.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_TN.properties ! src/share/classes/sun/util/resources/ar/CurrencyNames_ar_YE.properties ! src/share/classes/sun/util/resources/ar/LocaleNames_ar.properties ! src/share/classes/sun/util/resources/be/CalendarData_be.properties ! src/share/classes/sun/util/resources/be/CurrencyNames_be_BY.properties ! src/share/classes/sun/util/resources/be/LocaleNames_be.properties ! src/share/classes/sun/util/resources/bg/CalendarData_bg.properties ! src/share/classes/sun/util/resources/bg/CurrencyNames_bg_BG.properties ! src/share/classes/sun/util/resources/bg/LocaleNames_bg.properties ! src/share/classes/sun/util/resources/ca/CalendarData_ca.properties ! src/share/classes/sun/util/resources/ca/CurrencyNames_ca_ES.properties ! src/share/classes/sun/util/resources/ca/LocaleNames_ca.properties ! src/share/classes/sun/util/resources/cs/CalendarData_cs.properties ! src/share/classes/sun/util/resources/cs/CurrencyNames_cs_CZ.properties ! src/share/classes/sun/util/resources/cs/LocaleNames_cs.properties ! src/share/classes/sun/util/resources/da/CalendarData_da.properties ! src/share/classes/sun/util/resources/da/CurrencyNames_da_DK.properties ! src/share/classes/sun/util/resources/da/LocaleNames_da.properties ! src/share/classes/sun/util/resources/de/CalendarData_de.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_AT.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_CH.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_DE.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_GR.properties ! src/share/classes/sun/util/resources/de/CurrencyNames_de_LU.properties ! src/share/classes/sun/util/resources/de/LocaleNames_de.properties ! src/share/classes/sun/util/resources/el/CalendarData_el.properties ! src/share/classes/sun/util/resources/el/CalendarData_el_CY.properties ! src/share/classes/sun/util/resources/el/CurrencyNames_el_CY.properties ! src/share/classes/sun/util/resources/el/CurrencyNames_el_GR.properties ! src/share/classes/sun/util/resources/el/LocaleNames_el.properties ! src/share/classes/sun/util/resources/el/LocaleNames_el_CY.properties ! src/share/classes/sun/util/resources/en/CalendarData_en.properties ! src/share/classes/sun/util/resources/en/CalendarData_en_GB.properties ! src/share/classes/sun/util/resources/en/CalendarData_en_IE.properties ! src/share/classes/sun/util/resources/en/CalendarData_en_MT.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_AU.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_CA.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_GB.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_IE.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_IN.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_MT.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_NZ.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_PH.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_SG.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_US.properties ! src/share/classes/sun/util/resources/en/CurrencyNames_en_ZA.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en_MT.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en_PH.properties ! src/share/classes/sun/util/resources/en/LocaleNames_en_SG.properties ! src/share/classes/sun/util/resources/es/CalendarData_es.properties ! src/share/classes/sun/util/resources/es/CalendarData_es_ES.properties ! src/share/classes/sun/util/resources/es/CalendarData_es_US.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_AR.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_BO.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CL.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CO.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CR.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_CU.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_DO.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_EC.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_ES.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_GT.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_HN.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_MX.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_NI.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_PA.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_PR.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_PY.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_SV.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_US.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_UY.properties ! src/share/classes/sun/util/resources/es/CurrencyNames_es_VE.properties ! src/share/classes/sun/util/resources/es/LocaleNames_es.properties ! src/share/classes/sun/util/resources/es/LocaleNames_es_US.properties ! src/share/classes/sun/util/resources/et/CalendarData_et.properties ! src/share/classes/sun/util/resources/et/CurrencyNames_et_EE.properties ! src/share/classes/sun/util/resources/et/LocaleNames_et.properties ! src/share/classes/sun/util/resources/fi/CalendarData_fi.properties ! src/share/classes/sun/util/resources/fi/CurrencyNames_fi_FI.properties ! src/share/classes/sun/util/resources/fi/LocaleNames_fi.properties ! src/share/classes/sun/util/resources/fr/CalendarData_fr.properties ! src/share/classes/sun/util/resources/fr/CalendarData_fr_CA.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_BE.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CA.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_CH.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_FR.properties ! src/share/classes/sun/util/resources/fr/CurrencyNames_fr_LU.properties ! src/share/classes/sun/util/resources/fr/LocaleNames_fr.properties ! src/share/classes/sun/util/resources/ga/CurrencyNames_ga_IE.properties ! src/share/classes/sun/util/resources/ga/LocaleNames_ga.properties ! src/share/classes/sun/util/resources/hi/CalendarData_hi.properties ! src/share/classes/sun/util/resources/hi/CurrencyNames_hi_IN.properties ! src/share/classes/sun/util/resources/hi/LocaleNames_hi.properties ! src/share/classes/sun/util/resources/hr/CalendarData_hr.properties ! src/share/classes/sun/util/resources/hr/CurrencyNames_hr_HR.properties ! src/share/classes/sun/util/resources/hr/LocaleNames_hr.properties ! src/share/classes/sun/util/resources/hu/CalendarData_hu.properties ! src/share/classes/sun/util/resources/hu/CurrencyNames_hu_HU.properties ! src/share/classes/sun/util/resources/hu/LocaleNames_hu.properties ! src/share/classes/sun/util/resources/in/CalendarData_in_ID.properties ! src/share/classes/sun/util/resources/in/CurrencyNames_in_ID.properties ! src/share/classes/sun/util/resources/in/LocaleNames_in.properties ! src/share/classes/sun/util/resources/is/CalendarData_is.properties ! src/share/classes/sun/util/resources/is/CurrencyNames_is_IS.properties ! src/share/classes/sun/util/resources/is/LocaleNames_is.properties ! src/share/classes/sun/util/resources/it/CalendarData_it.properties ! src/share/classes/sun/util/resources/it/CurrencyNames_it.properties ! src/share/classes/sun/util/resources/it/CurrencyNames_it_CH.properties ! src/share/classes/sun/util/resources/it/CurrencyNames_it_IT.properties ! src/share/classes/sun/util/resources/it/LocaleNames_it.properties ! src/share/classes/sun/util/resources/iw/CalendarData_iw.properties ! src/share/classes/sun/util/resources/iw/CurrencyNames_iw_IL.properties ! src/share/classes/sun/util/resources/iw/LocaleNames_iw.properties ! src/share/classes/sun/util/resources/ja/CalendarData_ja.properties ! src/share/classes/sun/util/resources/ja/CurrencyNames_ja.properties ! src/share/classes/sun/util/resources/ja/CurrencyNames_ja_JP.properties ! src/share/classes/sun/util/resources/ja/LocaleNames_ja.properties ! src/share/classes/sun/util/resources/ko/CalendarData_ko.properties ! src/share/classes/sun/util/resources/ko/CurrencyNames_ko.properties ! src/share/classes/sun/util/resources/ko/CurrencyNames_ko_KR.properties ! src/share/classes/sun/util/resources/ko/LocaleNames_ko.properties ! src/share/classes/sun/util/resources/lt/CalendarData_lt.properties ! src/share/classes/sun/util/resources/lt/CurrencyNames_lt_LT.properties ! src/share/classes/sun/util/resources/lt/LocaleNames_lt.properties ! src/share/classes/sun/util/resources/lv/CalendarData_lv.properties ! src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties ! src/share/classes/sun/util/resources/lv/LocaleNames_lv.properties ! src/share/classes/sun/util/resources/mk/CalendarData_mk.properties ! src/share/classes/sun/util/resources/mk/CurrencyNames_mk_MK.properties ! src/share/classes/sun/util/resources/mk/LocaleNames_mk.properties ! src/share/classes/sun/util/resources/ms/CalendarData_ms_MY.properties ! src/share/classes/sun/util/resources/ms/CurrencyNames_ms_MY.properties ! src/share/classes/sun/util/resources/ms/LocaleNames_ms.properties ! src/share/classes/sun/util/resources/mt/CalendarData_mt.properties ! src/share/classes/sun/util/resources/mt/CalendarData_mt_MT.properties ! src/share/classes/sun/util/resources/mt/CurrencyNames_mt_MT.properties ! src/share/classes/sun/util/resources/mt/LocaleNames_mt.properties ! src/share/classes/sun/util/resources/nl/CalendarData_nl.properties ! src/share/classes/sun/util/resources/nl/CurrencyNames_nl_BE.properties ! src/share/classes/sun/util/resources/nl/CurrencyNames_nl_NL.properties ! src/share/classes/sun/util/resources/nl/LocaleNames_nl.properties ! src/share/classes/sun/util/resources/no/CalendarData_no.properties ! src/share/classes/sun/util/resources/no/CurrencyNames_no_NO.properties ! src/share/classes/sun/util/resources/no/LocaleNames_no.properties ! src/share/classes/sun/util/resources/no/LocaleNames_no_NO_NY.properties ! src/share/classes/sun/util/resources/pl/CalendarData_pl.properties ! src/share/classes/sun/util/resources/pl/CurrencyNames_pl_PL.properties ! src/share/classes/sun/util/resources/pl/LocaleNames_pl.properties ! src/share/classes/sun/util/resources/pt/CalendarData_pt.properties ! src/share/classes/sun/util/resources/pt/CalendarData_pt_PT.properties ! src/share/classes/sun/util/resources/pt/CurrencyNames_pt.properties ! src/share/classes/sun/util/resources/pt/CurrencyNames_pt_BR.properties ! src/share/classes/sun/util/resources/pt/CurrencyNames_pt_PT.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt_BR.properties ! src/share/classes/sun/util/resources/pt/LocaleNames_pt_PT.properties ! src/share/classes/sun/util/resources/ro/CalendarData_ro.properties ! src/share/classes/sun/util/resources/ro/CurrencyNames_ro_RO.properties ! src/share/classes/sun/util/resources/ro/LocaleNames_ro.properties ! src/share/classes/sun/util/resources/ru/CalendarData_ru.properties ! src/share/classes/sun/util/resources/ru/CurrencyNames_ru_RU.properties ! src/share/classes/sun/util/resources/ru/LocaleNames_ru.properties ! src/share/classes/sun/util/resources/sk/CalendarData_sk.properties ! src/share/classes/sun/util/resources/sk/CurrencyNames_sk_SK.properties ! src/share/classes/sun/util/resources/sk/LocaleNames_sk.properties ! src/share/classes/sun/util/resources/sl/CalendarData_sl.properties ! src/share/classes/sun/util/resources/sl/CurrencyNames_sl_SI.properties ! src/share/classes/sun/util/resources/sl/LocaleNames_sl.properties ! src/share/classes/sun/util/resources/sq/CalendarData_sq.properties ! src/share/classes/sun/util/resources/sq/CurrencyNames_sq_AL.properties ! src/share/classes/sun/util/resources/sq/LocaleNames_sq.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_BA.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_ME.properties ! src/share/classes/sun/util/resources/sr/CalendarData_sr_Latn_RS.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_BA.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_CS.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_BA.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_ME.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_Latn_RS.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_ME.properties ! src/share/classes/sun/util/resources/sr/CurrencyNames_sr_RS.properties ! src/share/classes/sun/util/resources/sr/LocaleNames_sr.properties ! src/share/classes/sun/util/resources/sr/LocaleNames_sr_Latn.properties ! src/share/classes/sun/util/resources/sv/CalendarData_sv.properties ! src/share/classes/sun/util/resources/sv/CurrencyNames_sv.properties ! src/share/classes/sun/util/resources/sv/CurrencyNames_sv_SE.properties ! src/share/classes/sun/util/resources/sv/LocaleNames_sv.properties ! src/share/classes/sun/util/resources/th/CalendarData_th.properties ! src/share/classes/sun/util/resources/th/CurrencyNames_th_TH.properties ! src/share/classes/sun/util/resources/th/LocaleNames_th.properties ! src/share/classes/sun/util/resources/tr/CalendarData_tr.properties ! src/share/classes/sun/util/resources/tr/CurrencyNames_tr_TR.properties ! src/share/classes/sun/util/resources/tr/LocaleNames_tr.properties ! src/share/classes/sun/util/resources/uk/CalendarData_uk.properties ! src/share/classes/sun/util/resources/uk/CurrencyNames_uk_UA.properties ! src/share/classes/sun/util/resources/uk/LocaleNames_uk.properties ! src/share/classes/sun/util/resources/vi/CalendarData_vi.properties ! src/share/classes/sun/util/resources/vi/CurrencyNames_vi_VN.properties ! src/share/classes/sun/util/resources/vi/LocaleNames_vi.properties ! src/share/classes/sun/util/resources/zh/CalendarData_zh.properties ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_CN.properties ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_TW.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_SG.properties ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_TW.properties ! src/share/classes/sun/util/xml/PlatformXmlPropertiesProvider.java ! src/share/demo/jfc/Font2DTest/Font2DTest.java ! src/share/demo/jfc/Font2DTest/Font2DTestApplet.java ! src/share/demo/jfc/Font2DTest/FontPanel.java ! src/share/demo/jfc/Notepad/Notepad.java ! src/share/demo/jvmti/agent_util/agent_util.c ! src/share/demo/jvmti/agent_util/agent_util.h ! src/share/demo/jvmti/compiledMethodLoad/compiledMethodLoad.c ! src/share/demo/jvmti/compiledMethodLoad/sample.makefile.txt ! src/share/demo/jvmti/gctest/gctest.c ! src/share/demo/jvmti/gctest/sample.makefile.txt ! src/share/demo/jvmti/heapTracker/HeapTracker.java ! src/share/demo/jvmti/heapTracker/heapTracker.c ! src/share/demo/jvmti/heapTracker/heapTracker.h ! src/share/demo/jvmti/heapTracker/sample.makefile.txt ! src/share/demo/jvmti/heapViewer/heapViewer.c ! src/share/demo/jvmti/heapViewer/sample.makefile.txt ! src/share/demo/jvmti/hprof/debug_malloc.c ! src/share/demo/jvmti/hprof/debug_malloc.h ! src/share/demo/jvmti/hprof/hprof.h ! src/share/demo/jvmti/hprof/hprof_blocks.c ! src/share/demo/jvmti/hprof/hprof_blocks.h ! src/share/demo/jvmti/hprof/hprof_check.c ! src/share/demo/jvmti/hprof/hprof_check.h ! src/share/demo/jvmti/hprof/hprof_class.c ! src/share/demo/jvmti/hprof/hprof_class.h ! src/share/demo/jvmti/hprof/hprof_cpu.c ! src/share/demo/jvmti/hprof/hprof_cpu.h ! src/share/demo/jvmti/hprof/hprof_error.c ! src/share/demo/jvmti/hprof/hprof_error.h ! src/share/demo/jvmti/hprof/hprof_event.c ! src/share/demo/jvmti/hprof/hprof_event.h ! src/share/demo/jvmti/hprof/hprof_frame.c ! src/share/demo/jvmti/hprof/hprof_frame.h ! src/share/demo/jvmti/hprof/hprof_init.c ! src/share/demo/jvmti/hprof/hprof_init.h ! src/share/demo/jvmti/hprof/hprof_io.c ! src/share/demo/jvmti/hprof/hprof_io.h ! src/share/demo/jvmti/hprof/hprof_ioname.c ! src/share/demo/jvmti/hprof/hprof_ioname.h ! src/share/demo/jvmti/hprof/hprof_listener.c ! src/share/demo/jvmti/hprof/hprof_listener.h ! src/share/demo/jvmti/hprof/hprof_loader.c ! src/share/demo/jvmti/hprof/hprof_loader.h ! src/share/demo/jvmti/hprof/hprof_md.h ! src/share/demo/jvmti/hprof/hprof_monitor.c ! src/share/demo/jvmti/hprof/hprof_monitor.h ! src/share/demo/jvmti/hprof/hprof_object.c ! src/share/demo/jvmti/hprof/hprof_object.h ! src/share/demo/jvmti/hprof/hprof_reference.c ! src/share/demo/jvmti/hprof/hprof_reference.h ! src/share/demo/jvmti/hprof/hprof_site.c ! src/share/demo/jvmti/hprof/hprof_site.h ! src/share/demo/jvmti/hprof/hprof_stack.c ! src/share/demo/jvmti/hprof/hprof_stack.h ! src/share/demo/jvmti/hprof/hprof_string.c ! src/share/demo/jvmti/hprof/hprof_string.h ! src/share/demo/jvmti/hprof/hprof_table.c ! src/share/demo/jvmti/hprof/hprof_table.h ! src/share/demo/jvmti/hprof/hprof_tag.c ! src/share/demo/jvmti/hprof/hprof_tag.h ! src/share/demo/jvmti/hprof/hprof_tls.c ! src/share/demo/jvmti/hprof/hprof_tls.h ! src/share/demo/jvmti/hprof/hprof_trace.c ! src/share/demo/jvmti/hprof/hprof_trace.h ! src/share/demo/jvmti/hprof/hprof_tracker.c ! src/share/demo/jvmti/hprof/hprof_tracker.h ! src/share/demo/jvmti/hprof/hprof_util.c ! src/share/demo/jvmti/hprof/hprof_util.h ! src/share/demo/jvmti/hprof/sample.makefile.txt ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.h ! src/share/demo/jvmti/java_crw_demo/sample.makefile.txt ! src/share/demo/jvmti/minst/Minst.java ! src/share/demo/jvmti/minst/minst.c ! src/share/demo/jvmti/minst/minst.h ! src/share/demo/jvmti/minst/sample.makefile.txt ! src/share/demo/jvmti/mtrace/Mtrace.java ! src/share/demo/jvmti/mtrace/mtrace.c ! src/share/demo/jvmti/mtrace/mtrace.h ! src/share/demo/jvmti/mtrace/sample.makefile.txt ! src/share/demo/jvmti/versionCheck/sample.makefile.txt ! src/share/demo/jvmti/versionCheck/versionCheck.c ! src/share/demo/jvmti/waiters/Agent.cpp ! src/share/demo/jvmti/waiters/Agent.hpp ! src/share/demo/jvmti/waiters/Monitor.cpp ! src/share/demo/jvmti/waiters/Monitor.hpp ! src/share/demo/jvmti/waiters/Thread.cpp ! src/share/demo/jvmti/waiters/Thread.hpp ! src/share/demo/jvmti/waiters/sample.makefile.txt ! src/share/demo/jvmti/waiters/waiters.cpp ! src/share/demo/management/FullThreadDump/Deadlock.java ! src/share/demo/management/FullThreadDump/FullThreadDump.java ! src/share/demo/management/FullThreadDump/ThreadMonitor.java ! src/share/demo/management/JTop/JTop.java ! src/share/demo/management/JTop/JTopPlugin.java ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java ! src/share/demo/management/MemoryMonitor/README.txt ! src/share/demo/management/VerboseGC/PrintGCStat.java ! src/share/demo/management/VerboseGC/VerboseGC.java ! src/share/demo/nbproject/project.xml ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/JarFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipCoder.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributes.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipInfo.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipUtils.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/EditableAtEndDocument.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptJConsolePlugin.java ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java ! src/share/demo/scripting/jconsole-plugin/src/resources/jconsole.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/heapdump.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/hello.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/invoke.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jstack.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jtop.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/sysprops.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/verbose.js ! src/share/instrument/JPLISAssert.h ! src/share/javavm/export/classfile_constants.h ! src/share/javavm/export/jawt.h ! src/share/javavm/export/jmm.h ! src/share/javavm/export/jvm.h ! src/share/native/com/sun/java/util/jar/pack/main.cpp ! src/share/native/common/check_code.c ! src/share/native/common/jdk_util.h ! src/share/native/java/io/ObjectInputStream.c ! src/share/native/java/io/io_util.h ! src/share/native/java/lang/System.c ! src/share/native/java/lang/Thread.c ! src/share/native/java/lang/fdlibm/include/fdlibm.h ! src/share/native/java/lang/fdlibm/include/jfdlibm.h ! src/share/native/java/lang/java_props.h ! src/share/native/java/util/zip/Adler32.c ! src/share/native/java/util/zip/CRC32.c ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/sun/misc/VM.c ! src/share/native/sun/nio/ch/genSocketOptionRegistry.c ! src/share/native/sun/security/ec/impl/ecc_impl.h ! src/share/native/sun/security/ec/impl/ecdecode.c ! src/share/native/sun/security/ec/impl/oid.c ! src/share/native/sun/security/ec/impl/secitem.c ! src/share/native/sun/security/krb5/nativeccache.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/npt/utf.h ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScanner.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/DirectoryScannerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManager.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ResultLogManagerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirAgent.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirClient.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanDirConfigMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManager.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/ScanManagerMXBean.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/DirectoryScannerConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/FileMatch.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultLogConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ResultRecord.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/ScanManagerConfig.java ! src/share/sample/jmx/jmx-scandir/src/com/sun/jmx/examples/scandir/config/XmlConfigUtils.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/DirectoryScannerTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanDirConfigTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/ScanManagerTest.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/TestUtils.java ! src/share/sample/jmx/jmx-scandir/test/com/sun/jmx/examples/scandir/config/XmlConfigUtilsTest.java ! src/share/sample/nio/multicast/MulticastAddress.java ! src/share/sample/nio/multicast/Reader.java ! src/share/sample/nio/multicast/Sender.java ! src/share/sample/nio/server/AcceptHandler.java ! src/share/sample/nio/server/Acceptor.java ! src/share/sample/nio/server/B1.java ! src/share/sample/nio/server/BN.java ! src/share/sample/nio/server/BP.java ! src/share/sample/nio/server/ChannelIO.java ! src/share/sample/nio/server/ChannelIOSecure.java ! src/share/sample/nio/server/Content.java ! src/share/sample/nio/server/Dispatcher.java ! src/share/sample/nio/server/Dispatcher1.java ! src/share/sample/nio/server/DispatcherN.java ! src/share/sample/nio/server/FileContent.java ! src/share/sample/nio/server/Handler.java ! src/share/sample/nio/server/MalformedRequestException.java ! src/share/sample/nio/server/N1.java ! src/share/sample/nio/server/N2.java ! src/share/sample/nio/server/Reply.java ! src/share/sample/nio/server/Request.java ! src/share/sample/nio/server/RequestHandler.java ! src/share/sample/nio/server/RequestServicer.java ! src/share/sample/nio/server/Sendable.java ! src/share/sample/nio/server/Server.java ! src/share/sample/nio/server/StringContent.java ! src/share/sample/nio/server/URLDumper.java ! src/share/sample/scripting/scriptpad/src/com/sun/sample/scriptpad/Main.java ! src/share/sample/scripting/scriptpad/src/resources/Main.js ! src/share/sample/scripting/scriptpad/src/resources/conc.js ! src/share/sample/scripting/scriptpad/src/resources/gui.js ! src/share/sample/scripting/scriptpad/src/resources/mm.js ! src/share/sample/scripting/scriptpad/src/resources/scriptpad.js ! src/share/sample/scripting/scriptpad/src/scripts/browse.js ! src/share/sample/scripting/scriptpad/src/scripts/insertfile.js ! src/share/sample/scripting/scriptpad/src/scripts/linewrap.js ! src/share/sample/scripting/scriptpad/src/scripts/mail.js ! src/share/sample/scripting/scriptpad/src/scripts/memmonitor.js ! src/share/sample/scripting/scriptpad/src/scripts/memory.js ! src/share/sample/scripting/scriptpad/src/scripts/textcolor.js ! src/share/sample/vm/clr-jvm/invoked.java ! src/share/sample/vm/clr-jvm/jinvoker.cpp ! src/share/sample/vm/clr-jvm/jinvokerExp.h ! src/share/sample/vm/jvm-clr/invoker.cpp ! src/share/sample/vm/jvm-clr/invoker.h ! src/share/sample/vm/jvm-clr/invoker.java ! src/share/sample/vm/jvm-clr/invokerExp.h ! src/share/transport/shmem/shmemBase.h ! src/share/transport/socket/socketTransport.c ! src/solaris/back/exec_md.c ! src/solaris/back/linker_md.c ! src/solaris/back/util_md.h ! src/solaris/bin/arm/jvm.cfg ! src/solaris/bin/i586/jvm.cfg ! src/solaris/bin/ppc/jvm.cfg ! src/solaris/bin/sparc/jvm.cfg ! src/solaris/classes/com/sun/management/UnixOperatingSystem.java ! src/solaris/classes/java/lang/ProcessEnvironment.java ! src/solaris/classes/java/lang/Terminator.java ! src/solaris/classes/java/net/DefaultInterface.java ! src/solaris/classes/sun/management/FileSystemImpl.java ! src/solaris/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/solaris/classes/sun/nio/ch/DefaultSelectorProvider.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorProvider.java ! src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java ! src/solaris/classes/sun/nio/ch/NativeThread.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/sctp/AssociationChange.java ! src/solaris/classes/sun/nio/ch/sctp/AssociationImpl.java ! src/solaris/classes/sun/nio/ch/sctp/PeerAddrChange.java ! src/solaris/classes/sun/nio/ch/sctp/ResultContainer.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpNet.java ! src/solaris/classes/sun/nio/ch/sctp/SctpNotification.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SendFailed.java ! src/solaris/classes/sun/nio/ch/sctp/Shutdown.java ! src/solaris/classes/sun/nio/fs/BsdFileStore.java ! src/solaris/classes/sun/nio/fs/BsdFileSystem.java ! src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/DefaultFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/MacOSXFileSystem.java ! src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/MacOSXNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/security/smartcardio/PlatformPCSC.java ! src/solaris/classes/sun/tools/attach/BsdAttachProvider.java ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java ! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java ! src/solaris/demo/jni/Poller/Client.java ! src/solaris/demo/jni/Poller/LinkedQueue.java ! src/solaris/demo/jni/Poller/Poller.c ! src/solaris/demo/jni/Poller/Poller.java ! src/solaris/demo/jni/Poller/PollingServer.java ! src/solaris/demo/jni/Poller/SimpleServer.java ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/solaris/doc/sun/man/man1/jcmd.1 ! src/solaris/instrument/EncodingSupport_md.c ! src/solaris/javavm/export/jvm_md.h ! src/solaris/native/com/sun/management/MacosxOperatingSystem.c ! src/solaris/native/com/sun/management/UnixOperatingSystem_md.c ! src/solaris/native/com/sun/security/auth/module/Unix.c ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/canonicalize_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h ! src/solaris/native/java/lang/ProcessEnvironment_md.c ! src/solaris/native/java/lang/java_props_macosx.c ! src/solaris/native/java/lang/java_props_macosx.h ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c ! src/solaris/native/java/net/SocketInputStream.c ! src/solaris/native/java/net/bsd_close.c ! src/solaris/native/java/net/net_util_md.h ! src/solaris/native/java/util/FileSystemPreferences.c ! src/solaris/native/sun/jdga/dgalock.c ! src/solaris/native/sun/management/FileSystemImpl.c ! src/solaris/native/sun/net/dns/ResolverConfigurationImpl.c ! src/solaris/native/sun/net/spi/DefaultProxySelector.c ! src/solaris/native/sun/nio/ch/DatagramChannelImpl.c ! src/solaris/native/sun/nio/ch/DatagramDispatcher.c ! src/solaris/native/sun/nio/ch/DevPollArrayWrapper.c ! src/solaris/native/sun/nio/ch/EPoll.c ! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c ! src/solaris/native/sun/nio/ch/FileChannelImpl.c ! src/solaris/native/sun/nio/ch/FileDispatcherImpl.c ! src/solaris/native/sun/nio/ch/FileKey.c ! src/solaris/native/sun/nio/ch/IOUtil.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/ch/SolarisEventPort.c ! src/solaris/native/sun/nio/ch/sctp/Sctp.h ! src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c ! src/solaris/native/sun/nio/ch/sctp/SctpNet.c ! src/solaris/native/sun/nio/ch/sctp/SctpServerChannelImpl.c ! src/solaris/native/sun/nio/fs/BsdNativeDispatcher.c ! src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c ! src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c ! src/solaris/native/sun/nio/fs/LinuxWatchService.c ! src/solaris/native/sun/nio/fs/MacOSXNativeDispatcher.c ! src/solaris/native/sun/nio/fs/SolarisNativeDispatcher.c ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c ! src/solaris/native/sun/nio/fs/genSolarisConstants.c ! src/solaris/native/sun/nio/fs/genUnixConstants.c ! src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c ! src/solaris/native/sun/security/smartcardio/pcsc_md.c ! src/solaris/npt/npt_md.h ! src/solaris/transport/socket/socket_md.c ! src/windows/classes/com/sun/management/OperatingSystem.java ! src/windows/classes/java/lang/ProcessEnvironment.java ! src/windows/classes/java/lang/Terminator.java ! src/windows/classes/java/net/DefaultInterface.java ! src/windows/classes/java/net/TwoStacksPlainSocketImpl.java ! src/windows/classes/sun/management/FileSystemImpl.java ! src/windows/classes/sun/net/dns/ResolverConfigurationImpl.java ! src/windows/classes/sun/nio/ch/NativeThread.java ! src/windows/classes/sun/nio/ch/SocketDispatcher.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/windows/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/windows/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/print/Win32PrintServiceLookup.java ! src/windows/classes/sun/security/krb5/internal/tools/Kinit.java ! src/windows/classes/sun/security/krb5/internal/tools/KinitOptions.java ! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java ! src/windows/classes/sun/security/smartcardio/PlatformPCSC.java ! src/windows/classes/sun/tools/attach/WindowsAttachProvider.java ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/io_util_md.h ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/NetworkInterface.c ! src/windows/native/java/net/NetworkInterface.h ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/java/net/net_util_md.c ! src/windows/native/java/net/net_util_md.h ! src/windows/native/sun/management/FileSystemImpl.c ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/IOUtil.c ! src/windows/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c ! src/windows/native/sun/nio/ch/nio_util.h ! src/windows/native/sun/security/krb5/NativeCreds.c ! src/windows/native/sun/security/pkcs11/j2secmod_md.c ! src/windows/native/sun/security/provider/WinCAPISeedGenerator.c ! src/windows/native/sun/tools/attach/WindowsAttachProvider.c ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c ! src/windows/native/sun/tracing/dtrace/jvm_symbols_md.c ! src/windows/npt/npt_md.h ! src/windows/transport/shmem/shmem_md.c ! test/com/sun/crypto/provider/Cipher/DES/PaddingTest.java ! test/com/sun/crypto/provider/KeyGenerator/Test4628062.java ! test/com/sun/jdi/ConnectedVMs.java ! test/com/sun/jdi/EarlyReturnTest.java ! test/com/sun/jdi/ImmutableResourceTest.sh ! test/com/sun/jdi/JITDebug.sh ! test/com/sun/jdi/MethodEntryExitEvents.java ! test/com/sun/jdi/MethodExitReturnValuesTest.java ! test/com/sun/jdi/PrivateTransportTest.sh ! test/com/sun/jdi/ShellScaffold.sh ! test/com/sun/jdi/Solaris32AndSolaris64Test.sh ! test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh ! test/com/sun/jndi/ldap/LdapTimeoutTest.java ! test/com/sun/management/OperatingSystemMXBean/TestTotalSwap.sh ! test/com/sun/net/httpserver/Test1.java ! test/com/sun/net/httpserver/Test10.java ! test/com/sun/net/httpserver/bugs/B6373555.java ! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java ! test/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java ! test/com/sun/security/auth/login/ConfigFile/IllegalURL.java ! test/com/sun/servicetag/JavaServiceTagTest.java ! test/com/sun/servicetag/JavaServiceTagTest1.java ! test/com/sun/tools/attach/CommonSetup.sh ! test/demo/zipfs/basic.sh ! test/java/io/File/MaxPathLength.java ! test/java/io/File/basic.sh ! test/java/io/FileInputStream/LargeFileAvailable.java ! test/java/io/IOException/LastErrorString.java ! test/java/io/Serializable/badSubstByReplace/BadSubstByReplace.java ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/expectedStackTrace/ExpectedStackTrace.java ! test/java/io/Serializable/replaceStringArray/ReplaceStringArray.java ! test/java/io/Serializable/replaceWithNull/ReplaceWithNull.java ! test/java/io/Serializable/serialver/classpath/run.sh ! test/java/io/Serializable/serialver/nested/run.sh ! test/java/io/Serializable/verifyDynamicObjHandleTable/VerifyDynamicObjHandleTable.java ! test/java/lang/Character/CheckProp.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/Double/ToHexString.java ! test/java/lang/Runtime/exec/StreamsSurviveDestroy.java ! test/java/lang/StringCoding/CheckEncodings.sh ! test/java/lang/ThreadGroup/NullThreadName.java ! test/java/lang/ThreadGroup/Stop.java ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/annotation/loaderLeak/Main.java ! test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/PrivateInvokeTest.java ! test/java/lang/invoke/RicochetTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java ! test/java/lang/management/BufferPoolMXBean/Basic.java ! test/java/lang/management/ManagementFactory/GetPlatformMXBeans.java ! test/java/lang/management/ManagementFactory/MBeanServerMXBeanUnsupportedTest.java ! test/java/lang/management/ManagementFactory/ThreadMXBeanProxy.java ! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java ! test/java/lang/management/MemoryMXBean/MemoryTest.java ! test/java/lang/management/OperatingSystemMXBean/TestSystemLoadAvg.sh ! test/java/lang/management/PlatformLoggingMXBean/PlatformLoggingMXBeanTest.java ! test/java/lang/ref/Basic.java ! test/java/net/Authenticator/B4678055.java ! test/java/net/Authenticator/B4722333.java ! test/java/net/Authenticator/B4759514.java ! test/java/net/Authenticator/B4769350.java ! test/java/net/Authenticator/B4921848.java ! test/java/net/Authenticator/B4933582.java ! test/java/net/Authenticator/B4933582.sh ! test/java/net/Authenticator/B4962064.java ! test/java/net/CookieHandler/CookieManagerTest.java ! test/java/net/CookieHandler/NullUriCookieTest.java ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/DatagramPacket/ReuseBuf.java ! test/java/net/DatagramSocket/Send12k.java ! test/java/net/DatagramSocket/SendDatagramToBadAddress.java ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/net/InetAddress/GetLocalHostWithSM.java ! test/java/net/NetworkInterface/NetParamsTest.java ! test/java/net/ProxySelector/LoopbackAddresses.java ! test/java/net/ProxySelector/ProxyTest.java ! test/java/net/Socket/OldSocketImpl.sh ! test/java/net/Socket/setReuseAddress/Basic.java ! test/java/net/Socket/setReuseAddress/Restart.java ! test/java/net/Socks/SocksServer.java ! test/java/net/Socks/SocksV4Test.java ! test/java/net/URL/B5086147.sh ! test/java/net/URL/OpenStream.java ! test/java/net/URL/PerConnectionProxy.java ! test/java/net/URL/Test.java ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/closetest/CloseTest.java ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/net/URLConnection/B5052093.java ! test/java/net/URLConnection/Redirect307Test.java ! test/java/nio/Buffer/Basic-X.java.template ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java ! test/java/nio/MappedByteBuffer/Truncate.java ! test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/Restart.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/DatagramChannel/BasicMulticastTests.java ! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java ! test/java/nio/channels/DatagramChannel/NetworkConfiguration.java ! test/java/nio/channels/DatagramChannel/Refused.java ! test/java/nio/channels/DatagramChannel/SelectWhenRefused.java ! test/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/java/nio/channels/FileChannel/ClosedByInterrupt.java ! test/java/nio/channels/Selector/OpRead.java ! test/java/nio/channels/Selector/lots_of_updates.sh ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java ! test/java/nio/channels/SocketChannel/Open.sh ! test/java/nio/channels/SocketChannel/Shutdown.java ! test/java/nio/channels/SocketChannel/SocketOptionTests.java ! test/java/nio/channels/TestUtil.java ! test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java ! test/java/nio/charset/coders/CheckSJISMappingProp.sh ! test/java/nio/charset/coders/Errors.java ! test/java/nio/charset/spi/basic.sh ! test/java/nio/file/Files/CustomOptions.java ! test/java/nio/file/Path/PathOps.java ! test/java/nio/file/WatchService/Basic.java ! test/java/nio/file/WatchService/SensitivityModifier.java ! test/java/nio/file/WatchService/WithSecurityManager.java ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/transport/pinLastArguments/PinLastArguments.java ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/text/Bidi/Bug6850113.java ! test/java/util/Collection/BiggernYours.java ! test/java/util/Collections/EmptyIterator.java ! test/java/util/Currency/CurrencyTest.java ! test/java/util/Hashtable/HashCode.java ! test/java/util/Hashtable/SimpleSerialization.java ! test/java/util/Locale/Bug6989440.java ! test/java/util/Locale/LocaleCategory.sh ! test/java/util/Map/Get.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/PluggableLocale/LocaleNameProviderTest.sh ! test/java/util/PluggableLocale/ProviderTest.java ! test/java/util/PluggableLocale/providersrc/DateFormatSymbolsProviderImpl.java ! test/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java ! test/java/util/ResourceBundle/Bug4168625Test.java ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/Control/Bug6530694.java ! test/java/util/ServiceLoader/basic.sh ! test/java/util/Timer/Args.java ! test/java/util/Timer/KillThread.java ! test/java/util/UUID/UUIDTest.java ! test/java/util/concurrent/FutureTask/BlockingTaskExecutor.java ! test/java/util/concurrent/ThreadPoolExecutor/Custom.java ! test/java/util/concurrent/locks/Lock/FlakyMutex.java ! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java ! test/java/util/logging/LoggingDeadlock4.java ! test/java/util/regex/RegExTest.java ! test/java/util/zip/ZipFile/ManyZipFiles.java ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh ! test/javax/management/remote/mandatory/URLTest.java ! test/javax/management/remote/mandatory/notif/ListenerScaleTest.java ! test/javax/naming/spi/DirectoryManager/GetContDirCtx.java ! test/javax/script/CommonSetup.sh ! test/javax/security/auth/Subject/Synch.java ! test/javax/security/auth/Subject/Synch2.java ! test/javax/security/auth/Subject/Synch3.java ! test/javax/security/auth/Subject/doAs/Test.sh ! test/javax/security/auth/login/LoginContext/ResetConfigModule.java ! test/javax/xml/crypto/dsig/SecurityManager/XMLDSigWithSecMgr.java ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/invoke/util/ValueConversionsTest.java ! test/sun/misc/Cleaner/exitOnThrow.sh ! test/sun/misc/Version/Version.java ! test/sun/net/www/AuthHeaderTest.java ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/http/KeepAliveCache/B5045306.java ! test/sun/net/www/httptest/HttpTransaction.java ! test/sun/net/www/httptest/TestHttpServer.java ! test/sun/net/www/protocol/file/DirPermissionDenied.sh ! test/sun/net/www/protocol/http/B6296310.java ! test/sun/net/www/protocol/http/B6299712.java ! test/sun/net/www/protocol/http/RelativeRedirect.java ! test/sun/net/www/protocol/http/ResponseCacheStream.java ! test/sun/net/www/protocol/http/SetChunkedStreamingMode.java ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/nio/cs/OLD/DoubleByteDecoder.java ! test/sun/nio/cs/OLD/DoubleByteEncoder.java ! test/sun/nio/cs/OLD/EUC_JP_LINUX_OLD.java ! test/sun/nio/cs/OLD/EUC_JP_OLD.java ! test/sun/nio/cs/OLD/EUC_JP_Open_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0201_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0208_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0208_Encoder.java ! test/sun/nio/cs/OLD/JIS_X_0208_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0208_Solaris_Encoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_Encoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_OLD.java ! test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Decoder.java ! test/sun/nio/cs/OLD/JIS_X_0212_Solaris_Encoder.java ! test/sun/nio/cs/OLD/MS932_OLD.java ! test/sun/nio/cs/OLD/PCK_OLD.java ! test/sun/nio/cs/OLD/SJIS_OLD.java ! test/sun/nio/cs/OLD/SingleByteDecoder.java ! test/sun/nio/cs/OLD/SingleByteEncoder.java ! test/sun/nio/cs/OLD/TestIBMDB.java ! test/sun/nio/cs/StrCodingBenchmark.java ! test/sun/nio/cs/StrCodingBenchmarkDB.java ! test/sun/nio/cs/TestCp834_SBCS.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/TestUTF8.java ! test/sun/nio/cs/TestX11JIS0201.java ! test/sun/security/krb5/ConfPlusProp.java ! test/sun/security/krb5/DnsFallback.java ! test/sun/security/krb5/Krb5NameEquals.java ! test/sun/security/krb5/ParseConfig.java ! test/sun/security/krb5/auto/BadKdc.java ! test/sun/security/krb5/auto/BadKdc1.java ! test/sun/security/krb5/auto/BadKdc2.java ! test/sun/security/krb5/auto/BadKdc3.java ! test/sun/security/krb5/auto/BadKdc4.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/MaxRetries.java ! test/sun/security/krb5/auto/OneKDC.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/auto/TcpTimeout.java ! test/sun/security/krb5/auto/W83.java ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/pkcs11/Secmod/AddPrivateKey.java ! test/sun/security/pkcs11/Secmod/AddTrustedCert.java ! test/sun/security/pkcs11/Secmod/Crypto.java ! test/sun/security/pkcs11/Secmod/GetPrivateKey.java ! test/sun/security/pkcs11/Secmod/JksSetPrivateKey.java ! test/sun/security/pkcs11/Secmod/TrustAnchors.java ! test/sun/security/pkcs11/SecmodTest.java ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/ec/ReadPKCS12.java ! test/sun/security/pkcs11/ec/TestECDH.java ! test/sun/security/pkcs11/ec/TestECDSA.java ! test/sun/security/pkcs11/fips/TrustManagerTest.java ! test/sun/security/pkcs11/rsa/TestCACerts.java ! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java ! test/sun/security/pkcs12/PKCS12SameKeyId.java ! test/sun/security/provider/DSA/TestKeyPairGenerator.java ! test/sun/security/provider/PolicyFile/Comparator.java ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/provider/X509Factory/BigCRL.java ! test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadBlocksClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadHandshake.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/RemoveMarkReset.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppOutputStream/NoExceptionOnClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/CipherSuiteOrder.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/GenSSLConfigs/main.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/HandshakeOutStream/NullCerts.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/InputRecord/SSLSocketTimeoutNulls.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadKSProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/BadTSProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/GoodProvider.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/RehandshakeFinished.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/SSLEngineDeadlock.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSessionImpl/HashCodeMissing.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientTimeout.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/CloseSocketException.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NewSocketMethods.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NonAutoClose.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReuseAddr.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ReverseNameLookup.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SSLSocketImplThrowsWrongExceptions.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ServerTimeout.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/SetClientMode.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/UnconnectedSocketWrongExceptions.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/AnonCipherWithWantClientAuth.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SocketCreation/SocketCreation.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/ClientServer.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/PKIXExtendedTM.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SelfIssuedCert.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/SunX509ExtendedTM.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/X509ExtendedTMEnabled.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/spi/ProviderInit.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/CriticalSubjectAltName.java ! test/sun/security/ssl/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnection/GetResponseCode.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/ImplicitHandshake.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSessionNulls.java ! test/sun/security/ssl/javax/net/ssl/FixingJavadocs/SSLSocketInherit.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/HttpsURLConnectionLocalCertificateChain.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLCtxAccessToSessCtx.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/AcceptLargeFragments.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ExtendedKeySocket.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngineResult/Deserialize.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/EmptyCertificateAuthorities.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableBlockCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/ExportableStreamCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericBlockCipher.java ! test/sun/security/ssl/javax/net/ssl/TLSv11/GenericStreamCipher.java ! test/sun/security/ssl/sanity/pluggability/CheckSSLContextExport.java ! test/sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java ! test/sun/security/ssl/sun/net/www/httpstest/HttpTransaction.java ! test/sun/security/ssl/sun/net/www/httpstest/TestHttpsServer.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java ! test/sun/security/ssl/sun/net/www/protocol/https/NewImpl/JavaxHostnameVerifier.java ! test/sun/security/ssl/templates/SSLEngineTemplate.java ! test/sun/security/ssl/templates/SSLSocketTemplate.java ! test/sun/security/tools/jarsigner/AlgOptions.sh ! test/sun/security/tools/jarsigner/JarSigningNonAscii.java ! test/sun/security/tools/jarsigner/LargeJarEntry.java ! test/sun/security/tools/jarsigner/PercentSign.sh ! test/sun/security/tools/jarsigner/concise_jarsigner.sh ! test/sun/security/tools/jarsigner/diffend.sh ! test/sun/security/tools/jarsigner/oldsig.sh ! test/sun/security/tools/keytool/AltProviderPath.sh ! test/sun/security/tools/keytool/CloneKeyAskPassword.sh ! test/sun/security/tools/keytool/NoExtNPE.sh ! test/sun/security/tools/keytool/SecretKeyKS.sh ! test/sun/security/tools/keytool/StandardAlgName.sh ! test/sun/security/tools/keytool/i18n.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/resource.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/tools/policytool/Alias.sh ! test/sun/security/tools/policytool/ChangeUI.sh ! test/sun/security/tools/policytool/OpenPolicy.sh ! test/sun/security/tools/policytool/SaveAs.sh ! test/sun/security/tools/policytool/UpdatePermissions.sh ! test/sun/security/tools/policytool/UsePolicy.sh ! test/sun/security/tools/policytool/i18n.sh ! test/sun/security/util/Oid/S11N.sh ! test/sun/security/util/Resources/NewNamesFormat.java ! test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java ! test/sun/tools/common/CommonSetup.sh ! test/sun/tools/jcmd/jcmd-Defaults.sh ! test/sun/tools/jcmd/jcmd-f.sh ! test/sun/tools/jcmd/jcmd-help-help.sh ! test/sun/tools/jcmd/jcmd-help.sh ! test/sun/tools/jcmd/jcmd-pid.sh ! test/sun/tools/jconsole/ImmutableResourceTest.sh ! test/sun/tools/jinfo/Basic.sh ! test/sun/tools/jrunscript/common.sh ! test/sun/tools/jrunscript/jrunscript-argsTest.sh ! test/sun/tools/jrunscript/jrunscript-eTest.sh ! test/sun/tools/jrunscript/jrunscript-fTest.sh ! test/sun/tools/jrunscript/jrunscriptTest.sh ! test/sun/tools/native2ascii/resources/ImmutableResourceTest.sh ! test/sun/util/logging/PlatformLoggerTest.java ! test/tools/launcher/DefaultLocaleTest.java ! test/tools/pack200/CommandLineTests.java ! test/tools/pack200/TimeStamp.java Changeset: 6ffd64541a6c Author: lana Date: 2012-11-02 17:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6ffd64541a6c Merge - make/sun/jdbc/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcSwing.gmk ! makefiles/mapfiles/libnio/mapfile-linux ! makefiles/mapfiles/libnio/mapfile-macosx ! makefiles/mapfiles/libnio/mapfile-solaris - src/solaris/native/java/io/FileSystem_md.c - src/windows/native/java/io/FileSystem_md.c ! test/javax/imageio/stream/StreamCloserLeak/run_test.sh Changeset: 63726e5b90da Author: erikj Date: 2012-11-03 16:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/63726e5b90da 8002220: build-infra: update for mac, solaris 11 issues 8002184: Fixed exclude and includes for jarsigner in new build Reviewed-by: ohair ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcJObjC.gmk Changeset: 26dbd73fb766 Author: katleman Date: 2012-11-07 15:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/26dbd73fb766 Merge ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk Changeset: ad5c1d6b1e16 Author: katleman Date: 2012-11-08 11:52 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ad5c1d6b1e16 Added tag jdk8-b64 for changeset 26dbd73fb766 ! .hgtags From vladimir.kozlov at oracle.com Fri Nov 9 09:35:31 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Nov 2012 09:35:31 -0800 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <509C5460.4050608@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> Message-ID: <509D3EE3.303@oracle.com> Bharadwaj, Nils just reminded me (for his changes) that you need to fix our LogCompilation parsing tool to recognize new "unique='n' live_tracked='n'" values (old was "nodes='n'"): src/share/tools/LogCompilation/ Also live_tracked could be simple "live". Thanks, Vladimir Vladimir Kozlov wrote: > VerifyIdealNodeCount flag should be also notproduct since it is used > only in debug VM. > > The next assert is not needed because it duplicates assert in live_nodes(): > > bool check_node_count(uint margin, const char* reason) { > if (unique() + margin > (uint)MaxNodeLimit) { > + assert(dead_node_count() <= unique(), "number of dead nodes more > than created"); > > Also don't split the assert in live_nodes() into 2 lines and maybe use > err_msg_res() to print _unique and _dead_node_count values. Also I think > it should return unsigned int type value as unique() method. > > Second Compile() constructor does not set _dead_node_count(0). > > count_live_nodes_by_graph_walk() and NotANode() methods are now used > only in debug code so put them under #ifdef ASSERT. > > > print_missing_nodes() should call count_live_nodes_by_graph_walk() > instead of duplicating code. And it should print to _log itself. > TracePhase() code will have only call to it: > > 3133 if (VerifyIdealNodeCount) { > 3134 Compile::current()->print_missing_nodes(); > 3135 } > > And do not check VerifyIdealNodeCount in print_missing_nodes() to allow > call it in debugger without VerifyIdealNodeCount set. > > I think VerifyIdealNodeCount code should be in ~TracePhase() (end of > phase). > > Thanks, > Vladimir > > Bharadwaj Yadavalli wrote: >> Addressed comments on my previous RFR. Changes at >> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_02/ >> >> These changes are made to keep an (almost) accurate running count of >> the reachable (live) flow graph nodes. This will result in a more >> realistic node count for various phases of C2 to decide on whether to >> proceed with optimizations or not. Prior to these changes, C2 bails >> out of compilation based on the number of nodes created which >> typically larger than the number of reachable (live) nodes. >> From vladimir.kozlov at oracle.com Fri Nov 9 09:43:22 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Nov 2012 09:43:22 -0800 Subject: Review Request (S): 8002364 - compile_id is not unique when CICountOSR is set In-Reply-To: <509CFE81.5080105@oracle.com> References: <509BCC8E.600@oracle.com> <7A5782BB-F2B6-47C4-8622-FAA2836D8677@oracle.com> <061ABEB6-981A-4ADF-9A22-D09B200B0BF7@oracle.com> <509CFE81.5080105@oracle.com> Message-ID: <509D40BA.50801@oracle.com> Nils, Thank you for reminding me. Yes, if you add new field (osr_id) into LogCompilation output, you need to change our logcompilation parser tool: src/share/tools/LogCompilation/ But it should be small change. Thanks, Vladimir Nils Eliasson wrote: > Vladimir Kozlov skrev 2012-11-08 19:02: >> It is not true. Vladimir I. changed the flag default value to false in >> recent changes for 7177003. >> Also in our developing environment we will not use JFR but we want a >> functionality which help us debug problems. So I would like to keep >> the flag and have a separate number in output (tty and LogCompilation >> log) for osr_id if the flag is on. So I agree with your general >> changes but you need to add more code. > > True, that change hadn't propagated to the branch where I originally did > the work. > > Yes, and thats exactly why I kept the functionality by extracting it to > a separate id and took great care to keep its behavior. > >> After thinking about this more, maybe we should always print osr_id as >> an additional number then we don't need CICountOSR flag. In this case >> you only need to add code to print this number in PrintCompilation and >> LogCompilation. >> >> Vladimir >> > Is there any parser or tool that will break if I add the osr_id as an > additional number? > > //N > From alejandro.murillo at oracle.com Fri Nov 9 18:02:37 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Sat, 10 Nov 2012 02:02:37 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 15 new changesets Message-ID: <20121110020305.78A68478BE@hg.openjdk.java.net> Changeset: 49bc14aaadcc Author: katleman Date: 2012-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/49bc14aaadcc Added tag jdk8-b64 for changeset 5920f72e799c ! .hgtags Changeset: 857f3ce858dd Author: dholmes Date: 2012-11-05 19:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/857f3ce858dd 8002034: Allow Full Debug Symbols when cross-compiling 8001756: Hotspot makefiles report missing OBJCOPY command in the wrong circumstances Reviewed-by: dcubed, dsamersoff, erikj, collins ! make/linux/makefiles/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make Changeset: 3d701c802d01 Author: minqi Date: 2012-11-02 13:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3d701c802d01 8000489: older builds of hsdis don't work anymore after 6879063 Summary: The old function not defined properly, need a definition for export in dll. Also changes made to let new jvm work with old hsdis. Reviewed-by: jrose, sspitsyn, kmo Contributed-by: yumin.qi at oracle.com ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c ! src/share/tools/hsdis/hsdis.h ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp Changeset: 4735d2c84362 Author: kamg Date: 2012-10-11 12:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4735d2c84362 7200776: Implement default methods in interfaces Summary: Add generic type analysis and default method selection algorithms Reviewed-by: coleenp, acorn + src/share/vm/classfile/bytecodeAssembler.cpp + src/share/vm/classfile/bytecodeAssembler.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp + src/share/vm/classfile/defaultMethods.cpp + src/share/vm/classfile/defaultMethods.hpp + src/share/vm/classfile/genericSignatures.cpp + src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/utilities/growableArray.hpp + src/share/vm/utilities/pair.hpp + src/share/vm/utilities/resourceHash.hpp Changeset: ec204374e626 Author: kamg Date: 2012-11-02 16:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ec204374e626 Merge ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/globals.hpp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: 9cc901118f6b Author: kamg Date: 2012-11-02 17:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/9cc901118f6b Merge Changeset: 69ad7823b1ca Author: zgu Date: 2012-11-05 15:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/69ad7823b1ca 8001591: NMT: assertion failed: assert(rec->addr() + rec->size() <= cur->base()) failed: Can not overlap in memSnapshot.cpp Summary: NMT should allow overlapping committed regions as long as they belong to the same reserved region Reviewed-by: dholmes, coleenp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.cpp Changeset: 8940ddc1036f Author: zgu Date: 2012-11-05 13:55 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8940ddc1036f Merge - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: c284cf4781f0 Author: rbackman Date: 2012-10-04 14:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c284cf4781f0 7127792: Add the ability to change an existing PeriodicTask's execution interval Summary: Enables dynamic enrollment / disenrollment from the PeriodicTasks in WatcherThread. Reviewed-by: dholmes, mgronlun ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 18fb7da42534 Author: coleenp Date: 2012-11-06 15:09 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/18fb7da42534 8000725: NPG: method_holder() and pool_holder() and pool_holder field should be InstanceKlass Summary: Change types of above methods and field to InstanceKlass and remove unneeded casts from the source files. Reviewed-by: dholmes, coleenp, zgu Contributed-by: harold.seigel at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp Changeset: ead8852dd4ef Author: coleenp Date: 2012-11-07 16:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ead8852dd4ef Merge Changeset: a4e1bd941ded Author: neliasso Date: 2012-11-08 22:39 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/a4e1bd941ded Merge ! src/share/vm/oops/cpCache.cpp Changeset: b4ee7b773144 Author: amurillo Date: 2012-11-09 08:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b4ee7b773144 Merge Changeset: 0f7290a03b24 Author: amurillo Date: 2012-11-09 08:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0f7290a03b24 Added tag hs25-b09 for changeset b4ee7b773144 ! .hgtags Changeset: 3be318ecfae5 Author: amurillo Date: 2012-11-09 08:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/3be318ecfae5 8003231: new hotspot build - hs25-b10 Reviewed-by: jcoomes ! make/hotspot_version From bharadwaj.yadavalli at oracle.com Mon Nov 12 08:59:20 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Mon, 12 Nov 2012 11:59:20 -0500 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <509C5460.4050608@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> Message-ID: <50A12AE8.8000500@oracle.com> Thanks for the review, Vladimir. On 11/8/2012 7:54 PM, Vladimir Kozlov wrote: > I think VerifyIdealNodeCount code should be in ~TracePhase() (end of > phase). > I am wondering if PrintIdealNodeCount and VerifyIdealNodeCount should be both in the constructor and destructor of TracePhase. This will allow us to track the node counts both at the entry of the phase (when the constructor is executed) and at the exit of the phase (when the destructor is executed). What do you think? Bharadwaj From Vladimir.Kozlov at oracle.com Mon Nov 12 11:15:06 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Nov 2012 11:15:06 -0800 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50A12AE8.8000500@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> <50A12AE8.8000500@oracle.com> Message-ID: <50A14ABA.2010402@oracle.com> Usually the beginning of next phase comes after the end of previous phase so you will have almost duplicated verification and expensive. I would prefer to have both PrintIdealNodeCount and VerifyIdealNodeCount at the end to show how the phase affected nodes count. The only reason I suggested to move only VerifyIdealNodeCount is that TracePhase does not have phase's name which I think is easy to fix and it will be nice to print also. Thanks, Vladimir On 11/12/12 08:59, Bharadwaj Yadavalli wrote: > Thanks for the review, Vladimir. > > On 11/8/2012 7:54 PM, Vladimir Kozlov wrote: >> I think VerifyIdealNodeCount code should be in ~TracePhase() (end of >> phase). >> > > I am wondering if PrintIdealNodeCount and VerifyIdealNodeCount should be > both in the constructor and destructor of TracePhase. > > This will allow us to track the node counts both at the entry of the > phase (when the constructor is executed) and at the exit of the phase > (when the destructor is executed). > > What do you think? > > Bharadwaj > From vladimir.x.ivanov at oracle.com Tue Nov 13 07:53:22 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 13 Nov 2012 18:53:22 +0300 Subject: RFR (S) 8001538: hs_err file does not list anymore compiled methods in compilation events Message-ID: <50A26CF2.10505@oracle.com> http://cr.openjdk.java.net/~vlivanov/8001538/webrev.00/ Due to incorrect message buffer size calculation, a message may be truncated to 4/8 characters. Also, changed how deoptimization events are logged: - moved [1] from "Deoptimization events" to "Events" section. - added [2] to "Deoptimization events" section Sample output from a hs_err file: Deoptimization events (2 events): Event: 3.438 Thread 0x0000000103804800 Uncommon trap: Test::f @ 23, reason: unloaded, action: reinterpret Event: 3.482 Thread 0x0000000103804800 Uncommon trap: Test::main @ 38, reason: unloaded, action: reinterpret Internal exceptions (10 events): ... Events (10 events): Event: 3.441 Thread 0x0000000103804800 DEOPT UNPACKING pc=0x00000001046cf214 sp=0x0000000100700548 mode 2 Event: 3.482 Thread 0x0000000103804800 Uncommon trap 3 fr.pc 0x00000001046ffe1c ... Testing: JPRT, simple test w/ deopt events in the log. Best regards, Vladimir Ivanov [1] Uncommon trap 3 fr.pc 0x00000001046ffe1c [2] Uncommon trap: Test::f @ 23, reason=unloaded action=reinterpret From vladimir.kozlov at oracle.com Tue Nov 13 08:41:55 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Nov 2012 08:41:55 -0800 Subject: RFR (S) 8001538: hs_err file does not list anymore compiled methods in compilation events In-Reply-To: <50A26CF2.10505@oracle.com> References: <50A26CF2.10505@oracle.com> Message-ID: <3F7665E3-3C59-475E-837D-242213CE7619@oracle.com> Very nice fix, Vladimir I., thank you To confirm, the size fix restored methods names in compilation events. Right? You moved deoptimization event logging under resourceMark, make sure the logging code does not use resource area or copied from it to safe place. Thanks, Vladimir On Nov 13, 2012, at 7:53 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8001538/webrev.00/ > > Due to incorrect message buffer size calculation, a message may be truncated to 4/8 characters. > > Also, changed how deoptimization events are logged: > - moved [1] from "Deoptimization events" to "Events" section. > - added [2] to "Deoptimization events" section > > Sample output from a hs_err file: > Deoptimization events (2 events): > Event: 3.438 Thread 0x0000000103804800 Uncommon trap: Test::f @ 23, reason: unloaded, action: reinterpret > Event: 3.482 Thread 0x0000000103804800 Uncommon trap: Test::main @ 38, reason: unloaded, action: reinterpret > > Internal exceptions (10 events): > ... > > Events (10 events): > Event: 3.441 Thread 0x0000000103804800 DEOPT UNPACKING pc=0x00000001046cf214 sp=0x0000000100700548 mode 2 > Event: 3.482 Thread 0x0000000103804800 Uncommon trap 3 fr.pc 0x00000001046ffe1c > ... > > Testing: JPRT, simple test w/ deopt events in the log. > > Best regards, > Vladimir Ivanov > > [1] Uncommon trap 3 fr.pc 0x00000001046ffe1c > [2] Uncommon trap: Test::f @ 23, reason=unloaded action=reinterpret From yumin.qi at oracle.com Tue Nov 13 10:08:07 2012 From: yumin.qi at oracle.com (yumin.qi at oracle.com) Date: Tue, 13 Nov 2012 18:08:07 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 6830717: replay of compilations would help with debugging Message-ID: <20121113180816.C973E47935@hg.openjdk.java.net> Changeset: bd7a7ce2e264 Author: minqi Date: 2012-11-12 14:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bd7a7ce2e264 6830717: replay of compilations would help with debugging Summary: When java process crashed in compiler thread, repeat the compilation process will help finding root cause. This is done with using SA dump application class data and replay data from core dump, then use debug version of jvm to recompile the problematic java method. Reviewed-by: kvn, twisti, sspitsyn Contributed-by: yumin.qi at oracle.com + agent/doc/c2replay.html ! agent/doc/clhsdb.html ! agent/doc/index.html ! agent/make/Makefile ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciBaseObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciConstant.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodData.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciMetadata.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.hpp + src/share/vm/ci/ciReplay.cpp + src/share/vm/ci/ciReplay.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/invocationCounter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! src/share/vm/utilities/vmError.cpp From christian.thalinger at oracle.com Tue Nov 13 10:43:56 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Nov 2012 10:43:56 -0800 Subject: RFR (S) 8001538: hs_err file does not list anymore compiled methods in compilation events In-Reply-To: <50A26CF2.10505@oracle.com> References: <50A26CF2.10505@oracle.com> Message-ID: <2525FC70-00E1-4197-8ABB-97343BAD6E0E@oracle.com> On Nov 13, 2012, at 7:53 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8001538/webrev.00/ > > Due to incorrect message buffer size calculation, a message may be truncated to 4/8 characters. > > Also, changed how deoptimization events are logged: > - moved [1] from "Deoptimization events" to "Events" section. > - added [2] to "Deoptimization events" section > > Sample output from a hs_err file: > Deoptimization events (2 events): > Event: 3.438 Thread 0x0000000103804800 Uncommon trap: Test::f @ 23, reason: unloaded, action: reinterpret > Event: 3.482 Thread 0x0000000103804800 Uncommon trap: Test::main @ 38, reason: unloaded, action: reinterpret > > Internal exceptions (10 events): > ... > > Events (10 events): > Event: 3.441 Thread 0x0000000103804800 DEOPT UNPACKING pc=0x00000001046cf214 sp=0x0000000100700548 mode 2 > Event: 3.482 Thread 0x0000000103804800 Uncommon trap 3 fr.pc 0x00000001046ffe1c > ... I have similar change in one of my workspaces: diff --git a/src/share/vm/runtime/deoptimization.cpp b/src/share/vm/runtime/deoptimization.cpp --- a/src/share/vm/runtime/deoptimization.cpp +++ b/src/share/vm/runtime/deoptimization.cpp @@ -1241,10 +1241,6 @@ // before we are done with it. nmethodLocker nl(fr.pc()); - // Log a message - Events::log_deopt_message(thread, "Uncommon trap %d fr.pc " INTPTR_FORMAT, - trap_request, fr.pc()); - { ResourceMark rm; @@ -1265,6 +1261,11 @@ int trap_bci = trap_scope->bci(); Bytecodes::Code trap_bc = trap_method->java_code_at(trap_bci); + // Log a message + Events::log_deopt_message(thread, "Uncommon trap: reason=%s action=%s pc=" INTPTR_FORMAT " method=%s @ %d", + trap_reason_name(reason), trap_action_name(action), fr.pc(), + trap_method->name_and_sig_as_C_string(), trap_bci); + // Record this event in the histogram. gather_statistics(reason, action, trap_bc); Maybe you can merge them. Btw. I find the PC also very helpful in the log_deopt_message. -- Chris > > Testing: JPRT, simple test w/ deopt events in the log. > > Best regards, > Vladimir Ivanov > > [1] Uncommon trap 3 fr.pc 0x00000001046ffe1c > [2] Uncommon trap: Test::f @ 23, reason=unloaded action=reinterpret From christian.thalinger at oracle.com Tue Nov 13 11:00:09 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Nov 2012 11:00:09 -0800 Subject: RFR (S) 8001538: hs_err file does not list anymore compiled methods in compilation events In-Reply-To: <2525FC70-00E1-4197-8ABB-97343BAD6E0E@oracle.com> References: <50A26CF2.10505@oracle.com> <2525FC70-00E1-4197-8ABB-97343BAD6E0E@oracle.com> Message-ID: <5419232C-ADA9-4C0D-9694-4694A6D72ECA@oracle.com> On Nov 13, 2012, at 10:43 AM, Christian Thalinger wrote: > > On Nov 13, 2012, at 7:53 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8001538/webrev.00/ >> >> Due to incorrect message buffer size calculation, a message may be truncated to 4/8 characters. >> >> Also, changed how deoptimization events are logged: >> - moved [1] from "Deoptimization events" to "Events" section. >> - added [2] to "Deoptimization events" section >> >> Sample output from a hs_err file: >> Deoptimization events (2 events): >> Event: 3.438 Thread 0x0000000103804800 Uncommon trap: Test::f @ 23, reason: unloaded, action: reinterpret >> Event: 3.482 Thread 0x0000000103804800 Uncommon trap: Test::main @ 38, reason: unloaded, action: reinterpret >> >> Internal exceptions (10 events): >> ... >> >> Events (10 events): >> Event: 3.441 Thread 0x0000000103804800 DEOPT UNPACKING pc=0x00000001046cf214 sp=0x0000000100700548 mode 2 >> Event: 3.482 Thread 0x0000000103804800 Uncommon trap 3 fr.pc 0x00000001046ffe1c >> ... > > I have similar change in one of my workspaces: > > diff --git a/src/share/vm/runtime/deoptimization.cpp b/src/share/vm/runtime/deoptimization.cpp > --- a/src/share/vm/runtime/deoptimization.cpp > +++ b/src/share/vm/runtime/deoptimization.cpp > @@ -1241,10 +1241,6 @@ > // before we are done with it. > nmethodLocker nl(fr.pc()); > > - // Log a message > - Events::log_deopt_message(thread, "Uncommon trap %d fr.pc " INTPTR_FORMAT, > - trap_request, fr.pc()); > - > { > ResourceMark rm; > > @@ -1265,6 +1261,11 @@ > int trap_bci = trap_scope->bci(); > Bytecodes::Code trap_bc = trap_method->java_code_at(trap_bci); > > + // Log a message > + Events::log_deopt_message(thread, "Uncommon trap: reason=%s action=%s pc=" INTPTR_FORMAT " method=%s @ %d", > + trap_reason_name(reason), trap_action_name(action), fr.pc(), > + trap_method->name_and_sig_as_C_string(), trap_bci); > + > // Record this event in the histogram. > gather_statistics(reason, action, trap_bc); > > Maybe you can merge them. Btw. I find the PC also very helpful in the log_deopt_message. Oh, and this to have enough space in the event log buffer for method names: diff --git a/src/share/vm/utilities/events.hpp b/src/share/vm/utilities/events.hpp --- a/src/share/vm/utilities/events.hpp +++ b/src/share/vm/utilities/events.hpp @@ -135,7 +135,7 @@ }; // A simple wrapper class for fixed size text messages. -class StringLogMessage : public FormatBuffer<132> { +class StringLogMessage : public FormatBuffer<256> { public: // Wrap this buffer in a stringStream. stringStream stream() { -- Chris > > -- Chris > >> >> Testing: JPRT, simple test w/ deopt events in the log. >> >> Best regards, >> Vladimir Ivanov >> >> [1] Uncommon trap 3 fr.pc 0x00000001046ffe1c >> [2] Uncommon trap: Test::f @ 23, reason=unloaded action=reinterpret > From bharadwaj.yadavalli at oracle.com Tue Nov 13 18:44:51 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Tue, 13 Nov 2012 21:44:51 -0500 Subject: RFR(S) 8001077: remove ciMethod::will_link Message-ID: <50A305A3.2060606@oracle.com> Trivial cleanup - http://cr.openjdk.java.net/~bharadwaj/8001077/webrev/ ciMethod::will_link actually returns is_loaded. A comment in the method states: // The link checks have been front-loaded into the get_method // call. This method (ciMethod::will_link()) will be removed // in the future. This comment is there since the duke:0 changeset. Removed will_link and changed all calls to is_loaded(). From vladimir.kozlov at oracle.com Tue Nov 13 18:55:51 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Nov 2012 18:55:51 -0800 Subject: RFR(S) 8001077: remove ciMethod::will_link In-Reply-To: <50A305A3.2060606@oracle.com> References: <50A305A3.2060606@oracle.com> Message-ID: Good. Thanks, Vladimir On Nov 13, 2012, at 6:44 PM, Bharadwaj Yadavalli wrote: > > Trivial cleanup - http://cr.openjdk.java.net/~bharadwaj/8001077/webrev/ > > ciMethod::will_link actually returns is_loaded. A comment in the method states: > > // The link checks have been front-loaded into the get_method > // call. This method (ciMethod::will_link()) will be removed > // in the future. > > This comment is there since the duke:0 changeset. > > Removed will_link and changed all calls to is_loaded(). From bharadwaj.yadavalli at oracle.com Wed Nov 14 09:48:17 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Wed, 14 Nov 2012 12:48:17 -0500 Subject: RFR(S) 8001077: remove ciMethod::will_link In-Reply-To: References: <50A305A3.2060606@oracle.com> Message-ID: <50A3D961.5030502@oracle.com> Thanks for the review, Vladimir. Bharadwaj On 11/13/2012 9:55 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On Nov 13, 2012, at 6:44 PM, Bharadwaj Yadavalli wrote: > >> Trivial cleanup - http://cr.openjdk.java.net/~bharadwaj/8001077/webrev/ >> >> ciMethod::will_link actually returns is_loaded. A comment in the method states: >> >> // The link checks have been front-loaded into the get_method >> // call. This method (ciMethod::will_link()) will be removed >> // in the future. >> >> This comment is there since the duke:0 changeset. >> >> Removed will_link and changed all calls to is_loaded(). From xiaoming.gu at gmail.com Wed Nov 14 10:54:36 2012 From: xiaoming.gu at gmail.com (xiaoming gu) Date: Wed, 14 Nov 2012 10:54:36 -0800 Subject: looking for workloads impacted by OptimizeStringConcat Message-ID: Could anyone point out one or more workloads in DaCapo or SPECjvm showing consistent improvement with -XX:+OptimizeStringConcat? (I know this optimization has become default. Actually I'm looking for workloads showing slowdown with -XX:-OptimizeStringConcat.) Thanks. -Xiaoming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121114/16432e33/attachment.html From nils.eliasson at oracle.com Thu Nov 15 01:12:04 2012 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 15 Nov 2012 10:12:04 +0100 Subject: Removing LogCleanUpReader Message-ID: <50A4B1E4.8040805@oracle.com> Anyone against removing the LogCleanUpReader from share/tools? According to the comments it was used for 1.5/1.6 to handle malformed xml from LogCompilation. //Nils From vladimir.x.ivanov at oracle.com Thu Nov 15 07:57:40 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 15 Nov 2012 18:57:40 +0300 Subject: How to reliably pin a node in CFG? Message-ID: <50A510F4.9060009@oracle.com> Hi, I'm looking at 8003135 [1] and the problem is that during null check (#132) hoisting, the load (#172) is also hoisted [2] [3]. LoadI node is constructed in LibraryCallKit::inline_native_isInterrupted and is pinned to IfTrue projection (#133) of #132, but it doesn't help. I'm not sure how to avoid the hoisting of the load. Should the load be pinned to corresponding Region/Loop node instead of If node? Is the logic in PhaseIdealLoop::dominated_by which updates control-dependent nodes (:242-:255)is correct? Best regards, Vladimir Ivanov [1] https://jbs.oracle.com/bugs/browse/JDK-8003135 "HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop" [2] http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loop_invariant_hoisting_132_before.png [3] http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loop_invariant_hoisting_132_after.png From vladimir.x.ivanov at oracle.com Thu Nov 15 09:33:39 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 15 Nov 2012 20:33:39 +0300 Subject: RFR (S) 8001538: hs_err file does not list anymore compiled methods in compilation events In-Reply-To: <3F7665E3-3C59-475E-837D-242213CE7619@oracle.com> References: <50A26CF2.10505@oracle.com> <3F7665E3-3C59-475E-837D-242213CE7619@oracle.com> Message-ID: <50A52773.8040208@oracle.com> Vladimir K., Chris, thank you for the review. Yes, it restores original compilation events format [1] I verified that it's safe to use objects from resource area for logging: event logger copies message content into internal buffer. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/ Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/hs_err_pid87677.log On 11/13/12 7:41 PM, Vladimir Kozlov wrote: > Very nice fix, Vladimir I., thank you > > To confirm, the size fix restored methods names in compilation events. Right? > > You moved deoptimization event logging under resourceMark, make sure the logging code does not use resource area or copied from it to safe place. > > Thanks, > Vladimir > > On Nov 13, 2012, at 7:53 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8001538/webrev.00/ >> >> Due to incorrect message buffer size calculation, a message may be truncated to 4/8 characters. >> >> Also, changed how deoptimization events are logged: >> - moved [1] from "Deoptimization events" to "Events" section. >> - added [2] to "Deoptimization events" section >> >> Sample output from a hs_err file: >> Deoptimization events (2 events): >> Event: 3.438 Thread 0x0000000103804800 Uncommon trap: Test::f @ 23, reason: unloaded, action: reinterpret >> Event: 3.482 Thread 0x0000000103804800 Uncommon trap: Test::main @ 38, reason: unloaded, action: reinterpret >> >> Internal exceptions (10 events): >> ... >> >> Events (10 events): >> Event: 3.441 Thread 0x0000000103804800 DEOPT UNPACKING pc=0x00000001046cf214 sp=0x0000000100700548 mode 2 >> Event: 3.482 Thread 0x0000000103804800 Uncommon trap 3 fr.pc 0x00000001046ffe1c >> ... >> >> Testing: JPRT, simple test w/ deopt events in the log. >> >> Best regards, >> Vladimir Ivanov >> >> [1] Uncommon trap 3 fr.pc 0x00000001046ffe1c >> [2] Uncommon trap: Test::f @ 23, reason=unloaded action=reinterpret > From Vladimir.Kozlov at oracle.com Thu Nov 15 09:00:16 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Nov 2012 09:00:16 -0800 Subject: Removing LogCleanUpReader In-Reply-To: <50A4B1E4.8040805@oracle.com> References: <50A4B1E4.8040805@oracle.com> Message-ID: <50A51FA0.6050404@oracle.com> No, keep it. LogCompilation tool is not release dependent so we can build it from current sources and use it to parse logs from previous jdk releases. Vladimir On 11/15/12 01:12, Nils Eliasson wrote: > Anyone against removing the LogCleanUpReader from share/tools? > > According to the comments it was used for 1.5/1.6 to handle malformed > xml from LogCompilation. > > //Nils From Vladimir.Kozlov at oracle.com Thu Nov 15 10:36:35 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Nov 2012 10:36:35 -0800 Subject: RFR(S) 8001077: remove ciMethod::will_link In-Reply-To: <50A3D961.5030502@oracle.com> References: <50A305A3.2060606@oracle.com> <50A3D961.5030502@oracle.com> Message-ID: <50A53633.6090602@oracle.com> The changes are very simple so I will push it with one reviewer. Thanks, Vladimir On 11/14/12 09:48, Bharadwaj Yadavalli wrote: > Thanks for the review, Vladimir. > > Bharadwaj > > On 11/13/2012 9:55 PM, Vladimir Kozlov wrote: >> Good. >> >> Thanks, >> Vladimir >> >> On Nov 13, 2012, at 6:44 PM, Bharadwaj Yadavalli wrote: >> >>> Trivial cleanup - http://cr.openjdk.java.net/~bharadwaj/8001077/webrev/ >>> >>> ciMethod::will_link actually returns is_loaded. A comment in the >>> method states: >>> >>> // The link checks have been front-loaded into the get_method >>> // call. This method (ciMethod::will_link()) will be removed >>> // in the future. >>> >>> This comment is there since the duke:0 changeset. >>> >>> Removed will_link and changed all calls to is_loaded(). From bharadwaj.yadavalli at oracle.com Thu Nov 15 10:44:16 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 15 Nov 2012 13:44:16 -0500 Subject: RFR(S) 8001077: remove ciMethod::will_link In-Reply-To: <50A53633.6090602@oracle.com> References: <50A305A3.2060606@oracle.com> <50A3D961.5030502@oracle.com> <50A53633.6090602@oracle.com> Message-ID: <50A53800.80407@oracle.com> That would be great. Thanks. Bharadwaj On 11/15/2012 1:36 PM, Vladimir Kozlov wrote: > The changes are very simple so I will push it with one reviewer. > > Thanks, > Vladimir > > On 11/14/12 09:48, Bharadwaj Yadavalli wrote: >> Thanks for the review, Vladimir. >> >> Bharadwaj >> >> On 11/13/2012 9:55 PM, Vladimir Kozlov wrote: >>> Good. >>> >>> Thanks, >>> Vladimir >>> >>> On Nov 13, 2012, at 6:44 PM, Bharadwaj Yadavalli wrote: >>> >>>> Trivial cleanup - >>>> http://cr.openjdk.java.net/~bharadwaj/8001077/webrev/ >>>> >>>> ciMethod::will_link actually returns is_loaded. A comment in the >>>> method states: >>>> >>>> // The link checks have been front-loaded into the get_method >>>> // call. This method (ciMethod::will_link()) will be removed >>>> // in the future. >>>> >>>> This comment is there since the duke:0 changeset. >>>> >>>> Removed will_link and changed all calls to is_loaded(). From Vladimir.Kozlov at oracle.com Thu Nov 15 10:50:59 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Nov 2012 10:50:59 -0800 Subject: RFR (S) 8001538: hs_err file does not list anymore compiled methods in compilation events In-Reply-To: <50A52773.8040208@oracle.com> References: <50A26CF2.10505@oracle.com> <3F7665E3-3C59-475E-837D-242213CE7619@oracle.com> <50A52773.8040208@oracle.com> Message-ID: <50A53993.4030308@oracle.com> Good. Vladimir On 11/15/12 09:33, Vladimir Ivanov wrote: > Vladimir K., Chris, thank you for the review. > > Yes, it restores original compilation events format [1] > > I verified that it's safe to use objects from resource area for logging: > event logger copies message content into internal buffer. > > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/ > > Best regards, > Vladimir Ivanov > > [1] > http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/hs_err_pid87677.log > > On 11/13/12 7:41 PM, Vladimir Kozlov wrote: >> Very nice fix, Vladimir I., thank you >> >> To confirm, the size fix restored methods names in compilation events. >> Right? >> >> You moved deoptimization event logging under resourceMark, make sure >> the logging code does not use resource area or copied from it to safe >> place. >> >> Thanks, >> Vladimir >> >> On Nov 13, 2012, at 7:53 AM, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8001538/webrev.00/ >>> >>> Due to incorrect message buffer size calculation, a message may be >>> truncated to 4/8 characters. >>> >>> Also, changed how deoptimization events are logged: >>> - moved [1] from "Deoptimization events" to "Events" section. >>> - added [2] to "Deoptimization events" section >>> >>> Sample output from a hs_err file: >>> Deoptimization events (2 events): >>> Event: 3.438 Thread 0x0000000103804800 Uncommon trap: Test::f @ 23, >>> reason: unloaded, action: reinterpret >>> Event: 3.482 Thread 0x0000000103804800 Uncommon trap: Test::main @ >>> 38, reason: unloaded, action: reinterpret >>> >>> Internal exceptions (10 events): >>> ... >>> >>> Events (10 events): >>> Event: 3.441 Thread 0x0000000103804800 DEOPT UNPACKING >>> pc=0x00000001046cf214 sp=0x0000000100700548 mode 2 >>> Event: 3.482 Thread 0x0000000103804800 Uncommon trap 3 fr.pc >>> 0x00000001046ffe1c >>> ... >>> >>> Testing: JPRT, simple test w/ deopt events in the log. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] Uncommon trap 3 fr.pc 0x00000001046ffe1c >>> [2] Uncommon trap: Test::f @ 23, reason=unloaded action=reinterpret >> From Vladimir.Kozlov at oracle.com Thu Nov 15 12:24:27 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Nov 2012 12:24:27 -0800 Subject: How to reliably pin a node in CFG? In-Reply-To: <50A510F4.9060009@oracle.com> References: <50A510F4.9060009@oracle.com> Message-ID: <50A54F7B.3020402@oracle.com> PhaseIdealLoop::dominated_by() and IfNode::dominated_by() are correct in general case. The problem is value of depends_only_on_test(). This load is from RAW memory and we should not hoist it. See comment in LoadPNode class declaration. So we can widen the case to all loads - we have to confirm this with John. An other simple way to fix it is to add membar before load since it is volatile field: insert_mem_bar(Op_MemBarCPUOrder); Vladimir K. On 11/15/12 07:57, Vladimir Ivanov wrote: > Hi, > > I'm looking at 8003135 [1] and the problem is that during null check > (#132) hoisting, the load (#172) is also hoisted [2] [3]. LoadI node is > constructed in LibraryCallKit::inline_native_isInterrupted > and is pinned to IfTrue projection (#133) of #132, but it doesn't help. > > I'm not sure how to avoid the hoisting of the load. > > Should the load be pinned to corresponding Region/Loop node instead of > If node? > > Is the logic in PhaseIdealLoop::dominated_by which updates > control-dependent nodes (:242-:255)is correct? > > Best regards, > Vladimir Ivanov > > [1] https://jbs.oracle.com/bugs/browse/JDK-8003135 > "HotSpot inlines and hoists the Thread.currentThread().isInterrupted() > out of the loop" > > [2] > http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loop_invariant_hoisting_132_before.png > > > [3] > http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loop_invariant_hoisting_132_after.png > From vladimir.kozlov at oracle.com Thu Nov 15 12:52:25 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Thu, 15 Nov 2012 20:52:25 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8001077: remove ciMethod::will_link Message-ID: <20121115205228.35AE6479BF@hg.openjdk.java.net> Changeset: bb33c6fdcf0d Author: bharadwaj Date: 2012-11-15 10:42 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/bb33c6fdcf0d 8001077: remove ciMethod::will_link Summary: Removed will_link and changed all calls to is_loaded(). Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/opto/doCall.cpp From john.coomes at oracle.com Fri Nov 16 01:47:26 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Nov 2012 09:47:26 +0000 Subject: hg: hsx/hotspot-comp: 5 new changesets Message-ID: <20121116094727.25563479EB@hg.openjdk.java.net> Changeset: 8bbc72864a41 Author: ohrstrom Date: 2012-11-08 12:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/8bbc72864a41 8003161: small fixes to re-enable new build system Reviewed-by: dholmes, alanb, erikj ! common/makefiles/JavaCompilation.gmk Changeset: 78bb27faf889 Author: tbell Date: 2012-11-12 12:34 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/78bb27faf889 8002028: build-infra: need no-hotspot partial build Summary: Added configure option --with-import-hotspot=/path/to/j2sdkimage Reviewed-by: dholmes, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/source-dirs.m4 ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: f2ac4d0edaae Author: tbell Date: 2012-11-13 15:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/f2ac4d0edaae 8003274: build-infra: Makefile changes needed for sjavac Summary: changes left in build-infra that are related to sjavac Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com, fredrik.ohrstrom at oracle.com ! common/autoconf/spec.gmk.in ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeHelpers.gmk Changeset: b772de306dc2 Author: katleman Date: 2012-11-14 12:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/b772de306dc2 Merge Changeset: 0e1b5886b06c Author: katleman Date: 2012-11-15 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/0e1b5886b06c Added tag jdk8-b65 for changeset b772de306dc2 ! .hgtags From john.coomes at oracle.com Fri Nov 16 01:47:31 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Nov 2012 09:47:31 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b65 for changeset 5132f7900a8f Message-ID: <20121116094735.51D1C479EC@hg.openjdk.java.net> Changeset: 65771ad1ca55 Author: katleman Date: 2012-11-15 15:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/65771ad1ca55 Added tag jdk8-b65 for changeset 5132f7900a8f ! .hgtags From john.coomes at oracle.com Fri Nov 16 01:47:39 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Nov 2012 09:47:39 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b65 for changeset 5cf3c69a93d6 Message-ID: <20121116094753.84C1D479ED@hg.openjdk.java.net> Changeset: e6af1ad464e3 Author: katleman Date: 2012-11-15 15:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/e6af1ad464e3 Added tag jdk8-b65 for changeset 5cf3c69a93d6 ! .hgtags From john.coomes at oracle.com Fri Nov 16 01:47:59 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Nov 2012 09:47:59 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b65 for changeset fbe54291c9d3 Message-ID: <20121116094806.06C4F479EE@hg.openjdk.java.net> Changeset: 3eb7f11cb4e0 Author: katleman Date: 2012-11-15 15:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/3eb7f11cb4e0 Added tag jdk8-b65 for changeset fbe54291c9d3 ! .hgtags From john.coomes at oracle.com Fri Nov 16 01:49:09 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Nov 2012 09:49:09 +0000 Subject: hg: hsx/hotspot-comp/jdk: 31 new changesets Message-ID: <20121116095550.9AE37479F0@hg.openjdk.java.net> Changeset: bc09a1591629 Author: alanb Date: 2012-11-04 14:07 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bc09a1591629 8000330: (fc) FileChannel.truncate issues when given size > file size 8002180: (fc) FileChannel.map does not throw NPE if MapMode specified as null Reviewed-by: chegar ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! test/java/nio/channels/FileChannel/MapTest.java ! test/java/nio/channels/FileChannel/Truncate.java Changeset: 46b24eb85b86 Author: mullan Date: 2012-11-05 10:30 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/46b24eb85b86 7171570: JEP 124 Potential API Changes Reviewed-by: vinnie, xuelei ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! test/java/security/cert/PKIXRevocationChecker/UnitTest.java Changeset: 4770b0a49675 Author: mullan Date: 2012-11-05 10:33 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4770b0a49675 Merge - make/sun/jdbc/Makefile - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java - src/solaris/native/java/io/FileSystem_md.c - src/windows/native/java/io/FileSystem_md.c Changeset: 510cb3671f14 Author: mullan Date: 2012-11-05 12:08 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/510cb3671f14 Merge Changeset: 519f4c9ebf8d Author: vinnie Date: 2012-11-05 20:18 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/519f4c9ebf8d 6383200: PBE: need new algorithm support in password based encryption Reviewed-by: valeriep ! src/share/classes/com/sun/crypto/provider/PBEKeyFactory.java ! src/share/classes/com/sun/crypto/provider/PBEParameters.java + src/share/classes/com/sun/crypto/provider/PBES1Core.java + src/share/classes/com/sun/crypto/provider/PBES2Core.java + src/share/classes/com/sun/crypto/provider/PBES2Parameters.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java ! src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java + src/share/classes/com/sun/crypto/provider/PBKDF2Core.java + src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/javax/crypto/spec/PBEParameterSpec.java ! test/com/sun/crypto/provider/Cipher/PBE/PBEInvalidParamsTest.java ! test/com/sun/crypto/provider/Cipher/PBE/PBEKeysAlgorithmNames.java ! test/com/sun/crypto/provider/Cipher/PBE/PBEParametersTest.java + test/com/sun/crypto/provider/Cipher/PBE/PBES2Test.java ! test/com/sun/crypto/provider/Cipher/PBE/PKCS12Cipher.java ! test/com/sun/crypto/provider/Cipher/PBE/PKCS12Oid.java ! test/com/sun/crypto/provider/Mac/HmacPBESHA1.java ! test/com/sun/crypto/provider/Mac/HmacSaltLengths.java Changeset: 798292c71419 Author: ksrini Date: 2012-11-05 14:53 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/798292c71419 8001191: use -source 8 -target 8 when compiling the JDK Reviewed-by: chegar, dholmes, erikj, jgish ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-java.gmk ! make/java/invoke/Makefile ! makefiles/Setup.gmk ! src/share/classes/sun/tools/java/RuntimeConstants.java ! src/share/native/java/lang/System.c ! test/ProblemList.txt Changeset: 8222e6eac651 Author: ksrini Date: 2012-11-05 15:00 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/8222e6eac651 7050936: (pack200) Support version 52.0 class files in langtools Reviewed-by: dholmes ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/native/com/sun/java/util/jar/pack/constants.h Changeset: cb65e3315b27 Author: jiangli Date: 2012-11-05 12:51 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cb65e3315b27 7197210: java/lang/invoke/CallSiteTest.java failing on armsflt. Summary: Reduce work load and set longer timeout for java/lang/invoke tests. Reviewed-by: kvn, twisti ! test/java/lang/invoke/BigArityTest.java ! test/java/lang/invoke/CallSiteTest.java ! test/java/lang/invoke/MethodHandlesTest.java ! test/java/lang/invoke/RicochetTest.java Changeset: d90714aec287 Author: lancea Date: 2012-11-06 14:59 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/d90714aec287 8002212: adding read/writeObject to additional SerialXXX classes Reviewed-by: naoto, forax ! src/share/classes/javax/sql/rowset/serial/SerialArray.java ! src/share/classes/javax/sql/rowset/serial/SerialDatalink.java ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java ! src/share/classes/javax/sql/rowset/serial/SerialRef.java ! src/share/classes/javax/sql/rowset/serial/SerialStruct.java Changeset: 157506182fa7 Author: chegar Date: 2012-11-06 21:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/157506182fa7 8002297: sun/net/www/protocol/http/StackTraceTest.java fails intermittently Reviewed-by: alanb, dsamersoff ! test/sun/net/www/protocol/http/StackTraceTest.java Changeset: bff9db7ca352 Author: peytoia Date: 2012-11-07 09:58 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/bff9db7ca352 7198195: Support Unicode 6.2.0 Reviewed-by: okutsu ! make/tools/GenerateCharacter/CharacterData01.java.template ! make/tools/UnicodeData/PropList.txt ! make/tools/UnicodeData/Scripts.txt ! make/tools/UnicodeData/SpecialCasing.txt ! make/tools/UnicodeData/UnicodeData.txt ! make/tools/UnicodeData/VERSION ! src/share/classes/java/lang/Character.java ! test/java/lang/Character/CheckProp.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/Character/PropList.txt ! test/java/lang/Character/PropertyValueAliases.txt ! test/java/lang/Character/Scripts.txt Changeset: c9fd61d23dbe Author: lana Date: 2012-11-06 18:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c9fd61d23dbe Merge - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java Changeset: a1bbb8805e22 Author: weijun Date: 2012-11-07 14:13 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/a1bbb8805e22 6355584: Introduce constrained Kerberos delegation Reviewed-by: valeriep + src/share/classes/com/sun/security/jgss/ExtendedGSSCredential.java ! src/share/classes/sun/security/jgss/GSSCaller.java ! src/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/share/classes/sun/security/jgss/HttpCaller.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java + src/share/classes/sun/security/jgss/krb5/Krb5ProxyCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/jgss/spi/GSSCredentialSpi.java ! src/share/classes/sun/security/jgss/spnego/SpNegoContext.java ! src/share/classes/sun/security/jgss/spnego/SpNegoCredElement.java ! src/share/classes/sun/security/jgss/wrapper/GSSCredElement.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/EncryptedData.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/KrbKdcRep.java ! src/share/classes/sun/security/krb5/KrbTgsRep.java ! src/share/classes/sun/security/krb5/KrbTgsReq.java ! src/share/classes/sun/security/krb5/internal/CredentialsUtil.java ! src/share/classes/sun/security/krb5/internal/EncKDCRepPart.java ! src/share/classes/sun/security/krb5/internal/KDCOptions.java ! src/share/classes/sun/security/krb5/internal/Krb5.java ! src/share/classes/sun/security/krb5/internal/PAData.java + src/share/classes/sun/security/krb5/internal/PAForUserEnc.java ! src/share/classes/sun/security/krb5/internal/crypto/KeyUsage.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! test/sun/security/krb5/auto/Basic.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/OkAsDelegate.java + test/sun/security/krb5/auto/S4U2proxy.java + test/sun/security/krb5/auto/S4U2proxyGSS.java + test/sun/security/krb5/auto/S4U2self.java + test/sun/security/krb5/auto/S4U2selfAsServer.java + test/sun/security/krb5/auto/S4U2selfAsServerGSS.java + test/sun/security/krb5/auto/S4U2selfGSS.java Changeset: 59e88d3b9b17 Author: jzavgren Date: 2012-11-07 10:49 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/59e88d3b9b17 8001579: Cleanup warnings in security native code Reviewed-by: chegar, alanb, vinnie ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c ! src/share/native/sun/security/jgss/wrapper/NativeUtil.c ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/solaris/native/sun/security/pkcs11/j2secmod_md.c ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c Changeset: 9e013ce42dd7 Author: dfuchs Date: 2012-11-07 13:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9e013ce42dd7 6720349: (ch) Channels tests depending on hosts inside Sun Summary: This changeset make the nio tests start small TCP or UDP servers from within the tests, instead of relying on external services. Reviewed-by: alanb ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java ! test/java/nio/channels/DatagramChannel/IsBound.java ! test/java/nio/channels/DatagramChannel/IsConnected.java ! test/java/nio/channels/Selector/Alias.java ! test/java/nio/channels/Selector/BasicConnect.java ! test/java/nio/channels/Selector/Connect.java ! test/java/nio/channels/Selector/ConnectWrite.java ! test/java/nio/channels/Selector/KeysReady.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java ! test/java/nio/channels/SocketChannel/Basic.java ! test/java/nio/channels/SocketChannel/BufferSize.java ! test/java/nio/channels/SocketChannel/Connect.java ! test/java/nio/channels/SocketChannel/ConnectState.java ! test/java/nio/channels/SocketChannel/FinishConnect.java ! test/java/nio/channels/SocketChannel/IsConnectable.java ! test/java/nio/channels/SocketChannel/LocalAddress.java ! test/java/nio/channels/SocketChannel/Stream.java ! test/java/nio/channels/SocketChannel/VectorParams.java + test/java/nio/channels/TestServers.java ! test/java/nio/channels/TestUtil.java Changeset: 7d50ff0e2d44 Author: coffeys Date: 2012-11-07 18:48 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7d50ff0e2d44 8002227: (tz) Support tzdata2012i Reviewed-by: peytoia, asaha ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/southamerica ! makefiles/GendataTimeZone.gmk Changeset: f51943263267 Author: andrew Date: 2012-11-07 16:07 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f51943263267 8003120: ResourceManager.getApplicationResources() does not close InputStreams Summary: Add finally blocks to close the InputStream instances Reviewed-by: lancea ! src/share/classes/com/sun/naming/internal/ResourceManager.java Changeset: cc325832469c Author: naoto Date: 2012-11-07 15:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cc325832469c 8001205: Calendar.getDisplayName(...): Returns null when provider is SPI but there is no SPI implementation 8001562: Collator.getAvailableLocales() doesn't return all locales for which localized instances are available Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java + test/java/util/Locale/Bug8001562.java ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java Changeset: 599f231cba97 Author: jfranck Date: 2012-11-07 17:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/599f231cba97 8001598: Augment ElementType enum for JSR 308 Reviewed-by: darcy ! src/share/classes/java/lang/annotation/ElementType.java Changeset: cdf02b372956 Author: sherman Date: 2012-11-07 20:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/cdf02b372956 6282196: There should be Math.mod(number, modulo) methods Summary: added the requested methods Reviewed-by: darcy, emcmanus, alanb Contributed-by: roger.riggs at oracle.com ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java + test/java/lang/Math/DivModTests.java Changeset: 1e7dd9e05ce2 Author: mullan Date: 2012-11-08 12:51 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1e7dd9e05ce2 7198416: CertificateIssuerName and CertificateSubjectName are redundant Reviewed-by: mullan Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/pkcs/PKCS7.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/x509/X509CertImpl.java ! src/share/classes/sun/security/x509/X509CertInfo.java ! src/share/classes/sun/security/x509/certAttributes.html ! test/sun/security/pkcs11/rsa/GenKeyStore.java ! test/sun/security/provider/X509Factory/BigCRL.java ! test/sun/security/rsa/GenKeyStore.java Changeset: 9edfa0e761b9 Author: xuelei Date: 2012-11-09 01:15 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/9edfa0e761b9 8001569: Regression test GetPeerHost uses static port number Reviewed-by: weijun ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHost.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostClient.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ServerHandshaker/GetPeerHostServer.java Changeset: 220d2458ce4b Author: lana Date: 2012-11-09 14:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/220d2458ce4b Merge Changeset: 3717bcf9d7a7 Author: dholmes Date: 2012-11-07 23:12 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3717bcf9d7a7 8002040: Allow Full Debug Symbols when cross-compiling Reviewed-by: dcubed, erikj, tbell ! make/common/Defs-linux.gmk Changeset: 1e79fec4a01f Author: ohrstrom Date: 2012-11-08 12:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/1e79fec4a01f 8003161: small fixes to re-enable new build system Reviewed-by: dholmes, alanb, erikj ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk Changeset: 170e8ccfbc4f Author: tbell Date: 2012-11-12 10:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/170e8ccfbc4f 8002365: build-infra: Build-infra fails on solaris 11.1 on sparc. Summary: Add '-lc' to LDFLAGS for native libraries in CompileNativeLibraries.gmk Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/CompileNativeLibraries.gmk Changeset: 2fc142843a93 Author: tbell Date: 2012-11-12 10:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2fc142843a93 8003177: build-infra: Compare reports diff in LocaleDataMetaInfo.class Summary: Remove spurious space in the locale lists Reviewed-by: naoto, ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/GensrcLocaleDataMetaInfo.gmk Changeset: e9e8a5852690 Author: tbell Date: 2012-11-12 12:35 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e9e8a5852690 8002028: build-infra: need no-hotspot partial build Summary: Added configure option --with-import-hotspot=/path/to/j2sdkimage Reviewed-by: dholmes, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/Import.gmk Changeset: 84f0439ccaab Author: tbell Date: 2012-11-13 13:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/84f0439ccaab 8001965: build-infra: Large compare diffs between new and old on mac Summary: The wrong icon source file was used when building closed Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/GensrcIcons.gmk Changeset: 130d3a54d28b Author: katleman Date: 2012-11-14 12:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/130d3a54d28b Merge Changeset: c87df8b1f55e Author: katleman Date: 2012-11-15 15:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c87df8b1f55e Added tag jdk8-b65 for changeset 130d3a54d28b ! .hgtags From john.coomes at oracle.com Fri Nov 16 01:57:43 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 16 Nov 2012 09:57:43 +0000 Subject: hg: hsx/hotspot-comp/langtools: 16 new changesets Message-ID: <20121116095821.55C21479F1@hg.openjdk.java.net> Changeset: 2443d24d096a Author: vromero Date: 2012-11-01 13:06 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2443d24d096a 6949443: visitTree assertion triggered using -Xjcov on small sample program Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java + test/tools/javac/options/T6949443.java Changeset: a33770a91b00 Author: jjg Date: 2012-11-02 19:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a33770a91b00 Merge Changeset: ef3ad754f5c7 Author: jjg Date: 2012-11-03 21:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/ef3ad754f5c7 8002146: javadoc doesn't release resources in a timely manner Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/Start.java Changeset: 352d130c47c5 Author: jjg Date: 2012-11-03 21:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/352d130c47c5 8002168: Cleanup initialization of javadoc Messager Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/Start.java ! test/tools/javadoc/6958836/Test.java Changeset: d7d932236fee Author: mcimadamore Date: 2012-11-04 10:59 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d7d932236fee 7192246: Add type-checking support for default methods Summary: Add type-checking support for default methods as per Featherweight-Defender document Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/ClassReaderTest/ClassReaderTest.java + test/tools/javac/defaultMethods/ClassReaderTest/pkg/Foo.java + test/tools/javac/defaultMethods/Neg01.java + test/tools/javac/defaultMethods/Neg01.out + test/tools/javac/defaultMethods/Neg02.java + test/tools/javac/defaultMethods/Neg02.out + test/tools/javac/defaultMethods/Neg03.java + test/tools/javac/defaultMethods/Neg03.out + test/tools/javac/defaultMethods/Neg04.java + test/tools/javac/defaultMethods/Neg04.out + test/tools/javac/defaultMethods/Neg05.java + test/tools/javac/defaultMethods/Neg05.out + test/tools/javac/defaultMethods/Neg06.java + test/tools/javac/defaultMethods/Neg06.out + test/tools/javac/defaultMethods/Neg07.java + test/tools/javac/defaultMethods/Neg07.out + test/tools/javac/defaultMethods/Neg08.java + test/tools/javac/defaultMethods/Neg08.out + test/tools/javac/defaultMethods/Neg09.java + test/tools/javac/defaultMethods/Neg09.out + test/tools/javac/defaultMethods/Neg10.java + test/tools/javac/defaultMethods/Neg10.out + test/tools/javac/defaultMethods/Neg11.java + test/tools/javac/defaultMethods/Neg11.out + test/tools/javac/defaultMethods/Neg12.java + test/tools/javac/defaultMethods/Neg12.out + test/tools/javac/defaultMethods/Neg13.java + test/tools/javac/defaultMethods/Neg13.out + test/tools/javac/defaultMethods/Neg14.java + test/tools/javac/defaultMethods/Neg14.out + test/tools/javac/defaultMethods/Neg15.java + test/tools/javac/defaultMethods/Neg15.out + test/tools/javac/defaultMethods/Neg16.java + test/tools/javac/defaultMethods/Neg16.out + test/tools/javac/defaultMethods/Pos01.java + test/tools/javac/defaultMethods/Pos02.java + test/tools/javac/defaultMethods/Pos04.java + test/tools/javac/defaultMethods/Pos05.java + test/tools/javac/defaultMethods/Pos06.java + test/tools/javac/defaultMethods/Pos07.java + test/tools/javac/defaultMethods/Pos08.java + test/tools/javac/defaultMethods/Pos10.java + test/tools/javac/defaultMethods/Pos11.java + test/tools/javac/defaultMethods/Pos12.java + test/tools/javac/defaultMethods/Pos13.java + test/tools/javac/defaultMethods/Pos14.java + test/tools/javac/defaultMethods/Pos15.java + test/tools/javac/defaultMethods/Pos16.java + test/tools/javac/defaultMethods/TestDefaultBody.java + test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java + test/tools/javac/defaultMethods/crossCompile/Clinit.java + test/tools/javac/defaultMethods/crossCompile/CrossCompile.java + test/tools/javac/defaultMethods/fd/FDTest.java + test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java + test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java + test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java + test/tools/javac/defaultMethods/fd/shapegen/Rule.java + test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java + test/tools/javac/defaultMethods/fd/shapegen/TTNode.java + test/tools/javac/defaultMethods/fd/shapegen/TTParser.java + test/tools/javac/defaultMethods/fd/shapegen/TTShape.java + test/tools/javac/defaultMethods/separate/Separate.java + test/tools/javac/defaultMethods/separate/pkg1/A.java + test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java + test/tools/javac/diags/examples/DefaultOverridesObjectMember.java + test/tools/javac/diags/examples/OverriddenDefault.java + test/tools/javac/diags/examples/RedundantSupertype.java + test/tools/javac/diags/examples/TypesIncompatibleAbstractDefault.java + test/tools/javac/diags/examples/TypesIncompatibleUnrelatedDefaults.java ! test/tools/javac/generics/7022054/T7022054pos1.java ! test/tools/javac/generics/7022054/T7022054pos2.java ! test/tools/javac/scope/7046348/EagerInterfaceCompletionTest.java Changeset: dbc94b8363dd Author: mcimadamore Date: 2012-11-04 11:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/dbc94b8363dd 8000931: Cleanup Resolve.java Summary: Unify all method resolution routines Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/7132880/T7132880.out ! test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/defaultMethods/Neg12.out ! test/tools/javac/generics/inference/6611449/T6611449.out ! test/tools/javac/generics/inference/7086601/T7086601a.out + test/tools/javac/resolve/tests/AmbiguityPrecedence.java Changeset: 9bce0c73583d Author: ksrini Date: 2012-10-31 10:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9bce0c73583d 8001112: Make -target 8 in javac generate version 52.0 classfile Reviewed-by: darcy, jjg ! src/share/classes/com/sun/tools/javac/jvm/Target.java ! test/tools/javac/classfiles/ClassVersionChecker.java ! test/tools/javac/versions/check.sh Changeset: 9b85813d2262 Author: mcimadamore Date: 2012-11-06 14:45 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/9b85813d2262 8002286: Regression: Fix for 8000931 causes a JCK test failure Summary: Wrong type used as 'site' in Resolve.resolveMethod Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/8002286/T8002286.java + test/tools/javac/8002286/T8002286.out Changeset: 8abc56be3131 Author: jjg Date: 2012-11-06 14:32 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/8abc56be3131 8000612: Discrepancy between resources provided in javadoc resource files and resources required by code Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! test/tools/javac/diags/CheckResourceKeys.java + test/tools/javadoc/CheckResourceKeys.java Changeset: 55a007aaf63d Author: jjg Date: 2012-11-06 17:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/55a007aaf63d 7198690: missing compiler message Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/main/Main.java Changeset: 6dc8616cea9b Author: lana Date: 2012-11-06 18:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/6dc8616cea9b Merge Changeset: 19d6ba779759 Author: vromero Date: 2012-11-05 16:26 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/19d6ba779759 8000484: Bad error recovery when 'catch' without 'try' is found Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/diags/examples/CatchWithoutTry.java + test/tools/javac/incompleteStatements/T8000484.java + test/tools/javac/incompleteStatements/T8000484.out Changeset: 2986e7052952 Author: jjg Date: 2012-11-07 17:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2986e7052952 8002157: Write combo compiler tests for repeating annotations for JDK8 Reviewed-by: darcy, jjg Contributed-by: sonali.goel at oracle.com + test/tools/javac/annotations/repeatingAnnotations/combo/BasicSyntaxCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/DeprecatedAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/DocumentedAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java + test/tools/javac/annotations/repeatingAnnotations/combo/InheritedAnnoCombo.java + test/tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java Changeset: a1dc543483fc Author: jjg Date: 2012-11-07 17:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a1dc543483fc 8003134: CheckResourceKeys issues Reviewed-by: jjh, bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard.properties ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javadoc/CheckResourceKeys.java Changeset: 5f2faba89cac Author: lana Date: 2012-11-09 14:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/5f2faba89cac Merge Changeset: b5d326a809a1 Author: katleman Date: 2012-11-15 15:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b5d326a809a1 Added tag jdk8-b65 for changeset 5f2faba89cac ! .hgtags From nils.eliasson at oracle.com Fri Nov 16 08:30:42 2012 From: nils.eliasson at oracle.com (nils.eliasson at oracle.com) Date: Fri, 16 Nov 2012 16:30:42 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7 new changesets Message-ID: <20121116163107.173E147A0C@hg.openjdk.java.net> Changeset: 6cb0d32b828b Author: bpittore Date: 2012-11-07 17:53 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6cb0d32b828b 8001185: parsing of sun.boot.library.path in os::dll_build_name somewhat broken Summary: dll_dir can contain multiple paths, need to parse them correctly when loading agents Reviewed-by: dholmes, dlong Contributed-by: bill.pittore at oracle.com ! src/os/bsd/vm/os_bsd.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/classfile/classLoader.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp Changeset: d9a84e246cce Author: cjplummer Date: 2012-11-09 09:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d9a84e246cce Merge ! src/share/vm/runtime/thread.cpp Changeset: 429994fc0754 Author: cjplummer Date: 2012-11-14 10:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/429994fc0754 Merge Changeset: 6bc207d87e5d Author: mgerdin Date: 2012-11-09 00:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6bc207d87e5d 7200229: NPG: possible performance issue exposed by closed/runtime/6559877/Test6559877.java Summary: Reduce the amount of calls to ChunkManager verification code Reviewed-by: jmasa, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: 0400886d2613 Author: coleenp Date: 2012-11-14 22:37 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/0400886d2613 8003259: NPG: Build with gcc 4.7.2 broken by 7045397 Summary: Qualify calls with this pointers to make gcc accept this code. Reviewed-by: coleenp, andrew Contributed-by: peter.levart at gmail.com ! src/share/vm/memory/binaryTreeDictionary.cpp Changeset: c5d4acbb943d Author: johnc Date: 2012-11-15 14:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/c5d4acbb943d Merge Changeset: 6b6ddf8c4329 Author: neliasso Date: 2012-11-16 09:59 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6b6ddf8c4329 Merge From david.r.chase at oracle.com Fri Nov 16 13:24:38 2012 From: david.r.chase at oracle.com (David Chase) Date: Fri, 16 Nov 2012 16:24:38 -0500 Subject: Request for reviews (XS): 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum Message-ID: <55D82646-02A6-4292-946C-7EAA2B57C1CE@oracle.com> Please review changes at http://cr.openjdk.java.net/~drchase/JDK-7146636/webrev.00/ Bug: A change in the minimum stack size on Solaris-sparc caused compiler/6865265/StackOverflowBug.java to fail to run; the run parameters specified a stack size too small for the VM to properly start. Fix: Increase the stack size in the run parameters. Testing: verified the failure first (specific to sparc+solaris). Applied fixes, the test now runs and passes. I went looking to see if there was a hardwired constant that should be tagged with a watch-out-if-you-change-it, but instead found Solaris::min_stack_allowed = MAX2(thr_min_stack(), Solaris::min_stack_allowed); ... os::Solaris::min_stack_allowed = MAX2(os::Solaris::min_stack_allowed, (size_t)(StackYellowPages+StackRedPages+StackShadowPages+ 2*BytesPerWord COMPILER2_PRESENT(+1)) * page_size); in hotspot/src/os/solaris/vm/os_solaris.cpp Thanks much, David From vladimir.x.ivanov at oracle.com Fri Nov 16 14:25:21 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 17 Nov 2012 01:25:21 +0300 Subject: How to reliably pin a node in CFG? In-Reply-To: <50A54F7B.3020402@oracle.com> References: <50A510F4.9060009@oracle.com> <50A54F7B.3020402@oracle.com> Message-ID: <50A6BD51.4080301@oracle.com> Vladimir K., Thanks, making depends_only_on_test == true for the load solves hoisting problem. Original problem still persist (the check is hoisted [1]), but that's another story - invariance analysis in PhaseIdealLoop::loop_predication_impl doesn't respect pinning we do. However, I wasn't able to figure out how to work with insert_mem_bar(Op_MemBarCPUOrder). How the graph should look like? It differs from volatile fields which produce multiple MemBar* nodes scattered around in the graph and other MemBarCPUOrderNode usages in library_call.cpp didn't give me any hint. If I issue it before the load [2], compilation fails during late scheduling [3]. I tried to issue it after the load in different places, but it didn't work (different assertions/compilation aborts during late scheduling). Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loadnode_depends_on_test_true_after.png Generated code: 056 B6: # B6 <- B5 B6 top-of-loop Freq: 1e-35 056 movl R8, [R10 + #28 (8-bit)] # int 05a testl rax, [rip + #offset_to_poll_page] # Safepoint: poll for GC # InterruptedVisibilityTest::think @ bci:4 L[0]=RBP STK[0]=R8 # OopMap{rbp=Oop off=90} 060 jmp,s B6 [2] http://cr.openjdk.java.net/~vlivanov/8003135/graphs/isInterrupted_membar_before.png [3] 1696 3 b java.lang.Thread::isInterrupted (6 bytes) COMPILE SKIPPED: late schedule failed: incorrect graph (not retryable) On 11/15/12 11:24 PM, Vladimir Kozlov wrote: > PhaseIdealLoop::dominated_by() and IfNode::dominated_by() are correct in > general case. The problem is value of depends_only_on_test(). This load > is from RAW memory and we should not hoist it. See comment in LoadPNode > class declaration. So we can widen the case to all loads - we have to > confirm this with John. > > An other simple way to fix it is to add membar before load since it is > volatile field: > > insert_mem_bar(Op_MemBarCPUOrder); > > Vladimir K. > > On 11/15/12 07:57, Vladimir Ivanov wrote: >> Hi, >> >> I'm looking at 8003135 [1] and the problem is that during null check >> (#132) hoisting, the load (#172) is also hoisted [2] [3]. LoadI node is >> constructed in LibraryCallKit::inline_native_isInterrupted >> and is pinned to IfTrue projection (#133) of #132, but it doesn't help. >> >> I'm not sure how to avoid the hoisting of the load. >> >> Should the load be pinned to corresponding Region/Loop node instead of >> If node? >> >> Is the logic in PhaseIdealLoop::dominated_by which updates >> control-dependent nodes (:242-:255)is correct? >> >> Best regards, >> Vladimir Ivanov >> >> [1] https://jbs.oracle.com/bugs/browse/JDK-8003135 >> "HotSpot inlines and hoists the Thread.currentThread().isInterrupted() >> out of the loop" >> >> [2] >> http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loop_invariant_hoisting_132_before.png >> >> >> >> [3] >> http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loop_invariant_hoisting_132_after.png >> >> From alejandro.murillo at oracle.com Fri Nov 16 13:35:51 2012 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 16 Nov 2012 21:35:51 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 15 new changesets Message-ID: <20121116213627.F2FEA47A1B@hg.openjdk.java.net> Changeset: 4e3e685dbc9d Author: katleman Date: 2012-11-15 15:39 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4e3e685dbc9d Added tag jdk8-b65 for changeset 0f7290a03b24 ! .hgtags Changeset: 64812523d72e Author: sspitsyn Date: 2012-10-31 16:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/64812523d72e 7194607: VerifyLocalVariableTableOnRetransformTest.sh fails after JSR-292 merge Summary: Use verifier_max_size instead of max_size to get code attribute max stack size. Reviewed-by: dcubed, minqi Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp Changeset: 8aaef2cee3b2 Author: minqi Date: 2012-11-08 16:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8aaef2cee3b2 Merge ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: ed8b1e39ff4f Author: zgu Date: 2012-11-09 11:04 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ed8b1e39ff4f 8002273: NMT to report JNI memory leaks when -Xcheck:jni is on Summary: Allows NMT to report that JNI thread failed to detach from JVM before exiting, which leaks the JavaThread object when check:jni option is on. Reviewed-by: acorn, dholmes, coleenp, ctornqvi ! src/share/vm/services/memSnapshot.cpp Changeset: 4efcd79826f2 Author: zgu Date: 2012-11-09 11:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/4efcd79826f2 Merge Changeset: fb3190e77d3c Author: zgu Date: 2012-11-09 19:24 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/fb3190e77d3c 8001592: NMT: assertion failed: assert(_amount >= amt) failed: Just check: memBaseline.hpp:180 Summary: Fixed NMT that miscounted arena memory when it is used as value or stack object. Reviewed-by: acorn, coleenp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTracker.hpp Changeset: e26ce0e8b666 Author: zgu Date: 2012-11-09 16:45 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e26ce0e8b666 Merge Changeset: 8c413497f434 Author: zgu Date: 2012-11-09 22:22 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8c413497f434 Merge ! src/share/vm/services/memSnapshot.cpp Changeset: e4f764ddb06a Author: hseigel Date: 2012-11-12 15:58 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e4f764ddb06a 7122219: Passed StringTableSize value not verified Summary: Check that the values specified for -XX:StringTableSize are within a certain range. Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 070d523b96a7 Author: hseigel Date: 2012-11-12 16:15 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/070d523b96a7 8001471: Klass::cast() does nothing Summary: Remove function Klass::cast() and calls to it. Reviewed-by: dholmes, coleenp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciType.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTrace.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/serviceUtil.hpp Changeset: 24e193d2a007 Author: coleenp Date: 2012-11-13 15:14 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/24e193d2a007 Merge Changeset: 80e866b1d053 Author: coleenp Date: 2012-11-16 09:19 -0500 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/80e866b1d053 Merge ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp Changeset: cfc5309f03b7 Author: amurillo Date: 2012-11-16 09:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cfc5309f03b7 Merge Changeset: 01684f7fee1b Author: amurillo Date: 2012-11-16 09:36 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/01684f7fee1b Added tag hs25-b10 for changeset cfc5309f03b7 ! .hgtags Changeset: e1d42ba865de Author: amurillo Date: 2012-11-16 09:43 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/e1d42ba865de 8003541: new hotspot build - hs25-b11 Reviewed-by: jcoomes ! make/hotspot_version From Vladimir.Kozlov at oracle.com Fri Nov 16 14:42:04 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Nov 2012 14:42:04 -0800 Subject: Request for reviews (XS): 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum In-Reply-To: <55D82646-02A6-4292-946C-7EAA2B57C1CE@oracle.com> References: <55D82646-02A6-4292-946C-7EAA2B57C1CE@oracle.com> Message-ID: <50A6C13C.6080908@oracle.com> Looks good. I will push it for you on Monday. Thanks, Vladimir On 11/16/12 13:24, David Chase wrote: > Please review changes at http://cr.openjdk.java.net/~drchase/JDK-7146636/webrev.00/ > > Bug: A change in the minimum stack size on Solaris-sparc caused compiler/6865265/StackOverflowBug.java to fail to run; the run parameters specified a stack size too small for the VM to properly start. > > Fix: Increase the stack size in the run parameters. > > Testing: verified the failure first (specific to sparc+solaris). Applied fixes, the test now runs and passes. > > > I went looking to see if there was a hardwired constant that should be tagged with a watch-out-if-you-change-it, but instead found > > Solaris::min_stack_allowed = MAX2(thr_min_stack(), Solaris::min_stack_allowed); > ... > os::Solaris::min_stack_allowed = MAX2(os::Solaris::min_stack_allowed, > (size_t)(StackYellowPages+StackRedPages+StackShadowPages+ > 2*BytesPerWord COMPILER2_PRESENT(+1)) * page_size); > > in hotspot/src/os/solaris/vm/os_solaris.cpp > > Thanks much, > > David > From Vladimir.Kozlov at oracle.com Fri Nov 16 14:58:59 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Nov 2012 14:58:59 -0800 Subject: How to reliably pin a node in CFG? In-Reply-To: <50A6BD51.4080301@oracle.com> References: <50A510F4.9060009@oracle.com> <50A54F7B.3020402@oracle.com> <50A6BD51.4080301@oracle.com> Message-ID: <50A6C533.1090009@oracle.com> On 11/16/12 14:25, Vladimir Ivanov wrote: > Vladimir K., > > Thanks, making depends_only_on_test == true for the load solves hoisting > problem. > > Original problem still persist (the check is hoisted [1]), but that's > another story - invariance analysis in > PhaseIdealLoop::loop_predication_impl doesn't respect pinning we do. loop_predication moves checks before the loop. In you case it is after. So it is something else. > > However, I wasn't able to figure out how to work with > insert_mem_bar(Op_MemBarCPUOrder). How the graph should look like? membar has 2 projections (ProjNode): control and memory. Load should points to both of them. In your graph only control edge of Load is membar projection. Vladimir > > It differs from volatile fields which produce multiple MemBar* nodes > scattered around in the graph and other MemBarCPUOrderNode usages in > library_call.cpp didn't give me any hint. > > If I issue it before the load [2], compilation fails during late > scheduling [3]. I tried to issue it after the load in different places, > but it didn't work (different assertions/compilation aborts during late > scheduling). > > Best regards, > Vladimir Ivanov > > [1] > http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loadnode_depends_on_test_true_after.png > > > Generated code: > 056 B6: # B6 <- B5 B6 top-of-loop Freq: 1e-35 > 056 movl R8, [R10 + #28 (8-bit)] # int > 05a testl rax, [rip + #offset_to_poll_page] # Safepoint: poll for GC # > InterruptedVisibilityTest::think @ bci:4 L[0]=RBP STK[0]=R8 > # OopMap{rbp=Oop off=90} > 060 jmp,s B6 > > [2] > http://cr.openjdk.java.net/~vlivanov/8003135/graphs/isInterrupted_membar_before.png > > > [3] 1696 3 b java.lang.Thread::isInterrupted (6 bytes) COMPILE SKIPPED: > late schedule failed: incorrect graph (not retryable) > > On 11/15/12 11:24 PM, Vladimir Kozlov wrote: >> PhaseIdealLoop::dominated_by() and IfNode::dominated_by() are correct in >> general case. The problem is value of depends_only_on_test(). This load >> is from RAW memory and we should not hoist it. See comment in LoadPNode >> class declaration. So we can widen the case to all loads - we have to >> confirm this with John. >> >> An other simple way to fix it is to add membar before load since it is >> volatile field: >> >> insert_mem_bar(Op_MemBarCPUOrder); >> >> Vladimir K. >> >> On 11/15/12 07:57, Vladimir Ivanov wrote: >>> Hi, >>> >>> I'm looking at 8003135 [1] and the problem is that during null check >>> (#132) hoisting, the load (#172) is also hoisted [2] [3]. LoadI node is >>> constructed in LibraryCallKit::inline_native_isInterrupted >>> and is pinned to IfTrue projection (#133) of #132, but it doesn't help. >>> >>> I'm not sure how to avoid the hoisting of the load. >>> >>> Should the load be pinned to corresponding Region/Loop node instead of >>> If node? >>> >>> Is the logic in PhaseIdealLoop::dominated_by which updates >>> control-dependent nodes (:242-:255)is correct? >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] https://jbs.oracle.com/bugs/browse/JDK-8003135 >>> "HotSpot inlines and hoists the Thread.currentThread().isInterrupted() >>> out of the loop" >>> >>> [2] >>> http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loop_invariant_hoisting_132_before.png >>> >>> >>> >>> >>> [3] >>> http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loop_invariant_hoisting_132_after.png >>> >>> >>> From vladimir.kozlov at oracle.com Fri Nov 16 17:48:48 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Sat, 17 Nov 2012 01:48:48 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum Message-ID: <20121117014850.7E99947A20@hg.openjdk.java.net> Changeset: 7cc69864a29b Author: kvn Date: 2012-11-16 15:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7cc69864a29b 7146636: compiler/6865265/StackOverflowBug.java fails due to changed stack minimum Summary: Increase the stack size in the run parameters. Reviewed-by: kvn Contributed-by: david.r.chase at oracle.com ! test/compiler/6865265/StackOverflowBug.java From christian.thalinger at oracle.com Mon Nov 19 10:09:18 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 Nov 2012 10:09:18 -0800 Subject: RFR (S) 8001538: hs_err file does not list anymore compiled methods in compilation events In-Reply-To: <50A52773.8040208@oracle.com> References: <50A26CF2.10505@oracle.com> <3F7665E3-3C59-475E-837D-242213CE7619@oracle.com> <50A52773.8040208@oracle.com> Message-ID: Looks good. -- Chris On Nov 15, 2012, at 9:33 AM, Vladimir Ivanov wrote: > Vladimir K., Chris, thank you for the review. > > Yes, it restores original compilation events format [1] > > I verified that it's safe to use objects from resource area for logging: event logger copies message content into internal buffer. > > Updated webrev: > http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/ > > Best regards, > Vladimir Ivanov > > [1] http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/hs_err_pid87677.log > > On 11/13/12 7:41 PM, Vladimir Kozlov wrote: >> Very nice fix, Vladimir I., thank you >> >> To confirm, the size fix restored methods names in compilation events. Right? >> >> You moved deoptimization event logging under resourceMark, make sure the logging code does not use resource area or copied from it to safe place. >> >> Thanks, >> Vladimir >> >> On Nov 13, 2012, at 7:53 AM, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~vlivanov/8001538/webrev.00/ >>> >>> Due to incorrect message buffer size calculation, a message may be truncated to 4/8 characters. >>> >>> Also, changed how deoptimization events are logged: >>> - moved [1] from "Deoptimization events" to "Events" section. >>> - added [2] to "Deoptimization events" section >>> >>> Sample output from a hs_err file: >>> Deoptimization events (2 events): >>> Event: 3.438 Thread 0x0000000103804800 Uncommon trap: Test::f @ 23, reason: unloaded, action: reinterpret >>> Event: 3.482 Thread 0x0000000103804800 Uncommon trap: Test::main @ 38, reason: unloaded, action: reinterpret >>> >>> Internal exceptions (10 events): >>> ... >>> >>> Events (10 events): >>> Event: 3.441 Thread 0x0000000103804800 DEOPT UNPACKING pc=0x00000001046cf214 sp=0x0000000100700548 mode 2 >>> Event: 3.482 Thread 0x0000000103804800 Uncommon trap 3 fr.pc 0x00000001046ffe1c >>> ... >>> >>> Testing: JPRT, simple test w/ deopt events in the log. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] Uncommon trap 3 fr.pc 0x00000001046ffe1c >>> [2] Uncommon trap: Test::f @ 23, reason=unloaded action=reinterpret >> From vladimir.x.ivanov at oracle.com Mon Nov 19 11:14:46 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 19 Nov 2012 22:14:46 +0300 Subject: RFR (S) 8001538: hs_err file does not list anymore compiled methods in compilation events In-Reply-To: References: <50A26CF2.10505@oracle.com> <3F7665E3-3C59-475E-837D-242213CE7619@oracle.com> <50A52773.8040208@oracle.com> Message-ID: <50AA8526.90605@oracle.com> Vladimir K., Chis, thanks. Best regards, Vladimir Ivanov On 11/19/12 9:09 PM, Christian Thalinger wrote: > Looks good. -- Chris > > On Nov 15, 2012, at 9:33 AM, Vladimir Ivanov wrote: > >> Vladimir K., Chris, thank you for the review. >> >> Yes, it restores original compilation events format [1] >> >> I verified that it's safe to use objects from resource area for logging: event logger copies message content into internal buffer. >> >> Updated webrev: >> http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/ >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/hs_err_pid87677.log >> >> On 11/13/12 7:41 PM, Vladimir Kozlov wrote: >>> Very nice fix, Vladimir I., thank you >>> >>> To confirm, the size fix restored methods names in compilation events. Right? >>> >>> You moved deoptimization event logging under resourceMark, make sure the logging code does not use resource area or copied from it to safe place. >>> >>> Thanks, >>> Vladimir >>> >>> On Nov 13, 2012, at 7:53 AM, Vladimir Ivanov wrote: >>> >>>> http://cr.openjdk.java.net/~vlivanov/8001538/webrev.00/ >>>> >>>> Due to incorrect message buffer size calculation, a message may be truncated to 4/8 characters. >>>> >>>> Also, changed how deoptimization events are logged: >>>> - moved [1] from "Deoptimization events" to "Events" section. >>>> - added [2] to "Deoptimization events" section >>>> >>>> Sample output from a hs_err file: >>>> Deoptimization events (2 events): >>>> Event: 3.438 Thread 0x0000000103804800 Uncommon trap: Test::f @ 23, reason: unloaded, action: reinterpret >>>> Event: 3.482 Thread 0x0000000103804800 Uncommon trap: Test::main @ 38, reason: unloaded, action: reinterpret >>>> >>>> Internal exceptions (10 events): >>>> ... >>>> >>>> Events (10 events): >>>> Event: 3.441 Thread 0x0000000103804800 DEOPT UNPACKING pc=0x00000001046cf214 sp=0x0000000100700548 mode 2 >>>> Event: 3.482 Thread 0x0000000103804800 Uncommon trap 3 fr.pc 0x00000001046ffe1c >>>> ... >>>> >>>> Testing: JPRT, simple test w/ deopt events in the log. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] Uncommon trap 3 fr.pc 0x00000001046ffe1c >>>> [2] Uncommon trap: Test::f @ 23, reason=unloaded action=reinterpret >>> > From christian.thalinger at oracle.com Mon Nov 19 11:04:26 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 Nov 2012 11:04:26 -0800 Subject: RFR(S) 8001077: remove ciMethod::will_link In-Reply-To: <50A305A3.2060606@oracle.com> References: <50A305A3.2060606@oracle.com> Message-ID: <278337ED-002E-4C8E-98EC-6EE4202C0E29@oracle.com> I know it's pushed already but in Parse::can_not_compile_call_site we could have removed the klass argument since it's not used anymore. -- Chris On Nov 13, 2012, at 6:44 PM, Bharadwaj Yadavalli wrote: > > Trivial cleanup - http://cr.openjdk.java.net/~bharadwaj/8001077/webrev/ > > ciMethod::will_link actually returns is_loaded. A comment in the method states: > > // The link checks have been front-loaded into the get_method > // call. This method (ciMethod::will_link()) will be removed > // in the future. > > This comment is there since the duke:0 changeset. > > Removed will_link and changed all calls to is_loaded(). From christian.thalinger at oracle.com Mon Nov 19 11:17:59 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 Nov 2012 11:17:59 -0800 Subject: looking for workloads impacted by OptimizeStringConcat In-Reply-To: References: Message-ID: <0844E150-45BA-44C6-941C-9B6007657135@oracle.com> On Nov 14, 2012, at 10:54 AM, xiaoming gu wrote: > Could anyone point out one or more workloads in DaCapo or SPECjvm showing consistent improvement with -XX:+OptimizeStringConcat? (I know this optimization has become default. Actually I'm looking for workloads showing slowdown with -XX:-OptimizeStringConcat.) I think you should just do some test runs yourself. Use +PrintOptimizeStringConcat to see what's happening. -- Chris > > Thanks. > > -Xiaoming From bharadwaj.yadavalli at oracle.com Mon Nov 19 12:14:17 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Mon, 19 Nov 2012 15:14:17 -0500 Subject: RFR(S) 8001077: remove ciMethod::will_link In-Reply-To: <278337ED-002E-4C8E-98EC-6EE4202C0E29@oracle.com> References: <50A305A3.2060606@oracle.com> <278337ED-002E-4C8E-98EC-6EE4202C0E29@oracle.com> Message-ID: <50AA9319.3030804@oracle.com> Yes. Will fold the change into my next changeset (if no one else makes the change by then). Thanks for catching it. Bharadwaj On 11/19/2012 2:04 PM, Christian Thalinger wrote: > I know it's pushed already but in Parse::can_not_compile_call_site we could have removed the klass argument since it's not used anymore. > > -- Chris > > On Nov 13, 2012, at 6:44 PM, Bharadwaj Yadavalli wrote: > >> Trivial cleanup - http://cr.openjdk.java.net/~bharadwaj/8001077/webrev/ >> >> ciMethod::will_link actually returns is_loaded. A comment in the method states: >> >> // The link checks have been front-loaded into the get_method >> // call. This method (ciMethod::will_link()) will be removed >> // in the future. >> >> This comment is there since the duke:0 changeset. >> >> Removed will_link and changed all calls to is_loaded(). From goetz.lindenmaier at sap.com Tue Nov 20 02:05:48 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 20 Nov 2012 11:05:48 +0100 Subject: RFR (S): Issue constants to constant pool in stub code Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> Hi, When adding constants to the constant pool, the code_section is switched to the constant pool code_section, and then back again. It was hard coded to switch back to the code_section for code. If constants are issued in stubs, it is switched back to the wrong code section. I changed the code to remember the code section and switch back to the proper one. Further it's necessary to relocate only after copying code and stub section to a new location, as the relocation might affect an address in the stub section. You can find these changes here: http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/ or in our ppc port: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062 Thank you and best regards, Goetz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121120/309b4366/attachment.html From goetz.lindenmaier at sap.com Tue Nov 20 03:08:25 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 20 Nov 2012 12:08:25 +0100 Subject: RFR (S): Specify offset of IC load in java_to_interp stub. Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF6672CB3@DEWDFECCR03.wdf.sap.corp> Hi, The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub to update the IC with NativeMovConstReg. The current implementation assumes that the load is always the first instruction in the stub. This is an artificial restriction. E.g., it might be useful to load the constant pool address (MachConstantBase) before the IC load (as we do on PPC). This change adds a constant specifying an offset from the beginning of the stub to the IC load. The offset is platform specific and 0 on sparc and x86. You can find the change here: http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/ or in our ppc port: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 Thank you and best regards, Goetz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121120/2ba4e359/attachment.html From vladimir.x.ivanov at oracle.com Tue Nov 20 04:19:34 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 20 Nov 2012 15:19:34 +0300 Subject: RFR (S): Issue constants to constant pool in stub code In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> Message-ID: <50AB7556.90603@oracle.com> Goetz, +// Inform CodeBuffer that incoming code and relocation will be code +// Should not be called if start_a_const() returned NULL +void AbstractAssembler::end_a_const() { + end_a_const(code()->insts()); +} Don't you want to add an assert to check that start_a_const() != NULL? Best regards, Vladimir Ivanov On 11/20/12 1:05 PM, Lindenmaier, Goetz wrote: > Hi, > > When adding constants to the constant pool, the code_section is switched > > to the constant pool code_section, and then back again. It was hard coded > > to switch back to the code_section for code. > > If constants are issued in stubs, it is switched back to the wrong code > section. > > I changed the code to remember the code section and switch back to the > proper > > one. > > Further it?s necessary to relocate only after copying code and stub > section to > > a new location, as the relocation might affect an address in the stub > section. > > You can find these changes here: > > http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/ > > or in our ppc port: > > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062 > > Thank you and best regards, > > Goetz > From goetz.lindenmaier at sap.com Tue Nov 20 04:05:21 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 20 Nov 2012 13:05:21 +0100 Subject: RFR (S): Issue constants to constant pool in stub code In-Reply-To: <50AB7556.90603@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> <50AB7556.90603@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF6672DAA@DEWDFECCR03.wdf.sap.corp> Hi Vladimir, That's the original comment, it only moved down. I understand it as hint for the user of this method. It's not necessary for the new method, as one could reset the cs to NULL. All callers of end_a_const() currently check the result of the previous start_a_const() call, so there no assertion is needed. Best regards, Goetz -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Dienstag, 20. November 2012 13:20 To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): Issue constants to constant pool in stub code Goetz, +// Inform CodeBuffer that incoming code and relocation will be code +// Should not be called if start_a_const() returned NULL +void AbstractAssembler::end_a_const() { + end_a_const(code()->insts()); +} Don't you want to add an assert to check that start_a_const() != NULL? Best regards, Vladimir Ivanov On 11/20/12 1:05 PM, Lindenmaier, Goetz wrote: > Hi, > > When adding constants to the constant pool, the code_section is switched > > to the constant pool code_section, and then back again. It was hard coded > > to switch back to the code_section for code. > > If constants are issued in stubs, it is switched back to the wrong code > section. > > I changed the code to remember the code section and switch back to the > proper > > one. > > Further it's necessary to relocate only after copying code and stub > section to > > a new location, as the relocation might affect an address in the stub > section. > > You can find these changes here: > > http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/ > > or in our ppc port: > > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062 > > Thank you and best regards, > > Goetz > From vladimir.x.ivanov at oracle.com Tue Nov 20 05:45:26 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 20 Nov 2012 16:45:26 +0300 Subject: How to reliably pin a node in CFG? In-Reply-To: <50A6C533.1090009@oracle.com> References: <50A510F4.9060009@oracle.com> <50A54F7B.3020402@oracle.com> <50A6BD51.4080301@oracle.com> <50A6C533.1090009@oracle.com> Message-ID: <50AB8976.6000004@oracle.com> >> Original problem still persist (the check is hoisted [1]), but that's >> another story - invariance analysis in >> PhaseIdealLoop::loop_predication_impl doesn't respect pinning we do. > > loop_predication moves checks before the loop. In you case it is after. So it is something else. Actually, it does move the check before the loop. The reason why invariance analysis concludes that the load is invariant is because of control node (IfTrue(#133)/If(#132)) the load depends on is marked as invariant. It occurs on a previous iteration when IfNode/#132 was predicated and became #211 (old nodes are marked as invariant in Invariance::map_ctrl called from PhaseIdealLoop::loop_predication_impl). >> >> However, I wasn't able to figure out how to work with >> insert_mem_bar(Op_MemBarCPUOrder). How the graph should look like? > > membar has 2 projections (ProjNode): control and memory. Load should > points to both of them. In your graph only control edge of Load is > membar projection. I double-checked and Load actually has both projections [1]. Any other evident mismatch in the graph? I'm debugging the code which does late scheduling but haven't found the root cause yet. Just in case: the patch [2] and the test [3] I use. Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/8003135/graphs/isInterruped_with_membar.png [2] diff --git a/src/share/vm/opto/library_call.cpp b/src/share/vm/opto/library_call.cpp --- a/src/share/vm/opto/library_call.cpp +++ b/src/share/vm/opto/library_call.cpp @@ -3250,6 +3250,9 @@ Node* p = basic_plus_adr(top()/*!oop*/, tls_ptr, in_bytes(JavaThread::osthread_offset())); Node* osthread = make_load(NULL, p, TypeRawPtr::NOTNULL, T_ADDRESS); p = basic_plus_adr(top()/*!oop*/, osthread, in_bytes(OSThread::interrupted_offset())); + + insert_mem_bar(Op_MemBarCPUOrder); + // Set the control input on the field _interrupted read to prevent it floating up. Node* int_bit = make_load(control(), p, TypeInt::BOOL, T_INT); Node* cmp_bit = _gvn.transform( new (C) CmpINode(int_bit, intcon(0)) ); [3] InterruptedVisibilityTest.java public class InterruptedVisibilityTest { public void think() { while (true) { if (checkInterruptedStatus()) break; } System.out.println("We're done thinking"); } private boolean checkInterruptedStatus() { return Thread.currentThread().isInterrupted(); } public static void main(String[] args) throws InterruptedException { final InterruptedVisibilityTest test = new InterruptedVisibilityTest(); test.think(); } } On 11/17/12 1:58 AM, Vladimir Kozlov wrote: > On 11/16/12 14:25, Vladimir Ivanov wrote: >> Vladimir K., >> >> Thanks, making depends_only_on_test == true for the load solves hoisting >> problem. >> >> Original problem still persist (the check is hoisted [1]), but that's >> another story - invariance analysis in >> PhaseIdealLoop::loop_predication_impl doesn't respect pinning we do. > > loop_predication moves checks before the loop. In you case it is after. > So it is something else. > >> >> However, I wasn't able to figure out how to work with >> insert_mem_bar(Op_MemBarCPUOrder). How the graph should look like? > > membar has 2 projections (ProjNode): control and memory. Load should > points to both of them. In your graph only control edge of Load is > membar projection. > > Vladimir > >> >> It differs from volatile fields which produce multiple MemBar* nodes >> scattered around in the graph and other MemBarCPUOrderNode usages in >> library_call.cpp didn't give me any hint. >> >> If I issue it before the load [2], compilation fails during late >> scheduling [3]. I tried to issue it after the load in different places, >> but it didn't work (different assertions/compilation aborts during late >> scheduling). >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loadnode_depends_on_test_true_after.png >> >> >> >> Generated code: >> 056 B6: # B6 <- B5 B6 top-of-loop Freq: 1e-35 >> 056 movl R8, [R10 + #28 (8-bit)] # int >> 05a testl rax, [rip + #offset_to_poll_page] # Safepoint: poll for GC # >> InterruptedVisibilityTest::think @ bci:4 L[0]=RBP STK[0]=R8 >> # OopMap{rbp=Oop off=90} >> 060 jmp,s B6 >> >> [2] >> http://cr.openjdk.java.net/~vlivanov/8003135/graphs/isInterrupted_membar_before.png >> >> >> >> [3] 1696 3 b java.lang.Thread::isInterrupted (6 bytes) COMPILE SKIPPED: >> late schedule failed: incorrect graph (not retryable) >> >> On 11/15/12 11:24 PM, Vladimir Kozlov wrote: >>> PhaseIdealLoop::dominated_by() and IfNode::dominated_by() are correct in >>> general case. The problem is value of depends_only_on_test(). This load >>> is from RAW memory and we should not hoist it. See comment in LoadPNode >>> class declaration. So we can widen the case to all loads - we have to >>> confirm this with John. >>> >>> An other simple way to fix it is to add membar before load since it is >>> volatile field: >>> >>> insert_mem_bar(Op_MemBarCPUOrder); >>> >>> Vladimir K. >>> >>> On 11/15/12 07:57, Vladimir Ivanov wrote: >>>> Hi, >>>> >>>> I'm looking at 8003135 [1] and the problem is that during null check >>>> (#132) hoisting, the load (#172) is also hoisted [2] [3]. LoadI node is >>>> constructed in LibraryCallKit::inline_native_isInterrupted >>>> and is pinned to IfTrue projection (#133) of #132, but it doesn't help. >>>> >>>> I'm not sure how to avoid the hoisting of the load. >>>> >>>> Should the load be pinned to corresponding Region/Loop node instead of >>>> If node? >>>> >>>> Is the logic in PhaseIdealLoop::dominated_by which updates >>>> control-dependent nodes (:242-:255)is correct? >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] https://jbs.oracle.com/bugs/browse/JDK-8003135 >>>> "HotSpot inlines and hoists the Thread.currentThread().isInterrupted() >>>> out of the loop" >>>> >>>> [2] >>>> http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loop_invariant_hoisting_132_before.png >>>> >>>> >>>> >>>> >>>> >>>> [3] >>>> http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loop_invariant_hoisting_132_after.png >>>> >>>> >>>> >>>> From vitalyd at gmail.com Tue Nov 20 04:49:30 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 20 Nov 2012 07:49:30 -0500 Subject: RFR (S): Issue constants to constant pool in stub code In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> Message-ID: Hi Goetz, I think the assert message in assembler.cpp (line 107) needs adjustment since cs can also be stubs now. Thanks Sent from my phone On Nov 20, 2012 5:07 AM, "Lindenmaier, Goetz" wrote: > Hi,**** > > ** ** > > When adding constants to the constant pool, the code_section is switched** > ** > > to the constant pool code_section, and then back again. It was hard coded > **** > > to switch back to the code_section for code.**** > > If constants are issued in stubs, it is switched back to the wrong code > section.**** > > I changed the code to remember the code section and switch back to the > proper**** > > one. **** > > Further it?s necessary to relocate only after copying code and stub > section to **** > > a new location, as the relocation might affect an address in the stub > section.**** > > ** ** > > You can find these changes here:**** > > http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/**** > > ** ** > > or in our ppc port:**** > > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062**** > > ** ** > > Thank you and best regards, **** > > Goetz**** > > ** ** > > ** ** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121120/45b732c1/attachment.html From goetz.lindenmaier at sap.com Tue Nov 20 05:33:40 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 20 Nov 2012 14:33:40 +0100 Subject: RFR (S): Issue constants to constant pool in stub code In-Reply-To: References: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF6672F3A@DEWDFECCR03.wdf.sap.corp> Hi Vitaly, What about "not in code?" Thanks, Goetz. From: Vitaly Davidovich [mailto:vitalyd at gmail.com] Sent: Dienstag, 20. November 2012 13:50 To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): Issue constants to constant pool in stub code Hi Goetz, I think the assert message in assembler.cpp (line 107) needs adjustment since cs can also be stubs now. Thanks Sent from my phone On Nov 20, 2012 5:07 AM, "Lindenmaier, Goetz" > wrote: Hi, When adding constants to the constant pool, the code_section is switched to the constant pool code_section, and then back again. It was hard coded to switch back to the code_section for code. If constants are issued in stubs, it is switched back to the wrong code section. I changed the code to remember the code section and switch back to the proper one. Further it's necessary to relocate only after copying code and stub section to a new location, as the relocation might affect an address in the stub section. You can find these changes here: http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/ or in our ppc port: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062 Thank you and best regards, Goetz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121120/d8093ef7/attachment.html From vitalyd at gmail.com Tue Nov 20 05:36:30 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 20 Nov 2012 08:36:30 -0500 Subject: RFR (S): Issue constants to constant pool in stub code In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF6672F3A@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6672F3A@DEWDFECCR03.wdf.sap.corp> Message-ID: That works. I was thinking even simpler: "not in insts/stubs?" :) Sent from my phone On Nov 20, 2012 8:33 AM, "Lindenmaier, Goetz" wrote: > Hi Vitaly,**** > > ** ** > > What about ?not in code??**** > > ** ** > > Thanks,**** > > Goetz.**** > > ** ** > > ** ** > > *From:* Vitaly Davidovich [mailto:vitalyd at gmail.com] > *Sent:* Dienstag, 20. November 2012 13:50 > *To:* Lindenmaier, Goetz > *Cc:* hotspot-compiler-dev at openjdk.java.net > *Subject:* Re: RFR (S): Issue constants to constant pool in stub code**** > > ** ** > > Hi Goetz,**** > > I think the assert message in assembler.cpp (line 107) needs adjustment > since cs can also be stubs now.**** > > Thanks**** > > Sent from my phone**** > > On Nov 20, 2012 5:07 AM, "Lindenmaier, Goetz" > wrote:**** > > Hi,**** > > **** > > When adding constants to the constant pool, the code_section is switched** > ** > > to the constant pool code_section, and then back again. It was hard coded > **** > > to switch back to the code_section for code.**** > > If constants are issued in stubs, it is switched back to the wrong code > section.**** > > I changed the code to remember the code section and switch back to the > proper**** > > one. **** > > Further it?s necessary to relocate only after copying code and stub > section to **** > > a new location, as the relocation might affect an address in the stub > section.**** > > **** > > You can find these changes here:**** > > http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/**** > > **** > > or in our ppc port:**** > > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062**** > > **** > > Thank you and best regards, **** > > Goetz**** > > **** > > **** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121120/4551b79b/attachment.html From goetz.lindenmaier at sap.com Tue Nov 20 05:45:30 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 20 Nov 2012 14:45:30 +0100 Subject: RFR (S): Issue constants to constant pool in stub code In-Reply-To: References: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6672F3A@DEWDFECCR03.wdf.sap.corp> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF6672F72@DEWDFECCR03.wdf.sap.corp> Done! From: Vitaly Davidovich [mailto:vitalyd at gmail.com] Sent: Dienstag, 20. November 2012 14:37 To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net Subject: RE: RFR (S): Issue constants to constant pool in stub code That works. I was thinking even simpler: "not in insts/stubs?" :) Sent from my phone On Nov 20, 2012 8:33 AM, "Lindenmaier, Goetz" > wrote: Hi Vitaly, What about "not in code?" Thanks, Goetz. From: Vitaly Davidovich [mailto:vitalyd at gmail.com] Sent: Dienstag, 20. November 2012 13:50 To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): Issue constants to constant pool in stub code Hi Goetz, I think the assert message in assembler.cpp (line 107) needs adjustment since cs can also be stubs now. Thanks Sent from my phone On Nov 20, 2012 5:07 AM, "Lindenmaier, Goetz" > wrote: Hi, When adding constants to the constant pool, the code_section is switched to the constant pool code_section, and then back again. It was hard coded to switch back to the code_section for code. If constants are issued in stubs, it is switched back to the wrong code section. I changed the code to remember the code section and switch back to the proper one. Further it's necessary to relocate only after copying code and stub section to a new location, as the relocation might affect an address in the stub section. You can find these changes here: http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/ or in our ppc port: http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062 Thank you and best regards, Goetz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121120/1d86fdd9/attachment-0001.html From bharadwaj.yadavalli at oracle.com Tue Nov 20 11:39:21 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Tue, 20 Nov 2012 14:39:21 -0500 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <509D3EE3.303@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> <509D3EE3.303@oracle.com> Message-ID: <50ABDC69.8050604@oracle.com> Please review the updated webrev at http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ Hopefully I have addressed all the review comments/suggestions. Thanks, Bharadwaj On 11/9/2012 12:35 PM, Vladimir Kozlov wrote: > Bharadwaj, > > Nils just reminded me (for his changes) that you need to fix our > LogCompilation parsing tool to recognize new "unique='n' > live_tracked='n'" values (old was "nodes='n'"): > > src/share/tools/LogCompilation/ > > Also live_tracked could be simple "live". > > Thanks, > Vladimir > > Vladimir Kozlov wrote: >> VerifyIdealNodeCount flag should be also notproduct since it is used >> only in debug VM. >> >> The next assert is not needed because it duplicates assert in >> live_nodes(): >> >> bool check_node_count(uint margin, const char* reason) { >> if (unique() + margin > (uint)MaxNodeLimit) { >> + assert(dead_node_count() <= unique(), "number of dead nodes >> more than created"); >> >> Also don't split the assert in live_nodes() into 2 lines and maybe >> use err_msg_res() to print _unique and _dead_node_count values. Also >> I think it should return unsigned int type value as unique() method. >> >> Second Compile() constructor does not set _dead_node_count(0). >> >> count_live_nodes_by_graph_walk() and NotANode() methods are now used >> only in debug code so put them under #ifdef ASSERT. >> >> >> print_missing_nodes() should call count_live_nodes_by_graph_walk() >> instead of duplicating code. And it should print to _log itself. >> TracePhase() code will have only call to it: >> >> 3133 if (VerifyIdealNodeCount) { >> 3134 Compile::current()->print_missing_nodes(); >> 3135 } >> >> And do not check VerifyIdealNodeCount in print_missing_nodes() to >> allow call it in debugger without VerifyIdealNodeCount set. >> >> I think VerifyIdealNodeCount code should be in ~TracePhase() (end of >> phase). >> >> Thanks, >> Vladimir >> >> Bharadwaj Yadavalli wrote: >>> Addressed comments on my previous RFR. Changes at >>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_02/ >>> >>> These changes are made to keep an (almost) accurate running count of >>> the reachable (live) flow graph nodes. This will result in a more >>> realistic node count for various phases of C2 to decide on whether >>> to proceed with optimizations or not. Prior to these changes, C2 >>> bails out of compilation based on the number of nodes created which >>> typically larger than the number of reachable (live) nodes. >>> From Vladimir.Kozlov at oracle.com Tue Nov 20 12:26:47 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Nov 2012 12:26:47 -0800 Subject: How to reliably pin a node in CFG? In-Reply-To: <50AB8976.6000004@oracle.com> References: <50A510F4.9060009@oracle.com> <50A54F7B.3020402@oracle.com> <50A6BD51.4080301@oracle.com> <50A6C533.1090009@oracle.com> <50AB8976.6000004@oracle.com> Message-ID: <50ABE787.8090802@oracle.com> The problem is that we need to reset memory for the call otherwise it use memory proj of membar on an OTHER code branch: 40 MemBarCPUOrder === 34 1 7 1 1 [[ 41 42 ]] !jvms: Thread::isInterrupted @ bci:2 41 Proj === 40 [[ 47 44 ]] #0 !jvms: Thread::isInterrupted @ bci:2 42 Proj === 40 [[ 70 44 56 70 ]] #2 Memory: @BotPTR *+bot, idx=Bot; !jvms: Thread::isInterrupted @ bci:2 56 CallStaticJava === 33 6 42 8 1 ( 10 22 1 ) [[ 57 58 59 61 ]] # Static java.lang.Thread::isInterrupted bool ( java/lang/Thread:NotNull *, bool ) Thread::isInterrupted @ bci:2 !jvms: Thread::isInterrupted @ bci:2 Something like following patch but I don't like it. Look on other similar code and find better solution. Thanks, Vladimir src/share/vm/opto/library_call.cpp Tue Nov 20 12:22:58 2012 -0800 @@ -3147,7 +3147,12 @@ Node* p = basic_plus_adr(top()/*!oop*/, tls_ptr, in_bytes(JavaThread::osthread_offset())); Node* osthread = make_load(NULL, p, TypeRawPtr::NOTNULL, T_ADDRESS); p = basic_plus_adr(top()/*!oop*/, osthread, in_bytes(OSThread::interrupted_offset())); + // Set the control input on the field _interrupted read to prevent it floating up. + Node* init_mem = map()->memory(); + insert_mem_bar(Op_MemBarCPUOrder); + Node* fast_mem = map()->memory(); + Node* int_bit = make_load(control(), p, TypeInt::BOOL, T_INT); Node* cmp_bit = _gvn.transform( new (C) CmpINode(int_bit, intcon(0)) ); Node* bol_bit = _gvn.transform( new (C) BoolNode(cmp_bit, BoolTest::ne) ); @@ -3186,6 +3191,7 @@ result_val->init_req(slow_result_path, top()); } else { // non-virtual because it is a private non-static + set_all_memory(init_mem); CallJavaNode* slow_call = generate_method_call(vmIntrinsics::_isInterrupted); Node* slow_val = set_results_for_java_call(slow_call); @@ -3195,7 +3201,6 @@ if (known_current_thread) slow_val = intcon(1); Node* fast_io = slow_call->in(TypeFunc::I_O); - Node* fast_mem = slow_call->in(TypeFunc::Memory); // These two phis are pre-filled with copies of of the fast IO and Memory Node* io_phi = PhiNode::make(result_rgn, fast_io, Type::ABIO); Node* mem_phi = PhiNode::make(result_rgn, fast_mem, Type::MEMORY, TypePtr::BOTTOM); On 11/20/12 05:45, Vladimir Ivanov wrote: > >> Original problem still persist (the check is hoisted [1]), but that's > >> another story - invariance analysis in > >> PhaseIdealLoop::loop_predication_impl doesn't respect pinning we do. > > > > loop_predication moves checks before the loop. In you case it is > after. So it is something else. > Actually, it does move the check before the loop. The reason why > invariance analysis concludes that the load is invariant is because of > control node (IfTrue(#133)/If(#132)) the load depends on is marked as > invariant. It occurs on a previous iteration when IfNode/#132 was > predicated and became #211 (old nodes are marked as invariant in > Invariance::map_ctrl called from PhaseIdealLoop::loop_predication_impl). > > >> > >> However, I wasn't able to figure out how to work with > >> insert_mem_bar(Op_MemBarCPUOrder). How the graph should look like? > > > > membar has 2 projections (ProjNode): control and memory. Load should > > points to both of them. In your graph only control edge of Load is > > membar projection. > I double-checked and Load actually has both projections [1]. Any other > evident mismatch in the graph? I'm debugging the code which does late > scheduling but haven't found the root cause yet. > > Just in case: the patch [2] and the test [3] I use. > > Best regards, > Vladimir Ivanov > > [1] > http://cr.openjdk.java.net/~vlivanov/8003135/graphs/isInterruped_with_membar.png > > > [2] diff --git a/src/share/vm/opto/library_call.cpp > b/src/share/vm/opto/library_call.cpp > --- a/src/share/vm/opto/library_call.cpp > +++ b/src/share/vm/opto/library_call.cpp > @@ -3250,6 +3250,9 @@ > Node* p = basic_plus_adr(top()/*!oop*/, tls_ptr, > in_bytes(JavaThread::osthread_offset())); > Node* osthread = make_load(NULL, p, TypeRawPtr::NOTNULL, T_ADDRESS); > p = basic_plus_adr(top()/*!oop*/, osthread, > in_bytes(OSThread::interrupted_offset())); > + > + insert_mem_bar(Op_MemBarCPUOrder); > + > // Set the control input on the field _interrupted read to prevent it > floating up. > Node* int_bit = make_load(control(), p, TypeInt::BOOL, T_INT); > Node* cmp_bit = _gvn.transform( new (C) CmpINode(int_bit, intcon(0)) ); > > [3] InterruptedVisibilityTest.java > public class InterruptedVisibilityTest { > public void think() { > while (true) { > if (checkInterruptedStatus()) break; > } > System.out.println("We're done thinking"); > } > > private boolean checkInterruptedStatus() { > return Thread.currentThread().isInterrupted(); > } > > public static void main(String[] args) throws InterruptedException { > final InterruptedVisibilityTest test = new InterruptedVisibilityTest(); > test.think(); > } > } > > > On 11/17/12 1:58 AM, Vladimir Kozlov wrote: >> On 11/16/12 14:25, Vladimir Ivanov wrote: >>> Vladimir K., >>> >>> Thanks, making depends_only_on_test == true for the load solves hoisting >>> problem. >>> >>> Original problem still persist (the check is hoisted [1]), but that's >>> another story - invariance analysis in >>> PhaseIdealLoop::loop_predication_impl doesn't respect pinning we do. >> >> loop_predication moves checks before the loop. In you case it is after. >> So it is something else. >> >>> >>> However, I wasn't able to figure out how to work with >>> insert_mem_bar(Op_MemBarCPUOrder). How the graph should look like? >> >> membar has 2 projections (ProjNode): control and memory. Load should >> points to both of them. In your graph only control edge of Load is >> membar projection. >> >> Vladimir >> >>> >>> It differs from volatile fields which produce multiple MemBar* nodes >>> scattered around in the graph and other MemBarCPUOrderNode usages in >>> library_call.cpp didn't give me any hint. >>> >>> If I issue it before the load [2], compilation fails during late >>> scheduling [3]. I tried to issue it after the load in different places, >>> but it didn't work (different assertions/compilation aborts during late >>> scheduling). >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] >>> http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loadnode_depends_on_test_true_after.png >>> >>> >>> >>> >>> Generated code: >>> 056 B6: # B6 <- B5 B6 top-of-loop Freq: 1e-35 >>> 056 movl R8, [R10 + #28 (8-bit)] # int >>> 05a testl rax, [rip + #offset_to_poll_page] # Safepoint: poll for GC # >>> InterruptedVisibilityTest::think @ bci:4 L[0]=RBP STK[0]=R8 >>> # OopMap{rbp=Oop off=90} >>> 060 jmp,s B6 >>> >>> [2] >>> http://cr.openjdk.java.net/~vlivanov/8003135/graphs/isInterrupted_membar_before.png >>> >>> >>> >>> >>> [3] 1696 3 b java.lang.Thread::isInterrupted (6 bytes) COMPILE SKIPPED: >>> late schedule failed: incorrect graph (not retryable) >>> >>> On 11/15/12 11:24 PM, Vladimir Kozlov wrote: >>>> PhaseIdealLoop::dominated_by() and IfNode::dominated_by() are >>>> correct in >>>> general case. The problem is value of depends_only_on_test(). This load >>>> is from RAW memory and we should not hoist it. See comment in LoadPNode >>>> class declaration. So we can widen the case to all loads - we have to >>>> confirm this with John. >>>> >>>> An other simple way to fix it is to add membar before load since it is >>>> volatile field: >>>> >>>> insert_mem_bar(Op_MemBarCPUOrder); >>>> >>>> Vladimir K. >>>> >>>> On 11/15/12 07:57, Vladimir Ivanov wrote: >>>>> Hi, >>>>> >>>>> I'm looking at 8003135 [1] and the problem is that during null check >>>>> (#132) hoisting, the load (#172) is also hoisted [2] [3]. LoadI >>>>> node is >>>>> constructed in LibraryCallKit::inline_native_isInterrupted >>>>> and is pinned to IfTrue projection (#133) of #132, but it doesn't >>>>> help. >>>>> >>>>> I'm not sure how to avoid the hoisting of the load. >>>>> >>>>> Should the load be pinned to corresponding Region/Loop node instead of >>>>> If node? >>>>> >>>>> Is the logic in PhaseIdealLoop::dominated_by which updates >>>>> control-dependent nodes (:242-:255)is correct? >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] https://jbs.oracle.com/bugs/browse/JDK-8003135 >>>>> "HotSpot inlines and hoists the Thread.currentThread().isInterrupted() >>>>> out of the loop" >>>>> >>>>> [2] >>>>> http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loop_invariant_hoisting_132_before.png >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> [3] >>>>> http://cr.openjdk.java.net/~vlivanov/8003135/graphs/loop_invariant_hoisting_132_after.png >>>>> >>>>> >>>>> >>>>> >>>>> From Vladimir.Kozlov at oracle.com Tue Nov 20 13:00:07 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Nov 2012 13:00:07 -0800 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50ABDC69.8050604@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> <509D3EE3.303@oracle.com> <50ABDC69.8050604@oracle.com> Message-ID: <50ABEF57.1020901@oracle.com> Bharadwaj, _log->begin_head("phase (3098-3103 lines) should be executed in TracePhase constructor (we have nested phases). And I don't understand your changes in LogParser.java. What I asked is to collect additional data for "live='x'" (the same thing we do for now for "nides='x'"). Thanks, Vladimir On 11/20/12 11:39, Bharadwaj Yadavalli wrote: > > Please review the updated webrev at > http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ > > Hopefully I have addressed all the review comments/suggestions. > > Thanks, > > Bharadwaj > > On 11/9/2012 12:35 PM, Vladimir Kozlov wrote: >> Bharadwaj, >> >> Nils just reminded me (for his changes) that you need to fix our >> LogCompilation parsing tool to recognize new "unique='n' >> live_tracked='n'" values (old was "nodes='n'"): >> >> src/share/tools/LogCompilation/ >> >> Also live_tracked could be simple "live". >> >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> VerifyIdealNodeCount flag should be also notproduct since it is used >>> only in debug VM. >>> >>> The next assert is not needed because it duplicates assert in >>> live_nodes(): >>> >>> bool check_node_count(uint margin, const char* reason) { >>> if (unique() + margin > (uint)MaxNodeLimit) { >>> + assert(dead_node_count() <= unique(), "number of dead nodes more >>> than created"); >>> >>> Also don't split the assert in live_nodes() into 2 lines and maybe >>> use err_msg_res() to print _unique and _dead_node_count values. Also >>> I think it should return unsigned int type value as unique() method. >>> >>> Second Compile() constructor does not set _dead_node_count(0). >>> >>> count_live_nodes_by_graph_walk() and NotANode() methods are now used >>> only in debug code so put them under #ifdef ASSERT. >>> >>> >>> print_missing_nodes() should call count_live_nodes_by_graph_walk() >>> instead of duplicating code. And it should print to _log itself. >>> TracePhase() code will have only call to it: >>> >>> 3133 if (VerifyIdealNodeCount) { >>> 3134 Compile::current()->print_missing_nodes(); >>> 3135 } >>> >>> And do not check VerifyIdealNodeCount in print_missing_nodes() to >>> allow call it in debugger without VerifyIdealNodeCount set. >>> >>> I think VerifyIdealNodeCount code should be in ~TracePhase() (end of >>> phase). >>> >>> Thanks, >>> Vladimir >>> >>> Bharadwaj Yadavalli wrote: >>>> Addressed comments on my previous RFR. Changes at >>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_02/ >>>> >>>> These changes are made to keep an (almost) accurate running count of >>>> the reachable (live) flow graph nodes. This will result in a more >>>> realistic node count for various phases of C2 to decide on whether >>>> to proceed with optimizations or not. Prior to these changes, C2 >>>> bails out of compilation based on the number of nodes created which >>>> typically larger than the number of reachable (live) nodes. >>>> From christian.thalinger at oracle.com Tue Nov 20 13:11:15 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Nov 2012 13:11:15 -0800 Subject: RFR (S): Issue constants to constant pool in stub code In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> Message-ID: <201207F2-DC70-4DDC-8CA2-F7D25E0FAE82@oracle.com> On Nov 20, 2012, at 2:05 AM, "Lindenmaier, Goetz" wrote: > Hi, > > When adding constants to the constant pool, the code_section is switched > to the constant pool code_section, and then back again. It was hard coded > to switch back to the code_section for code. > If constants are issued in stubs, it is switched back to the wrong code section. > I changed the code to remember the code section and switch back to the proper > one. > Further it?s necessary to relocate only after copying code and stub section to > a new location, as the relocation might affect an address in the stub section. > > You can find these changes here: > http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/ That's a nice fix. Recently I touched this code and I was worried about that also. I suppose on PPC you only use address_constant in stubs. What about the other constant emitting methods? -- Chris > > or in our ppc port: > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062 > > Thank you and best regards, > Goetz > From christian.thalinger at oracle.com Tue Nov 20 13:19:10 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Nov 2012 13:19:10 -0800 Subject: RFR (S): Specify offset of IC load in java_to_interp stub. In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF6672CB3@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6672CB3@DEWDFECCR03.wdf.sap.corp> Message-ID: <9436FC33-1E4D-41DD-9D54-8CE11D718BC2@oracle.com> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" wrote: > Hi, > > The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub > to update the IC with NativeMovConstReg. The current implementation assumes that > the load is always the first instruction in the stub. This is an artificial restriction. E.g., > it might be useful to load the constant pool address (MachConstantBase) before the > IC load (as we do on PPC). > > This change adds a constant specifying an offset from the beginning of the stub to > the IC load. The offset is platform specific and 0 on sparc and x86. > > You can find the change here: > http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/ That should be fixed indeed. +#ifndef COMPILER2 +const int CompiledStaticCall::comp_to_int_load_offset = 0; There is no C1 for PPC (sorry, I didn't check)? -- Chris > > or in our ppc port: > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 > > Thank you and best regards, > Goetz > > > From christian.thalinger at oracle.com Tue Nov 20 18:40:33 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Nov 2012 18:40:33 -0800 Subject: RFR (S) 8001538: hs_err file does not list anymore compiled methods in compilation events In-Reply-To: <50AA8526.90605@oracle.com> References: <50A26CF2.10505@oracle.com> <3F7665E3-3C59-475E-837D-242213CE7619@oracle.com> <50A52773.8040208@oracle.com> <50AA8526.90605@oracle.com> Message-ID: <13C305C6-8811-4AED-AC16-62C324F44D8A@oracle.com> On Nov 19, 2012, at 11:14 AM, Vladimir Ivanov wrote: > Vladimir K., Chis, thanks. Is someone going to push this change? -- Chris > > Best regards, > Vladimir Ivanov > > On 11/19/12 9:09 PM, Christian Thalinger wrote: >> Looks good. -- Chris >> >> On Nov 15, 2012, at 9:33 AM, Vladimir Ivanov wrote: >> >>> Vladimir K., Chris, thank you for the review. >>> >>> Yes, it restores original compilation events format [1] >>> >>> I verified that it's safe to use objects from resource area for logging: event logger copies message content into internal buffer. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/ >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/hs_err_pid87677.log >>> >>> On 11/13/12 7:41 PM, Vladimir Kozlov wrote: >>>> Very nice fix, Vladimir I., thank you >>>> >>>> To confirm, the size fix restored methods names in compilation events. Right? >>>> >>>> You moved deoptimization event logging under resourceMark, make sure the logging code does not use resource area or copied from it to safe place. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On Nov 13, 2012, at 7:53 AM, Vladimir Ivanov wrote: >>>> >>>>> http://cr.openjdk.java.net/~vlivanov/8001538/webrev.00/ >>>>> >>>>> Due to incorrect message buffer size calculation, a message may be truncated to 4/8 characters. >>>>> >>>>> Also, changed how deoptimization events are logged: >>>>> - moved [1] from "Deoptimization events" to "Events" section. >>>>> - added [2] to "Deoptimization events" section >>>>> >>>>> Sample output from a hs_err file: >>>>> Deoptimization events (2 events): >>>>> Event: 3.438 Thread 0x0000000103804800 Uncommon trap: Test::f @ 23, reason: unloaded, action: reinterpret >>>>> Event: 3.482 Thread 0x0000000103804800 Uncommon trap: Test::main @ 38, reason: unloaded, action: reinterpret >>>>> >>>>> Internal exceptions (10 events): >>>>> ... >>>>> >>>>> Events (10 events): >>>>> Event: 3.441 Thread 0x0000000103804800 DEOPT UNPACKING pc=0x00000001046cf214 sp=0x0000000100700548 mode 2 >>>>> Event: 3.482 Thread 0x0000000103804800 Uncommon trap 3 fr.pc 0x00000001046ffe1c >>>>> ... >>>>> >>>>> Testing: JPRT, simple test w/ deopt events in the log. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] Uncommon trap 3 fr.pc 0x00000001046ffe1c >>>>> [2] Uncommon trap: Test::f @ 23, reason=unloaded action=reinterpret >>>> >> From christian.thalinger at oracle.com Tue Nov 20 18:47:03 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Nov 2012 18:47:03 -0800 Subject: RFR (XL): 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() Message-ID: http://cr.openjdk.java.net/~twisti/7172640 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() Reviewed-by: Most intrinsics in LibraryCallKit re-push the arguments that have been popped off before the call to just pop them again as arguments. It would be much cleaner and more correct to use argument() accessors instead. Another problem is that it is very tricky to find the places where the stack pointer needs to be adjusted to the correct value for re-execution (uncommon traps). This adjustment is a plain SP bump and decrease after the call. In itself very error prone and it could be handled in a much more elegant way. src/share/vm/ci/ciMethod.cpp src/share/vm/ci/ciMethod.hpp src/share/vm/ci/ciSignature.hpp src/share/vm/interpreter/bytecodes.hpp src/share/vm/opto/callGenerator.cpp src/share/vm/opto/callnode.hpp src/share/vm/opto/doCall.cpp src/share/vm/opto/graphKit.cpp src/share/vm/opto/graphKit.hpp src/share/vm/opto/library_call.cpp src/share/vm/opto/parse1.cpp src/share/vm/opto/parse2.cpp src/share/vm/opto/parse3.cpp src/share/vm/opto/parseHelper.cpp src/share/vm/opto/type.hpp From vladimir.kozlov at oracle.com Tue Nov 20 19:57:42 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Nov 2012 19:57:42 -0800 Subject: RFR (S) 8001538: hs_err file does not list anymore compiled methods in compilation events In-Reply-To: <13C305C6-8811-4AED-AC16-62C324F44D8A@oracle.com> References: <50A26CF2.10505@oracle.com> <3F7665E3-3C59-475E-837D-242213CE7619@oracle.com> <50A52773.8040208@oracle.com> <50AA8526.90605@oracle.com> <13C305C6-8811-4AED-AC16-62C324F44D8A@oracle.com> Message-ID: <5E09F0B6-ADAF-4EB5-8198-12C79A711794@oracle.com> Vladimir I. can do it himself since he is Committer now. Vladimir K. On Nov 20, 2012, at 6:40 PM, Christian Thalinger wrote: > > On Nov 19, 2012, at 11:14 AM, Vladimir Ivanov wrote: > >> Vladimir K., Chis, thanks. > > Is someone going to push this change? > > -- Chris > >> >> Best regards, >> Vladimir Ivanov >> >> On 11/19/12 9:09 PM, Christian Thalinger wrote: >>> Looks good. -- Chris >>> >>> On Nov 15, 2012, at 9:33 AM, Vladimir Ivanov wrote: >>> >>>> Vladimir K., Chris, thank you for the review. >>>> >>>> Yes, it restores original compilation events format [1] >>>> >>>> I verified that it's safe to use objects from resource area for logging: event logger copies message content into internal buffer. >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/ >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/hs_err_pid87677.log >>>> >>>> On 11/13/12 7:41 PM, Vladimir Kozlov wrote: >>>>> Very nice fix, Vladimir I., thank you >>>>> >>>>> To confirm, the size fix restored methods names in compilation events. Right? >>>>> >>>>> You moved deoptimization event logging under resourceMark, make sure the logging code does not use resource area or copied from it to safe place. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On Nov 13, 2012, at 7:53 AM, Vladimir Ivanov wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~vlivanov/8001538/webrev.00/ >>>>>> >>>>>> Due to incorrect message buffer size calculation, a message may be truncated to 4/8 characters. >>>>>> >>>>>> Also, changed how deoptimization events are logged: >>>>>> - moved [1] from "Deoptimization events" to "Events" section. >>>>>> - added [2] to "Deoptimization events" section >>>>>> >>>>>> Sample output from a hs_err file: >>>>>> Deoptimization events (2 events): >>>>>> Event: 3.438 Thread 0x0000000103804800 Uncommon trap: Test::f @ 23, reason: unloaded, action: reinterpret >>>>>> Event: 3.482 Thread 0x0000000103804800 Uncommon trap: Test::main @ 38, reason: unloaded, action: reinterpret >>>>>> >>>>>> Internal exceptions (10 events): >>>>>> ... >>>>>> >>>>>> Events (10 events): >>>>>> Event: 3.441 Thread 0x0000000103804800 DEOPT UNPACKING pc=0x00000001046cf214 sp=0x0000000100700548 mode 2 >>>>>> Event: 3.482 Thread 0x0000000103804800 Uncommon trap 3 fr.pc 0x00000001046ffe1c >>>>>> ... >>>>>> >>>>>> Testing: JPRT, simple test w/ deopt events in the log. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> [1] Uncommon trap 3 fr.pc 0x00000001046ffe1c >>>>>> [2] Uncommon trap: Test::f @ 23, reason=unloaded action=reinterpret >>>>> >>> > From vladimir.kozlov at oracle.com Tue Nov 20 20:13:39 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Nov 2012 20:13:39 -0800 Subject: RFR (XL): 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() In-Reply-To: References: Message-ID: <330A47A4-3251-461D-8C70-5752203A1344@oracle.com> Could you factor out the assert in callnode.hpp? graphKit.cpp: + // If the bytecode needs to be reexecuted we need a stack pointer with + // the arguments on the stack. ---- + // If the bytecode needs to be reexecuted we need to put + // the arguments back on the stack. + // NOTE: set_bci (called from sync_jvms) might reset the reexecute bit to + // undefined if the bci is different. This is okay for Parse but is a + // problem for LibraryCallKit where we explicitly set the reexecute bit. ---- + // NOTE: set_bci (called from sync_jvms) will reset the reexecute bit to + // undefined if the bci is different. This is normal for Parse but it + // should not happen for LibraryCallKit because only one bci is processed. Thanks, Vladimir K. On Nov 20, 2012, at 6:47 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7172640 > > 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() > Reviewed-by: > > Most intrinsics in LibraryCallKit re-push the arguments that have been > popped off before the call to just pop them again as arguments. It > would be much cleaner and more correct to use argument() accessors > instead. > > Another problem is that it is very tricky to find the places where the > stack pointer needs to be adjusted to the correct value for > re-execution (uncommon traps). This adjustment is a plain SP bump and > decrease after the call. In itself very error prone and it could be > handled in a much more elegant way. > > src/share/vm/ci/ciMethod.cpp > src/share/vm/ci/ciMethod.hpp > src/share/vm/ci/ciSignature.hpp > src/share/vm/interpreter/bytecodes.hpp > src/share/vm/opto/callGenerator.cpp > src/share/vm/opto/callnode.hpp > src/share/vm/opto/doCall.cpp > src/share/vm/opto/graphKit.cpp > src/share/vm/opto/graphKit.hpp > src/share/vm/opto/library_call.cpp > src/share/vm/opto/parse1.cpp > src/share/vm/opto/parse2.cpp > src/share/vm/opto/parse3.cpp > src/share/vm/opto/parseHelper.cpp > src/share/vm/opto/type.hpp > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121120/ad26a664/attachment.html From goetz.lindenmaier at sap.com Wed Nov 21 00:14:08 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 21 Nov 2012 09:14:08 +0100 Subject: RFR (S): Issue constants to constant pool in stub code In-Reply-To: <201207F2-DC70-4DDC-8CA2-F7D25E0FAE82@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> <201207F2-DC70-4DDC-8CA2-F7D25E0FAE82@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF667377D@DEWDFECCR03.wdf.sap.corp> Hi Christian, you're right, I should fix the other constants too. I also can kick out the end_a_const() without argument, as it's no more needed, then. Thanks, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Dienstag, 20. November 2012 22:11 To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): Issue constants to constant pool in stub code On Nov 20, 2012, at 2:05 AM, "Lindenmaier, Goetz" wrote: > Hi, > > When adding constants to the constant pool, the code_section is switched > to the constant pool code_section, and then back again. It was hard coded > to switch back to the code_section for code. > If constants are issued in stubs, it is switched back to the wrong code section. > I changed the code to remember the code section and switch back to the proper > one. > Further it's necessary to relocate only after copying code and stub section to > a new location, as the relocation might affect an address in the stub section. > > You can find these changes here: > http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/ That's a nice fix. Recently I touched this code and I was worried about that also. I suppose on PPC you only use address_constant in stubs. What about the other constant emitting methods? -- Chris > > or in our ppc port: > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062 > > Thank you and best regards, > Goetz > From goetz.lindenmaier at sap.com Wed Nov 21 00:15:51 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 21 Nov 2012 09:15:51 +0100 Subject: RFR (S): Specify offset of IC load in java_to_interp stub. In-Reply-To: <9436FC33-1E4D-41DD-9D54-8CE11D718BC2@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF6672CB3@DEWDFECCR03.wdf.sap.corp> <9436FC33-1E4D-41DD-9D54-8CE11D718BC2@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF6673783@DEWDFECCR03.wdf.sap.corp> Hi Chris, yes, there is no C1 on ppc. We do tiered compilation with a stripped C2. Best regards, Goetz -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Dienstag, 20. November 2012 22:19 To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub. On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" wrote: > Hi, > > The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub > to update the IC with NativeMovConstReg. The current implementation assumes that > the load is always the first instruction in the stub. This is an artificial restriction. E.g., > it might be useful to load the constant pool address (MachConstantBase) before the > IC load (as we do on PPC). > > This change adds a constant specifying an offset from the beginning of the stub to > the IC load. The offset is platform specific and 0 on sparc and x86. > > You can find the change here: > http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/ That should be fixed indeed. +#ifndef COMPILER2 +const int CompiledStaticCall::comp_to_int_load_offset = 0; There is no C1 for PPC (sorry, I didn't check)? -- Chris > > or in our ppc port: > http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 > > Thank you and best regards, > Goetz > > > From vladimir.x.ivanov at oracle.com Wed Nov 21 02:03:35 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 21 Nov 2012 13:03:35 +0300 Subject: RFR (S) 8001538: hs_err file does not list anymore compiled methods in compilation events In-Reply-To: <5E09F0B6-ADAF-4EB5-8198-12C79A711794@oracle.com> References: <50A26CF2.10505@oracle.com> <3F7665E3-3C59-475E-837D-242213CE7619@oracle.com> <50A52773.8040208@oracle.com> <50AA8526.90605@oracle.com> <13C305C6-8811-4AED-AC16-62C324F44D8A@oracle.com> <5E09F0B6-ADAF-4EB5-8198-12C79A711794@oracle.com> Message-ID: <50ACA6F7.5030708@oracle.com> Yes, I plan to push it today. Best regards, Vladimir Ivanov On 11/21/12 6:57 AM, Vladimir Kozlov wrote: > Vladimir I. can do it himself since he is Committer now. > > Vladimir K. > > On Nov 20, 2012, at 6:40 PM, Christian Thalinger wrote: > >> >> On Nov 19, 2012, at 11:14 AM, Vladimir Ivanov wrote: >> >>> Vladimir K., Chis, thanks. >> >> Is someone going to push this change? >> >> -- Chris >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/19/12 9:09 PM, Christian Thalinger wrote: >>>> Looks good. -- Chris >>>> >>>> On Nov 15, 2012, at 9:33 AM, Vladimir Ivanov wrote: >>>> >>>>> Vladimir K., Chris, thank you for the review. >>>>> >>>>> Yes, it restores original compilation events format [1] >>>>> >>>>> I verified that it's safe to use objects from resource area for logging: event logger copies message content into internal buffer. >>>>> >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/ >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> [1] http://cr.openjdk.java.net/~vlivanov/8001538/webrev.01/hs_err_pid87677.log >>>>> >>>>> On 11/13/12 7:41 PM, Vladimir Kozlov wrote: >>>>>> Very nice fix, Vladimir I., thank you >>>>>> >>>>>> To confirm, the size fix restored methods names in compilation events. Right? >>>>>> >>>>>> You moved deoptimization event logging under resourceMark, make sure the logging code does not use resource area or copied from it to safe place. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On Nov 13, 2012, at 7:53 AM, Vladimir Ivanov wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~vlivanov/8001538/webrev.00/ >>>>>>> >>>>>>> Due to incorrect message buffer size calculation, a message may be truncated to 4/8 characters. >>>>>>> >>>>>>> Also, changed how deoptimization events are logged: >>>>>>> - moved [1] from "Deoptimization events" to "Events" section. >>>>>>> - added [2] to "Deoptimization events" section >>>>>>> >>>>>>> Sample output from a hs_err file: >>>>>>> Deoptimization events (2 events): >>>>>>> Event: 3.438 Thread 0x0000000103804800 Uncommon trap: Test::f @ 23, reason: unloaded, action: reinterpret >>>>>>> Event: 3.482 Thread 0x0000000103804800 Uncommon trap: Test::main @ 38, reason: unloaded, action: reinterpret >>>>>>> >>>>>>> Internal exceptions (10 events): >>>>>>> ... >>>>>>> >>>>>>> Events (10 events): >>>>>>> Event: 3.441 Thread 0x0000000103804800 DEOPT UNPACKING pc=0x00000001046cf214 sp=0x0000000100700548 mode 2 >>>>>>> Event: 3.482 Thread 0x0000000103804800 Uncommon trap 3 fr.pc 0x00000001046ffe1c >>>>>>> ... >>>>>>> >>>>>>> Testing: JPRT, simple test w/ deopt events in the log. >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> [1] Uncommon trap 3 fr.pc 0x00000001046ffe1c >>>>>>> [2] Uncommon trap: Test::f @ 23, reason=unloaded action=reinterpret >>>>>> >>>> >> > From vladimir.x.ivanov at oracle.com Wed Nov 21 04:52:31 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 21 Nov 2012 15:52:31 +0300 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50ABDC69.8050604@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> <509D3EE3.303@oracle.com> <50ABDC69.8050604@oracle.com> Message-ID: <50ACCE8F.1080701@oracle.com> Few minor comments: src/share/vm/opto/compile.cpp: +static inline bool NotANode(const Node* n) { Can you rename it to something like not_a_node? Camel style names aren't common in the codebase. if (_log != NULL) { - _log->done("phase nodes='%d'", C->unique()); + _log->done("phase name='%s'", _phase_name); } Phase name is redundant here - it duplicates info from the head. But I would leave nodes count as is and add live nodes count. Best regards, Vladimir Ivanov On 11/20/12 10:39 PM, Bharadwaj Yadavalli wrote: > > Please review the updated webrev at > http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ > > Hopefully I have addressed all the review comments/suggestions. > > Thanks, > > Bharadwaj > > On 11/9/2012 12:35 PM, Vladimir Kozlov wrote: >> Bharadwaj, >> >> Nils just reminded me (for his changes) that you need to fix our >> LogCompilation parsing tool to recognize new "unique='n' >> live_tracked='n'" values (old was "nodes='n'"): >> >> src/share/tools/LogCompilation/ >> >> Also live_tracked could be simple "live". >> >> Thanks, >> Vladimir >> >> Vladimir Kozlov wrote: >>> VerifyIdealNodeCount flag should be also notproduct since it is used >>> only in debug VM. >>> >>> The next assert is not needed because it duplicates assert in >>> live_nodes(): >>> >>> bool check_node_count(uint margin, const char* reason) { >>> if (unique() + margin > (uint)MaxNodeLimit) { >>> + assert(dead_node_count() <= unique(), "number of dead nodes >>> more than created"); >>> >>> Also don't split the assert in live_nodes() into 2 lines and maybe >>> use err_msg_res() to print _unique and _dead_node_count values. Also >>> I think it should return unsigned int type value as unique() method. >>> >>> Second Compile() constructor does not set _dead_node_count(0). >>> >>> count_live_nodes_by_graph_walk() and NotANode() methods are now used >>> only in debug code so put them under #ifdef ASSERT. >>> >>> >>> print_missing_nodes() should call count_live_nodes_by_graph_walk() >>> instead of duplicating code. And it should print to _log itself. >>> TracePhase() code will have only call to it: >>> >>> 3133 if (VerifyIdealNodeCount) { >>> 3134 Compile::current()->print_missing_nodes(); >>> 3135 } >>> >>> And do not check VerifyIdealNodeCount in print_missing_nodes() to >>> allow call it in debugger without VerifyIdealNodeCount set. >>> >>> I think VerifyIdealNodeCount code should be in ~TracePhase() (end of >>> phase). >>> >>> Thanks, >>> Vladimir >>> >>> Bharadwaj Yadavalli wrote: >>>> Addressed comments on my previous RFR. Changes at >>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_02/ >>>> >>>> These changes are made to keep an (almost) accurate running count of >>>> the reachable (live) flow graph nodes. This will result in a more >>>> realistic node count for various phases of C2 to decide on whether >>>> to proceed with optimizations or not. Prior to these changes, C2 >>>> bails out of compilation based on the number of nodes created which >>>> typically larger than the number of reachable (live) nodes. >>>> From goetz.lindenmaier at sap.com Wed Nov 21 06:51:15 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 21 Nov 2012 15:51:15 +0100 Subject: RFR (M): lateExpand: expands nodes after register allocation Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF6812157@DEWDFECCR03.wdf.sap.corp> Hi, Michael and Volker talked to you about our late expand feature at JavaOne. The lateExpand phase in the C2 compiler expands nodes after register allocation. Some nodes can not be expanded during matching. E.g., register allocation might not be able to deal with the resulting pattern. To allow better scheduling in such cases, we introduce lateExpand which runs after register allocation. Whether and how nodes are expanded is specified in the ad-file. See block.cpp for a detailed documentation. We use this for some nodes on ppc, and extensively on ia64. The change below contains the code for this feature. http://cr.openjdk.java.net/~goetz/webrevs/webrev-lateExpand/ Below you find an example how to use late expand for the sparc.ad file. Further down you see the code generated by adlc. Perhaps you can find better use cases for this feature. Best regards, Goetz. --- a/src/cpu/sparc/vm/sparc.ad 2012-11-21 12:27:04.591486000 +0100 +++ b/src/cpu/sparc/vm/sparc.ad 2012-11-19 14:45:15.059452000 +0100 @@ -1933,7 +1937,7 @@ } // Does the CPU require late expand (see block.cpp for description of late expand)? -const bool Matcher::require_late_expand = false; +const bool Matcher::require_late_expand = true; // Should the Matcher clone shifts on addressing modes, expecting them to // be subsumed into complex addressing expressions or compute them into @@ -7497,6 +7501,7 @@ // Register Division instruct divI_reg_reg(iRegI dst, iRegIsafe src1, iRegIsafe src2) %{ match(Set dst (DivI src1 src2)); + predicate(!UseNewCode); ins_cost((2+71)*DEFAULT_COST); format %{ "SRA $src2,0,$src2\n\t" @@ -7506,6 +7511,68 @@ ins_pipe(sdiv_reg_reg); %} +//------------------------------------------------------------------------------------ + +encode %{ + + enc_class lateExpandIdiv_reg_reg(iRegI dst, iRegIsafe src1, iRegIsafe src2) %{ + MachNode *m1 = new (C) divI_reg_reg_SRANode(); + MachNode *m2 = new (C) divI_reg_reg_SRANode(); + MachNode *m3 = new (C) divI_reg_reg_SDIVXNode(); + + m1->add_req(n_region, n_src1); + m2->add_req(n_region, n_src2); + m3->add_req(n_region, m1, m2); + + m1->_opnds[0] = _opnds[1]->clone(C); + m1->_opnds[1] = _opnds[1]->clone(C); + + m2->_opnds[0] = _opnds[2]->clone(C); + m2->_opnds[1] = _opnds[2]->clone(C); + + m3->_opnds[0] = _opnds[0]->clone(C); + m3->_opnds[1] = _opnds[1]->clone(C); + m3->_opnds[2] = _opnds[2]->clone(C); + + ra_->set1(m1->_idx, ra_->get_reg_first(n_src1)); + ra_->set1(m2->_idx, ra_->get_reg_first(n_src2)); + ra_->set1(m3->_idx, ra_->get_reg_first(this)); + + nodes->push(m1); + nodes->push(m2); + nodes->push(m3); + %} +%} + +instruct divI_reg_reg_SRA(iRegIsafe dst) %{ + effect(USE_DEF dst); + size(4); + format %{ "SRA $dst,0,$dst\n\t" %} + ins_encode %{ __ sra($dst$$Register, 0, $dst$$Register); %} + ins_pipe(ialu_reg_reg); +%} + +instruct divI_reg_reg_SDIVX(iRegI dst, iRegIsafe src1, iRegIsafe src2) %{ + effect(DEF dst, USE src1, USE src2); + size(4); + format %{ "SDIVX $src1,$src2,$dst\n\t" %} + ins_encode %{ __ sdivx($dst$$Register, 0, $dst$$Register); %} + ins_pipe(sdiv_reg_reg); +%} + +instruct divI_reg_reg_Ex(iRegI dst, iRegIsafe src1, iRegIsafe src2) %{ + match(Set dst (DivI src1 src2)); + predicate(UseNewCode); + ins_cost((2+71)*DEFAULT_COST); + + format %{ "SRA $src2,0,$src2\n\t" + "SRA $src1,0,$src1\n\t" + "SDIVX $src1,$src2,$dst" %} + lateExpand( lateExpandIdiv_reg_reg(src1, src2, dst) ); +%} + +//------------------------------------------------------------------------------------ + // Immediate Division instruct divI_reg_imm13(iRegI dst, iRegIsafe src1, immI13 src2) %{ match(Set dst (DivI src1 src2)); class divI_reg_reg_ExNode : public MachNode { // ... virtual bool requires_late_expand() const { return true; } virtual void lateExpand(GrowableArray *nodes, PhaseRegAlloc *ra_); // ... }; void divI_reg_reg_ExNode::lateExpand(GrowableArray *nodes, PhaseRegAlloc *ra_) { // Start at oper_input_base() and count operands unsigned idx0 = 1; unsigned idx1 = 1; // src1 unsigned idx2 = idx1 + opnd_array(1)->num_edges(); // src2 // Access to ins and operands for late expand. unsigned idx_dst = idx1; // iRegI, src1 unsigned idx_src1 = idx2; // iRegIsafe, src2 unsigned idx_src2 = idx0; // iRegIsafe, dst Node *n_region = lookup(0); Node *n_dst = lookup(idx_dst); Node *n_src1 = lookup(idx_src1); Node *n_src2 = lookup(idx_src2); iRegIOper *op_dst = (iRegIOper *)opnd_array(1); iRegIsafeOper *op_src1 = (iRegIsafeOper *)opnd_array(2); iRegIsafeOper *op_src2 = (iRegIsafeOper *)opnd_array(0); Compile *C = Compile::current(); { #line 7518 "/net/usr.work/d045726/oJ/8/main-hotspot-outputStream-test/src/cpu/sparc/vm/sparc.ad" MachNode *m1 = new (C) divI_reg_reg_SRANode(); MachNode *m2 = new (C) divI_reg_reg_SRANode(); MachNode *m3 = new (C) divI_reg_reg_SDIVXNode(); m1->add_req(n_region, n_src1); m2->add_req(n_region, n_src2); m3->add_req(n_region, m1, m2); m1->_opnds[0] = _opnds[1]->clone(C); m1->_opnds[1] = _opnds[1]->clone(C); m2->_opnds[0] = _opnds[2]->clone(C); m2->_opnds[1] = _opnds[2]->clone(C); m3->_opnds[0] = _opnds[0]->clone(C); m3->_opnds[1] = _opnds[1]->clone(C); m3->_opnds[2] = _opnds[2]->clone(C); ra_->set1(m1->_idx, ra_->get_reg_first(n_src1)); ra_->set1(m2->_idx, ra_->get_reg_first(n_src2)); ra_->set1(m3->_idx, ra_->get_reg_first(this)); nodes->push(m1); nodes->push(m2); nodes->push(m3); #line 11120 "../generated/adfiles/ad_sparc.cpp" } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121121/549369f6/attachment-0001.html From christian.thalinger at oracle.com Wed Nov 21 10:44:48 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Nov 2012 10:44:48 -0800 Subject: RFR (S): 8003850: add support for constants in stub code [Was: Re: RFR (S): Issue constants to constant pool in stub code] In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF667377D@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> <201207F2-DC70-4DDC-8CA2-F7D25E0FAE82@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF667377D@DEWDFECCR03.wdf.sap.corp> Message-ID: <139AA4B4-0875-4E3E-BEFE-D1F33E37011C@oracle.com> On Nov 21, 2012, at 12:14 AM, "Lindenmaier, Goetz" wrote: > Hi Christian, > > you're right, I should fix the other constants too. > I also can kick out the end_a_const() without argument, as it's no more needed, then. I filed: 8003850: add support for constants in stub code -- Chris > > Thanks, > Goetz. > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Dienstag, 20. November 2012 22:11 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (S): Issue constants to constant pool in stub code > > > On Nov 20, 2012, at 2:05 AM, "Lindenmaier, Goetz" wrote: > >> Hi, >> >> When adding constants to the constant pool, the code_section is switched >> to the constant pool code_section, and then back again. It was hard coded >> to switch back to the code_section for code. >> If constants are issued in stubs, it is switched back to the wrong code section. >> I changed the code to remember the code section and switch back to the proper >> one. >> Further it's necessary to relocate only after copying code and stub section to >> a new location, as the relocation might affect an address in the stub section. >> >> You can find these changes here: >> http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/ > > That's a nice fix. Recently I touched this code and I was worried about that also. I suppose on PPC you only use address_constant in stubs. What about the other constant emitting methods? > > -- Chris > >> >> or in our ppc port: >> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062 >> >> Thank you and best regards, >> Goetz >> > From christian.thalinger at oracle.com Wed Nov 21 10:52:34 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Nov 2012 10:52:34 -0800 Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF6673783@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6672CB3@DEWDFECCR03.wdf.sap.corp> <9436FC33-1E4D-41DD-9D54-8CE11D718BC2@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF6673783@DEWDFECCR03.wdf.sap.corp> Message-ID: On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz" wrote: > Hi Chris, > > yes, there is no C1 on ppc. > We do tiered compilation with a stripped C2. Right. But some other architecture (or in the future) might need this for C1 as well. We should find a better place for the value than the ad file. The obvious place would be compiledIC_.hpp but we don't have that file, yet. I filed: 8003853: specify offset of IC load in java_to_interp stub -- Chris > > Best regards, > Goetz > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Dienstag, 20. November 2012 22:19 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub. > > > On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" wrote: > >> Hi, >> >> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub >> to update the IC with NativeMovConstReg. The current implementation assumes that >> the load is always the first instruction in the stub. This is an artificial restriction. E.g., >> it might be useful to load the constant pool address (MachConstantBase) before the >> IC load (as we do on PPC). >> >> This change adds a constant specifying an offset from the beginning of the stub to >> the IC load. The offset is platform specific and 0 on sparc and x86. >> >> You can find the change here: >> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/ > > That should be fixed indeed. > > +#ifndef COMPILER2 > +const int CompiledStaticCall::comp_to_int_load_offset = 0; > > There is no C1 for PPC (sorry, I didn't check)? > > -- Chris > >> >> or in our ppc port: >> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 >> >> Thank you and best regards, >> Goetz >> >> >> > From christian.thalinger at oracle.com Wed Nov 21 11:04:50 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Nov 2012 11:04:50 -0800 Subject: RFR (M): 8003854: expand nodes after register allocation [Was: Re: RFR (M): lateExpand: expands nodes after register allocation] In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF6812157@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6812157@DEWDFECCR03.wdf.sap.corp> Message-ID: On Nov 21, 2012, at 6:51 AM, "Lindenmaier, Goetz" wrote: > Hi, > > Michael and Volker talked to you about our late expand feature at JavaOne. > > The lateExpand phase in the C2 compiler expands nodes after register > allocation. > Some nodes can not be expanded during matching. E.g., register allocation > might not be able to deal with the resulting pattern. To allow better > scheduling in such cases, we introduce lateExpand which runs after > register allocation. Whether and how nodes are expanded is specified > in the ad-file. See block.cpp for a detailed documentation. We use this > for some nodes on ppc, and extensively on ia64. > > The change below contains the code for this feature. > > http://cr.openjdk.java.net/~goetz/webrevs/webrev-lateExpand/ > > Below you find an example how to use late expand for the sparc.ad file. > Further down you see the code generated by adlc. > Perhaps you can find better use cases for this feature. I filed: 8003854: expand nodes after register allocation -- Chris > > Best regards, > Goetz. > > > --- a/src/cpu/sparc/vm/sparc.ad 2012-11-21 12:27:04.591486000 +0100 > +++ b/src/cpu/sparc/vm/sparc.ad 2012-11-19 14:45:15.059452000 +0100 > @@ -1933,7 +1937,7 @@ > } > > // Does the CPU require late expand (see block.cpp for description of late expand)? > -const bool Matcher::require_late_expand = false; > +const bool Matcher::require_late_expand = true; > > // Should the Matcher clone shifts on addressing modes, expecting them to > // be subsumed into complex addressing expressions or compute them into > @@ -7497,6 +7501,7 @@ > // Register Division > instruct divI_reg_reg(iRegI dst, iRegIsafe src1, iRegIsafe src2) %{ > match(Set dst (DivI src1 src2)); > + predicate(!UseNewCode); > ins_cost((2+71)*DEFAULT_COST); > > format %{ "SRA $src2,0,$src2\n\t" > @@ -7506,6 +7511,68 @@ > ins_pipe(sdiv_reg_reg); > %} > > +//------------------------------------------------------------------------------------ > + > +encode %{ > + > + enc_class lateExpandIdiv_reg_reg(iRegI dst, iRegIsafe src1, iRegIsafe src2) %{ > + MachNode *m1 = new (C) divI_reg_reg_SRANode(); > + MachNode *m2 = new (C) divI_reg_reg_SRANode(); > + MachNode *m3 = new (C) divI_reg_reg_SDIVXNode(); > + > + m1->add_req(n_region, n_src1); > + m2->add_req(n_region, n_src2); > + m3->add_req(n_region, m1, m2); > + > + m1->_opnds[0] = _opnds[1]->clone(C); > + m1->_opnds[1] = _opnds[1]->clone(C); > + > + m2->_opnds[0] = _opnds[2]->clone(C); > + m2->_opnds[1] = _opnds[2]->clone(C); > + > + m3->_opnds[0] = _opnds[0]->clone(C); > + m3->_opnds[1] = _opnds[1]->clone(C); > + m3->_opnds[2] = _opnds[2]->clone(C); > + > + ra_->set1(m1->_idx, ra_->get_reg_first(n_src1)); > + ra_->set1(m2->_idx, ra_->get_reg_first(n_src2)); > + ra_->set1(m3->_idx, ra_->get_reg_first(this)); > + > + nodes->push(m1); > + nodes->push(m2); > + nodes->push(m3); > + %} > +%} > + > +instruct divI_reg_reg_SRA(iRegIsafe dst) %{ > + effect(USE_DEF dst); > + size(4); > + format %{ "SRA $dst,0,$dst\n\t" %} > + ins_encode %{ __ sra($dst$$Register, 0, $dst$$Register); %} > + ins_pipe(ialu_reg_reg); > +%} > + > +instruct divI_reg_reg_SDIVX(iRegI dst, iRegIsafe src1, iRegIsafe src2) %{ > + effect(DEF dst, USE src1, USE src2); > + size(4); > + format %{ "SDIVX $src1,$src2,$dst\n\t" %} > + ins_encode %{ __ sdivx($dst$$Register, 0, $dst$$Register); %} > + ins_pipe(sdiv_reg_reg); > +%} > + > +instruct divI_reg_reg_Ex(iRegI dst, iRegIsafe src1, iRegIsafe src2) %{ > + match(Set dst (DivI src1 src2)); > + predicate(UseNewCode); > + ins_cost((2+71)*DEFAULT_COST); > + > + format %{ "SRA $src2,0,$src2\n\t" > + "SRA $src1,0,$src1\n\t" > + "SDIVX $src1,$src2,$dst" %} > + lateExpand( lateExpandIdiv_reg_reg(src1, src2, dst) ); > +%} > + > +//------------------------------------------------------------------------------------ > + > // Immediate Division > instruct divI_reg_imm13(iRegI dst, iRegIsafe src1, immI13 src2) %{ > match(Set dst (DivI src1 src2)); > > > > > class divI_reg_reg_ExNode : public MachNode { > // ... > virtual bool requires_late_expand() const { return true; } > virtual void lateExpand(GrowableArray *nodes, PhaseRegAlloc *ra_); > // ... > }; > > void divI_reg_reg_ExNode::lateExpand(GrowableArray *nodes, PhaseRegAlloc *ra_) { > // Start at oper_input_base() and count operands > unsigned idx0 = 1; > unsigned idx1 = 1; // src1 > unsigned idx2 = idx1 + opnd_array(1)->num_edges(); // src2 > // Access to ins and operands for late expand. > unsigned idx_dst = idx1; // iRegI, src1 > unsigned idx_src1 = idx2; // iRegIsafe, src2 > unsigned idx_src2 = idx0; // iRegIsafe, dst > Node *n_region = lookup(0); > Node *n_dst = lookup(idx_dst); > Node *n_src1 = lookup(idx_src1); > Node *n_src2 = lookup(idx_src2); > iRegIOper *op_dst = (iRegIOper *)opnd_array(1); > iRegIsafeOper *op_src1 = (iRegIsafeOper *)opnd_array(2); > iRegIsafeOper *op_src2 = (iRegIsafeOper *)opnd_array(0); > Compile *C = Compile::current(); > { > #line 7518 "/net/usr.work/d045726/oJ/8/main-hotspot-outputStream-test/src/cpu/sparc/vm/sparc.ad" > > MachNode *m1 = new (C) divI_reg_reg_SRANode(); > MachNode *m2 = new (C) divI_reg_reg_SRANode(); > MachNode *m3 = new (C) divI_reg_reg_SDIVXNode(); > > m1->add_req(n_region, n_src1); > m2->add_req(n_region, n_src2); > m3->add_req(n_region, m1, m2); > > m1->_opnds[0] = _opnds[1]->clone(C); > m1->_opnds[1] = _opnds[1]->clone(C); > > m2->_opnds[0] = _opnds[2]->clone(C); > m2->_opnds[1] = _opnds[2]->clone(C); > > m3->_opnds[0] = _opnds[0]->clone(C); > m3->_opnds[1] = _opnds[1]->clone(C); > m3->_opnds[2] = _opnds[2]->clone(C); > > ra_->set1(m1->_idx, ra_->get_reg_first(n_src1)); > ra_->set1(m2->_idx, ra_->get_reg_first(n_src2)); > ra_->set1(m3->_idx, ra_->get_reg_first(this)); > > nodes->push(m1); > nodes->push(m2); > nodes->push(m3); > > #line 11120 "../generated/adfiles/ad_sparc.cpp" > } > } From christian.thalinger at oracle.com Wed Nov 21 14:41:42 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Nov 2012 14:41:42 -0800 Subject: RFR (XL): 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() In-Reply-To: <330A47A4-3251-461D-8C70-5752203A1344@oracle.com> References: <330A47A4-3251-461D-8C70-5752203A1344@oracle.com> Message-ID: <9FA13D58-7069-4428-A82C-42A33D1E990F@oracle.com> On Nov 20, 2012, at 8:13 PM, Vladimir Kozlov wrote: > Could you factor out the assert in callnode.hpp? Done. > > graphKit.cpp: > > + // If the bytecode needs to be reexecuted we need a stack pointer with > + // the arguments on the stack. > ---- > + // If the bytecode needs to be reexecuted we need to put > + // the arguments back on the stack. > > + // NOTE: set_bci (called from sync_jvms) might reset the reexecute bit to > + // undefined if the bci is different. This is okay for Parse but is a > + // problem for LibraryCallKit where we explicitly set the reexecute bit. > ---- > + // NOTE: set_bci (called from sync_jvms) will reset the reexecute bit to > + // undefined if the bci is different. This is normal for Parse but it > + // should not happen for LibraryCallKit because only one bci is processed. Done. webrev updated. -- Chris > Thanks, > Vladimir K. > > On Nov 20, 2012, at 6:47 PM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7172640 >> >> 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() >> Reviewed-by: >> >> Most intrinsics in LibraryCallKit re-push the arguments that have been >> popped off before the call to just pop them again as arguments. It >> would be much cleaner and more correct to use argument() accessors >> instead. >> >> Another problem is that it is very tricky to find the places where the >> stack pointer needs to be adjusted to the correct value for >> re-execution (uncommon traps). This adjustment is a plain SP bump and >> decrease after the call. In itself very error prone and it could be >> handled in a much more elegant way. >> >> src/share/vm/ci/ciMethod.cpp >> src/share/vm/ci/ciMethod.hpp >> src/share/vm/ci/ciSignature.hpp >> src/share/vm/interpreter/bytecodes.hpp >> src/share/vm/opto/callGenerator.cpp >> src/share/vm/opto/callnode.hpp >> src/share/vm/opto/doCall.cpp >> src/share/vm/opto/graphKit.cpp >> src/share/vm/opto/graphKit.hpp >> src/share/vm/opto/library_call.cpp >> src/share/vm/opto/parse1.cpp >> src/share/vm/opto/parse2.cpp >> src/share/vm/opto/parse3.cpp >> src/share/vm/opto/parseHelper.cpp >> src/share/vm/opto/type.hpp >> > From Vladimir.Kozlov at oracle.com Wed Nov 21 15:01:42 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Nov 2012 15:01:42 -0800 Subject: RFR (XL): 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() In-Reply-To: <9FA13D58-7069-4428-A82C-42A33D1E990F@oracle.com> References: <330A47A4-3251-461D-8C70-5752203A1344@oracle.com> <9FA13D58-7069-4428-A82C-42A33D1E990F@oracle.com> Message-ID: <50AD5D56.7050001@oracle.com> Good. Vladimir On 11/21/12 14:41, Christian Thalinger wrote: > > On Nov 20, 2012, at 8:13 PM, Vladimir Kozlov wrote: > >> Could you factor out the assert in callnode.hpp? > > Done. > >> >> graphKit.cpp: >> >> + // If the bytecode needs to be reexecuted we need a stack pointer with >> + // the arguments on the stack. >> ---- >> + // If the bytecode needs to be reexecuted we need to put >> + // the arguments back on the stack. >> >> + // NOTE: set_bci (called from sync_jvms) might reset the reexecute bit to >> + // undefined if the bci is different. This is okay for Parse but is a >> + // problem for LibraryCallKit where we explicitly set the reexecute bit. >> ---- >> + // NOTE: set_bci (called from sync_jvms) will reset the reexecute bit to >> + // undefined if the bci is different. This is normal for Parse but it >> + // should not happen for LibraryCallKit because only one bci is processed. > > Done. webrev updated. > > -- Chris > >> Thanks, >> Vladimir K. >> >> On Nov 20, 2012, at 6:47 PM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/7172640 >>> >>> 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() >>> Reviewed-by: >>> >>> Most intrinsics in LibraryCallKit re-push the arguments that have been >>> popped off before the call to just pop them again as arguments. It >>> would be much cleaner and more correct to use argument() accessors >>> instead. >>> >>> Another problem is that it is very tricky to find the places where the >>> stack pointer needs to be adjusted to the correct value for >>> re-execution (uncommon traps). This adjustment is a plain SP bump and >>> decrease after the call. In itself very error prone and it could be >>> handled in a much more elegant way. >>> >>> src/share/vm/ci/ciMethod.cpp >>> src/share/vm/ci/ciMethod.hpp >>> src/share/vm/ci/ciSignature.hpp >>> src/share/vm/interpreter/bytecodes.hpp >>> src/share/vm/opto/callGenerator.cpp >>> src/share/vm/opto/callnode.hpp >>> src/share/vm/opto/doCall.cpp >>> src/share/vm/opto/graphKit.cpp >>> src/share/vm/opto/graphKit.hpp >>> src/share/vm/opto/library_call.cpp >>> src/share/vm/opto/parse1.cpp >>> src/share/vm/opto/parse2.cpp >>> src/share/vm/opto/parse3.cpp >>> src/share/vm/opto/parseHelper.cpp >>> src/share/vm/opto/type.hpp >>> >> > From christian.thalinger at oracle.com Wed Nov 21 15:05:33 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Nov 2012 15:05:33 -0800 Subject: RFR (XL): 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() In-Reply-To: <50AD5D56.7050001@oracle.com> References: <330A47A4-3251-461D-8C70-5752203A1344@oracle.com> <9FA13D58-7069-4428-A82C-42A33D1E990F@oracle.com> <50AD5D56.7050001@oracle.com> Message-ID: <3CE9AA8E-9224-46A4-8A7D-788BB1BC3D9D@oracle.com> Thank you, Vladimir. -- Chris On Nov 21, 2012, at 3:01 PM, Vladimir Kozlov wrote: > Good. > > Vladimir > > On 11/21/12 14:41, Christian Thalinger wrote: >> >> On Nov 20, 2012, at 8:13 PM, Vladimir Kozlov wrote: >> >>> Could you factor out the assert in callnode.hpp? >> >> Done. >> >>> >>> graphKit.cpp: >>> >>> + // If the bytecode needs to be reexecuted we need a stack pointer with >>> + // the arguments on the stack. >>> ---- >>> + // If the bytecode needs to be reexecuted we need to put >>> + // the arguments back on the stack. >>> >>> + // NOTE: set_bci (called from sync_jvms) might reset the reexecute bit to >>> + // undefined if the bci is different. This is okay for Parse but is a >>> + // problem for LibraryCallKit where we explicitly set the reexecute bit. >>> ---- >>> + // NOTE: set_bci (called from sync_jvms) will reset the reexecute bit to >>> + // undefined if the bci is different. This is normal for Parse but it >>> + // should not happen for LibraryCallKit because only one bci is processed. >> >> Done. webrev updated. >> >> -- Chris >> >>> Thanks, >>> Vladimir K. >>> >>> On Nov 20, 2012, at 6:47 PM, Christian Thalinger wrote: >>> >>>> http://cr.openjdk.java.net/~twisti/7172640 >>>> >>>> 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() >>>> Reviewed-by: >>>> >>>> Most intrinsics in LibraryCallKit re-push the arguments that have been >>>> popped off before the call to just pop them again as arguments. It >>>> would be much cleaner and more correct to use argument() accessors >>>> instead. >>>> >>>> Another problem is that it is very tricky to find the places where the >>>> stack pointer needs to be adjusted to the correct value for >>>> re-execution (uncommon traps). This adjustment is a plain SP bump and >>>> decrease after the call. In itself very error prone and it could be >>>> handled in a much more elegant way. >>>> >>>> src/share/vm/ci/ciMethod.cpp >>>> src/share/vm/ci/ciMethod.hpp >>>> src/share/vm/ci/ciSignature.hpp >>>> src/share/vm/interpreter/bytecodes.hpp >>>> src/share/vm/opto/callGenerator.cpp >>>> src/share/vm/opto/callnode.hpp >>>> src/share/vm/opto/doCall.cpp >>>> src/share/vm/opto/graphKit.cpp >>>> src/share/vm/opto/graphKit.hpp >>>> src/share/vm/opto/library_call.cpp >>>> src/share/vm/opto/parse1.cpp >>>> src/share/vm/opto/parse2.cpp >>>> src/share/vm/opto/parse3.cpp >>>> src/share/vm/opto/parseHelper.cpp >>>> src/share/vm/opto/type.hpp >>>> >>> >> From john.r.rose at oracle.com Wed Nov 21 15:56:31 2012 From: john.r.rose at oracle.com (John Rose) Date: Wed, 21 Nov 2012 15:56:31 -0800 Subject: RFR (XL): 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() In-Reply-To: References: Message-ID: <0BFEB1D7-836F-4F5D-9D05-A89EE16D4821@oracle.com> On Nov 20, 2012, at 6:47 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/7172640 That's a lovely cleanup. The "to push or not to push" stuff around null checks is swept to the background. The reexecute_sp cut point clears things up nicely. I especially like that GraphKit::_sp is now private. The helper methods like get_field_at_bci are tasteful. The huge swaths of code deletion are great. The number of deleted lines is twice as big as the number of inserted lines! A few comments: I think the call to "kit.push_result()" should be guarded (internally or externally) by "kit.stopped()". The guard "result != NULL" is a little off, though it probably doesn't hurt. I don't think do_null_check_receiver pulls its weight, though it's OK. Are you sure the argument(0) value can never be top? That would make the assert fail. If you delete the assert, then there's nothing interesting in that method. (It seems that null_check_common now wants to be called "do_null_check_common". Actually, the whole "do_" prefix thing is bogus noise. Maybe we can undo "do_" now for those functions?) ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121121/4ff67d48/attachment.html From Vladimir.Kozlov at oracle.com Wed Nov 21 16:13:25 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Nov 2012 16:13:25 -0800 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50ACCE8F.1080701@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> <509D3EE3.303@oracle.com> <50ABDC69.8050604@oracle.com> <50ACCE8F.1080701@oracle.com> Message-ID: <50AD6E25.3080100@oracle.com> On 11/21/12 04:52, Vladimir Ivanov wrote: > Few minor comments: > > src/share/vm/opto/compile.cpp: > +static inline bool NotANode(const Node* n) { > Can you rename it to something like not_a_node? Camel style names aren't > common in the codebase. > > if (_log != NULL) { > - _log->done("phase nodes='%d'", C->unique()); > + _log->done("phase name='%s'", _phase_name); > } > Phase name is redundant here - it duplicates info from the head. But I It is not redundant with nested phases and big methods you don't see the head so it is nice to see which phase ends. > would leave nodes count as is and add live nodes count. Agree. It could be duplicated in the head of the following phase but more info is good. Vladimir K. > > Best regards, > Vladimir Ivanov > > On 11/20/12 10:39 PM, Bharadwaj Yadavalli wrote: >> >> Please review the updated webrev at >> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ >> >> Hopefully I have addressed all the review comments/suggestions. >> >> Thanks, >> >> Bharadwaj >> >> On 11/9/2012 12:35 PM, Vladimir Kozlov wrote: >>> Bharadwaj, >>> >>> Nils just reminded me (for his changes) that you need to fix our >>> LogCompilation parsing tool to recognize new "unique='n' >>> live_tracked='n'" values (old was "nodes='n'"): >>> >>> src/share/tools/LogCompilation/ >>> >>> Also live_tracked could be simple "live". >>> >>> Thanks, >>> Vladimir >>> >>> Vladimir Kozlov wrote: >>>> VerifyIdealNodeCount flag should be also notproduct since it is used >>>> only in debug VM. >>>> >>>> The next assert is not needed because it duplicates assert in >>>> live_nodes(): >>>> >>>> bool check_node_count(uint margin, const char* reason) { >>>> if (unique() + margin > (uint)MaxNodeLimit) { >>>> + assert(dead_node_count() <= unique(), "number of dead nodes >>>> more than created"); >>>> >>>> Also don't split the assert in live_nodes() into 2 lines and maybe >>>> use err_msg_res() to print _unique and _dead_node_count values. Also >>>> I think it should return unsigned int type value as unique() method. >>>> >>>> Second Compile() constructor does not set _dead_node_count(0). >>>> >>>> count_live_nodes_by_graph_walk() and NotANode() methods are now used >>>> only in debug code so put them under #ifdef ASSERT. >>>> >>>> >>>> print_missing_nodes() should call count_live_nodes_by_graph_walk() >>>> instead of duplicating code. And it should print to _log itself. >>>> TracePhase() code will have only call to it: >>>> >>>> 3133 if (VerifyIdealNodeCount) { >>>> 3134 Compile::current()->print_missing_nodes(); >>>> 3135 } >>>> >>>> And do not check VerifyIdealNodeCount in print_missing_nodes() to >>>> allow call it in debugger without VerifyIdealNodeCount set. >>>> >>>> I think VerifyIdealNodeCount code should be in ~TracePhase() (end of >>>> phase). >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Bharadwaj Yadavalli wrote: >>>>> Addressed comments on my previous RFR. Changes at >>>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_02/ >>>>> >>>>> These changes are made to keep an (almost) accurate running count of >>>>> the reachable (live) flow graph nodes. This will result in a more >>>>> realistic node count for various phases of C2 to decide on whether >>>>> to proceed with optimizations or not. Prior to these changes, C2 >>>>> bails out of compilation based on the number of nodes created which >>>>> typically larger than the number of reachable (live) nodes. >>>>> From christian.thalinger at oracle.com Wed Nov 21 17:02:12 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Nov 2012 17:02:12 -0800 Subject: RFR (XL): 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() In-Reply-To: <0BFEB1D7-836F-4F5D-9D05-A89EE16D4821@oracle.com> References: <0BFEB1D7-836F-4F5D-9D05-A89EE16D4821@oracle.com> Message-ID: On Nov 21, 2012, at 3:56 PM, John Rose wrote: > On Nov 20, 2012, at 6:47 PM, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/7172640 > > That's a lovely cleanup. The "to push or not to push" stuff around null checks is swept to the background. The reexecute_sp cut point clears things up nicely. > > I especially like that GraphKit::_sp is now private. The helper methods like get_field_at_bci are tasteful. > > The huge swaths of code deletion are great. The number of deleted lines is twice as big as the number of inserted lines! > > A few comments: > > I think the call to "kit.push_result()" should be guarded (internally or externally) by "kit.stopped()". The guard "result != NULL" is a little off, though it probably doesn't hurt. Yes. Done. > > I don't think do_null_check_receiver pulls its weight, though it's OK. Are you sure the argument(0) value can never be top? That would make the assert fail. If you delete the assert, then there's nothing interesting in that method. Hmm. No, I'm not sure is can never be top. I added do_null_check_receiver to emphasize that we are checking a receiver. Maybe we don't need it? > > (It seems that null_check_common now wants to be called "do_null_check_common". Actually, the whole "do_" prefix thing is bogus noise. Maybe we can undo "do_" now for those functions?) Good idea. I removed all the do_ prefixes. Additionally I added default parameters because we almost always pass in T_OBJECT. webrev is updated. -- Chris > > ? John From goetz.lindenmaier at sap.com Thu Nov 22 08:51:03 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 22 Nov 2012 17:51:03 +0100 Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] In-Reply-To: References: <140FA3E3585AD840A3316D2853F974DC1BF6672CB3@DEWDFECCR03.wdf.sap.corp> <9436FC33-1E4D-41DD-9D54-8CE11D718BC2@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF6673783@DEWDFECCR03.wdf.sap.corp> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF6931DF6@DEWDFECCR03.wdf.sap.corp> Hi Chris, We put it into the ad file because it describes an offset into the stub that is generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), used by ir node CallStaticJavaDirect. Maybe I should not call it stub, but it's generated into the stubs section of the code buffer. If that stub generator is moved out of the ad file to shared compiler code, one should move the field with it, but for the current implementation I think that's fine. Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature? If so, one could protect the whole thing by #ifdef COMPILER2. Thanks for all the bugids! Best regards, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Mittwoch, 21. November 2012 19:53 To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz" wrote: > Hi Chris, > > yes, there is no C1 on ppc. > We do tiered compilation with a stripped C2. Right. But some other architecture (or in the future) might need this for C1 as well. We should find a better place for the value than the ad file. The obvious place would be compiledIC_.hpp but we don't have that file, yet. I filed: 8003853: specify offset of IC load in java_to_interp stub -- Chris > > Best regards, > Goetz > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Dienstag, 20. November 2012 22:19 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub. > > > On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" wrote: > >> Hi, >> >> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub >> to update the IC with NativeMovConstReg. The current implementation assumes that >> the load is always the first instruction in the stub. This is an artificial restriction. E.g., >> it might be useful to load the constant pool address (MachConstantBase) before the >> IC load (as we do on PPC). >> >> This change adds a constant specifying an offset from the beginning of the stub to >> the IC load. The offset is platform specific and 0 on sparc and x86. >> >> You can find the change here: >> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/ > > That should be fixed indeed. > > +#ifndef COMPILER2 > +const int CompiledStaticCall::comp_to_int_load_offset = 0; > > There is no C1 for PPC (sorry, I didn't check)? > > -- Chris > >> >> or in our ppc port: >> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 >> >> Thank you and best regards, >> Goetz >> >> >> > From xerox.time.tech at gmail.com Thu Nov 22 09:00:36 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Thu, 22 Nov 2012 12:00:36 -0500 Subject: Turn off All Optimizations Message-ID: Is there a way to turn off all the optimizations the hotpot compiler will do to the bytecode when JITting it. Xin From aleksey.shipilev at oracle.com Thu Nov 22 09:06:56 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 22 Nov 2012 21:06:56 +0400 Subject: Turn off All Optimizations In-Reply-To: References: Message-ID: <50AE5BB0.6040404@oracle.com> On 11/22/2012 09:00 PM, Xin Tong wrote: > Is there a way to turn off all the optimizations the hotpot compiler > will do to the bytecode when JITting it. Use plain old interpreter with "-Xint"? -Aleksey. From xerox.time.tech at gmail.com Thu Nov 22 09:18:50 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Thu, 22 Nov 2012 12:18:50 -0500 Subject: Turn off All Optimizations In-Reply-To: <50AE5BB0.6040404@oracle.com> References: <50AE5BB0.6040404@oracle.com> Message-ID: I want the compiler to compile the code at the same time. i.e. i want to study why the compiler is so much faster than the intepreter from a microarchitectural point of view. enabling optimizations complicates the problem. there are 2 compilers in the hotspot, the c1 and opto. which one is used ? Xin On Thu, Nov 22, 2012 at 12:06 PM, Aleksey Shipilev wrote: > On 11/22/2012 09:00 PM, Xin Tong wrote: >> Is there a way to turn off all the optimizations the hotpot compiler >> will do to the bytecode when JITting it. > > Use plain old interpreter with "-Xint"? > > -Aleksey. > From krystal.mo at oracle.com Thu Nov 22 11:11:38 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Fri, 23 Nov 2012 03:11:38 +0800 Subject: Turn off All Optimizations In-Reply-To: References: <50AE5BB0.6040404@oracle.com> Message-ID: <50AE78EA.2000109@oracle.com> Hi Xin, So what you're looking for is some kind of baseline compiler, right? How does your study relate to the ones on different threading techniques for implementing interpreters? e.g. context-threading / inline-threading? Unfortunately neither C1 nor C2 has a magic switch to turn off all optimizations. Turning code into SSA-form and back is already "optimizing" in a lot of cases; both C1 and C2 use SSA-form intermediate representations, so it wouldn't be reasonable to have such a magic switch. If you're using the client VM, then you'd be using C1; If you're using the server VM, and if tiered compilation is not turned on (e.g. it's not turned on by default on JDK6 and JDK7 to date), then you'd be using C2; With tiered compilation, you'd be using both C1 and C2. A method could be compiled multiple times by either compilers. - Kris On 2012/11/23 1:18, Xin Tong wrote: > I want the compiler to compile the code at the same time. i.e. i want > to study why the compiler is so much faster than the intepreter from a > microarchitectural point of view. enabling optimizations complicates > the problem. > > there are 2 compilers in the hotspot, the c1 and opto. which one is used ? > > Xin > > On Thu, Nov 22, 2012 at 12:06 PM, Aleksey Shipilev > wrote: >> On 11/22/2012 09:00 PM, Xin Tong wrote: >>> Is there a way to turn off all the optimizations the hotpot compiler >>> will do to the bytecode when JITting it. >> Use plain old interpreter with "-Xint"? >> >> -Aleksey. >> From goetz.lindenmaier at sap.com Thu Nov 22 13:53:57 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 22 Nov 2012 22:53:57 +0100 Subject: RFR (S): 8003850: add support for constants in stub code [Was: Re: RFR (S): Issue constants to constant pool in stub code] In-Reply-To: <139AA4B4-0875-4E3E-BEFE-D1F33E37011C@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> <201207F2-DC70-4DDC-8CA2-F7D25E0FAE82@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF667377D@DEWDFECCR03.wdf.sap.corp> <139AA4B4-0875-4E3E-BEFE-D1F33E37011C@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF699BB90@DEWDFECCR03.wdf.sap.corp> Hi Chris, I fixed the other constants and renamed the webrev: http://cr.openjdk.java.net/~goetz/webrevs/8003850/ Cheers, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Wednesday, November 21, 2012 7:45 PM To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net Subject: RFR (S): 8003850: add support for constants in stub code [Was: Re: RFR (S): Issue constants to constant pool in stub code] On Nov 21, 2012, at 12:14 AM, "Lindenmaier, Goetz" wrote: > Hi Christian, > > you're right, I should fix the other constants too. > I also can kick out the end_a_const() without argument, as it's no more needed, then. I filed: 8003850: add support for constants in stub code -- Chris > > Thanks, > Goetz. > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Dienstag, 20. November 2012 22:11 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (S): Issue constants to constant pool in stub code > > > On Nov 20, 2012, at 2:05 AM, "Lindenmaier, Goetz" wrote: > >> Hi, >> >> When adding constants to the constant pool, the code_section is switched >> to the constant pool code_section, and then back again. It was hard coded >> to switch back to the code_section for code. >> If constants are issued in stubs, it is switched back to the wrong code section. >> I changed the code to remember the code section and switch back to the proper >> one. >> Further it's necessary to relocate only after copying code and stub section to >> a new location, as the relocation might affect an address in the stub section. >> >> You can find these changes here: >> http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/ > > That's a nice fix. Recently I touched this code and I was worried about that also. I suppose on PPC you only use address_constant in stubs. What about the other constant emitting methods? > > -- Chris > >> >> or in our ppc port: >> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062 >> >> Thank you and best regards, >> Goetz >> > From vladimir.x.ivanov at oracle.com Thu Nov 22 15:13:05 2012 From: vladimir.x.ivanov at oracle.com (vladimir.x.ivanov at oracle.com) Date: Thu, 22 Nov 2012 23:13:05 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8001538: hs_err file does not list anymore compiled methods in compilation events Message-ID: <20121122231313.B4D7347AE6@hg.openjdk.java.net> Changeset: ee32440febeb Author: vlivanov Date: 2012-11-21 05:57 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/ee32440febeb 8001538: hs_err file does not list anymore compiled methods in compilation events Summary: Fixed message buffer size calculation. Reviewed-by: kvn, twisti ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/utilities/events.hpp From mikael.vidstedt at oracle.com Thu Nov 22 17:54:05 2012 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 22 Nov 2012 17:54:05 -0800 Subject: Removing LogCleanUpReader In-Reply-To: <50A51FA0.6050404@oracle.com> References: <50A4B1E4.8040805@oracle.com> <50A51FA0.6050404@oracle.com> Message-ID: <50AED73D.2020207@oracle.com> That in itself isn't a reason to keep it, you can always get the code from the version control system. More important is whether it's helpful for the current sources and if anybody is actually using it? Cheers, Mikael On 2012-11-15 09:00, Vladimir Kozlov wrote: > No, keep it. LogCompilation tool is not release dependent so we can > build it from current sources and use it to parse logs from previous > jdk releases. > > Vladimir > > On 11/15/12 01:12, Nils Eliasson wrote: >> Anyone against removing the LogCleanUpReader from share/tools? >> >> According to the comments it was used for 1.5/1.6 to handle malformed >> xml from LogCompilation. >> >> //Nils From xerox.time.tech at gmail.com Thu Nov 22 22:43:53 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Fri, 23 Nov 2012 01:43:53 -0500 Subject: Turn off All Optimizations In-Reply-To: <50AE78EA.2000109@oracle.com> References: <50AE5BB0.6040404@oracle.com> <50AE78EA.2000109@oracle.com> Message-ID: On Thu, Nov 22, 2012 at 2:11 PM, Krystal Mo wrote: > Hi Xin, > > So what you're looking for is some kind of baseline compiler, right? > How does your study relate to the ones on different threading techniques for > implementing interpreters? e.g. context-threading / inline-threading? I want to exam why interpreter is slower than the JIT. it is commonly believed (easily verifiable) that interpreter is typically much slower than the JIT. but no one ( at least i am not aware of) has ever fully investigated why. i want to look at the performance differences from a microarchitectural point of view., including the following 1. branch prediction 2. instruction cache 3. data cache 4. dynamic instruction count. 5. TLB. there may be more... different implementations of interpreters dohave impact on the results, but the context-threaded interpreter is believed to be more friendly than the simple switch based interpreter. > > Unfortunately neither C1 nor C2 has a magic switch to turn off all > optimizations. Turning code into SSA-form and back is already "optimizing" > in a lot of cases; both C1 and C2 use SSA-form intermediate representations, > so it wouldn't be reasonable to have such a magic switch. > I am modifying the opto compiler, trying to disable all the optimizations. however, I think the Node *nn = transform_old(n); in the PhaseIterGVN::optimize must be called for the compiler to work. does this transform the node to SSA representation which is later recognized by the code generator ? Are their any optimizations in the code generator as well, e.g. does hotspot run instruction scheduling ? Xin > If you're using the client VM, then you'd be using C1; > If you're using the server VM, and if tiered compilation is not turned on > (e.g. it's not turned on by default on JDK6 and JDK7 to date), then you'd be > using C2; > With tiered compilation, you'd be using both C1 and C2. A method could be > compiled multiple times by either compilers. > > - Kris > > > On 2012/11/23 1:18, Xin Tong wrote: >> >> I want the compiler to compile the code at the same time. i.e. i want >> to study why the compiler is so much faster than the intepreter from a >> microarchitectural point of view. enabling optimizations complicates >> the problem. >> >> there are 2 compilers in the hotspot, the c1 and opto. which one is used ? >> >> Xin >> >> On Thu, Nov 22, 2012 at 12:06 PM, Aleksey Shipilev >> wrote: >>> >>> On 11/22/2012 09:00 PM, Xin Tong wrote: >>>> >>>> Is there a way to turn off all the optimizations the hotpot compiler >>>> will do to the bytecode when JITting it. >>> >>> Use plain old interpreter with "-Xint"? >>> >>> -Aleksey. >>> > From Vladimir.Kozlov at oracle.com Thu Nov 22 23:12:46 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 22 Nov 2012 23:12:46 -0800 Subject: Removing LogCleanUpReader In-Reply-To: <50AED73D.2020207@oracle.com> References: <50A4B1E4.8040805@oracle.com> <50A51FA0.6050404@oracle.com> <50AED73D.2020207@oracle.com> Message-ID: <5634D59B-303B-46CB-94B8-D1B52F4F1328@oracle.com> Current version has more fixes in it and we can extract more information from logs from previous VM versions. Why kill compatibility if we can keep it without any cost to us? Regards, Vladimir On Nov 22, 2012, at 5:54 PM, Mikael Vidstedt wrote: > > That in itself isn't a reason to keep it, you can always get the code from the version control system. More important is whether it's helpful for the current sources and if anybody is actually using it? > > Cheers, > Mikael > > On 2012-11-15 09:00, Vladimir Kozlov wrote: >> No, keep it. LogCompilation tool is not release dependent so we can build it from current sources and use it to parse logs from previous jdk releases. >> >> Vladimir >> >> On 11/15/12 01:12, Nils Eliasson wrote: >>> Anyone against removing the LogCleanUpReader from share/tools? >>> >>> According to the comments it was used for 1.5/1.6 to handle malformed >>> xml from LogCompilation. >>> >>> //Nils > From vladimir.x.ivanov at oracle.com Fri Nov 23 06:19:28 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 23 Nov 2012 17:19:28 +0300 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50AD6E25.3080100@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> <509D3EE3.303@oracle.com> <50ABDC69.8050604@oracle.com> <50ACCE8F.1080701@oracle.com> <50AD6E25.3080100@oracle.com> Message-ID: <50AF85F0.3020103@oracle.com> >> if (_log != NULL) { >> - _log->done("phase nodes='%d'", C->unique()); >> + _log->done("phase name='%s'", _phase_name); >> } >> Phase name is redundant here - it duplicates info from the head. But I > > It is not redundant with nested phases and big methods you don't see the > head so it is nice to see which phase ends. Valid point. I'm not against this change, just looking at it from automated parsing perspective. Current format isn't human-friendly anyway :-) Best regards, Vladimir Ivanov >> would leave nodes count as is and add live nodes count. > > Agree. It could be duplicated in the head of the following phase but > more info is good. > > Vladimir K. > >> >> Best regards, >> Vladimir Ivanov >> >> On 11/20/12 10:39 PM, Bharadwaj Yadavalli wrote: >>> >>> Please review the updated webrev at >>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ >>> >>> Hopefully I have addressed all the review comments/suggestions. >>> >>> Thanks, >>> >>> Bharadwaj >>> >>> On 11/9/2012 12:35 PM, Vladimir Kozlov wrote: >>>> Bharadwaj, >>>> >>>> Nils just reminded me (for his changes) that you need to fix our >>>> LogCompilation parsing tool to recognize new "unique='n' >>>> live_tracked='n'" values (old was "nodes='n'"): >>>> >>>> src/share/tools/LogCompilation/ >>>> >>>> Also live_tracked could be simple "live". >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> Vladimir Kozlov wrote: >>>>> VerifyIdealNodeCount flag should be also notproduct since it is used >>>>> only in debug VM. >>>>> >>>>> The next assert is not needed because it duplicates assert in >>>>> live_nodes(): >>>>> >>>>> bool check_node_count(uint margin, const char* reason) { >>>>> if (unique() + margin > (uint)MaxNodeLimit) { >>>>> + assert(dead_node_count() <= unique(), "number of dead nodes >>>>> more than created"); >>>>> >>>>> Also don't split the assert in live_nodes() into 2 lines and maybe >>>>> use err_msg_res() to print _unique and _dead_node_count values. Also >>>>> I think it should return unsigned int type value as unique() method. >>>>> >>>>> Second Compile() constructor does not set _dead_node_count(0). >>>>> >>>>> count_live_nodes_by_graph_walk() and NotANode() methods are now used >>>>> only in debug code so put them under #ifdef ASSERT. >>>>> >>>>> >>>>> print_missing_nodes() should call count_live_nodes_by_graph_walk() >>>>> instead of duplicating code. And it should print to _log itself. >>>>> TracePhase() code will have only call to it: >>>>> >>>>> 3133 if (VerifyIdealNodeCount) { >>>>> 3134 Compile::current()->print_missing_nodes(); >>>>> 3135 } >>>>> >>>>> And do not check VerifyIdealNodeCount in print_missing_nodes() to >>>>> allow call it in debugger without VerifyIdealNodeCount set. >>>>> >>>>> I think VerifyIdealNodeCount code should be in ~TracePhase() (end of >>>>> phase). >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Bharadwaj Yadavalli wrote: >>>>>> Addressed comments on my previous RFR. Changes at >>>>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_02/ >>>>>> >>>>>> These changes are made to keep an (almost) accurate running count of >>>>>> the reachable (live) flow graph nodes. This will result in a more >>>>>> realistic node count for various phases of C2 to decide on whether >>>>>> to proceed with optimizations or not. Prior to these changes, C2 >>>>>> bails out of compilation based on the number of nodes created which >>>>>> typically larger than the number of reachable (live) nodes. >>>>>> From krystal.mo at oracle.com Mon Nov 26 01:51:43 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Mon, 26 Nov 2012 17:51:43 +0800 Subject: Turn off All Optimizations In-Reply-To: References: <50AE5BB0.6040404@oracle.com> <50AE78EA.2000109@oracle.com> Message-ID: <50B33BAF.5030103@oracle.com> Comments inline: On 11/23/2012 02:43 PM, Xin Tong wrote: > On Thu, Nov 22, 2012 at 2:11 PM, Krystal Mo wrote: >> Hi Xin, >> >> So what you're looking for is some kind of baseline compiler, right? >> How does your study relate to the ones on different threading techniques for >> implementing interpreters? e.g. context-threading / inline-threading? > I want to exam why interpreter is slower than the JIT. it is commonly > believed (easily verifiable) that interpreter is typically much slower > than the JIT. but no one ( at least i am not aware of) has ever fully > investigated why. i want to look at the performance differences from a > microarchitectural point of view., including the following > > 1. branch prediction > 2. instruction cache > 3. data cache > 4. dynamic instruction count. > 5. TLB. > > there may be more... > > different implementations of interpreters dohave impact on the > results, but the context-threaded interpreter is believed to be more > friendly than the simple switch based interpreter. A compiler that doesn't do any optimizations is a baseline compiler. Inline-threaded interpreter is basically equivalent to a baseline interpreter; another similar form is "template-based compiler". These can be found in some JVM implementations (but not in HotSpot, though). It looks like what you're trying to measure is the "interpretation overhead" of various forms of interpreters, comparing with a baseline that is "an interpreter with zero interpretation overhead, but no other optimizations applied". >> Unfortunately neither C1 nor C2 has a magic switch to turn off all >> optimizations. Turning code into SSA-form and back is already "optimizing" >> in a lot of cases; both C1 and C2 use SSA-form intermediate representations, >> so it wouldn't be reasonable to have such a magic switch. >> > I am modifying the opto compiler, trying to disable all the > optimizations. however, I think the Node *nn = > transform_old(n); in the PhaseIterGVN::optimize must be called for the > compiler to work. does this transform the node to SSA representation > which is later recognized by the code generator ? The Ideal Graph in C2 is already an SSA-form IR. Java bytecode (which is not in SSA-form) is converted into Ideal Graph during parsing, which is very early in the compilation process; you can't disable it without effectively throwing away the core of C2. Iterative GVN is a later phase. I'd imagine writing a new baseline compiler for HotSpot from scratch is easier than disabling all optimizations in C2 for your purpose. > Are their any optimizations in the code generator as well, e.g. does > hotspot run instruction scheduling ? C2 does global code motion and peephole optimizations in the code generator. - Kris > > Xin > >> If you're using the client VM, then you'd be using C1; >> If you're using the server VM, and if tiered compilation is not turned on >> (e.g. it's not turned on by default on JDK6 and JDK7 to date), then you'd be >> using C2; >> With tiered compilation, you'd be using both C1 and C2. A method could be >> compiled multiple times by either compilers. >> >> - Kris >> >> >> On 2012/11/23 1:18, Xin Tong wrote: >>> I want the compiler to compile the code at the same time. i.e. i want >>> to study why the compiler is so much faster than the intepreter from a >>> microarchitectural point of view. enabling optimizations complicates >>> the problem. >>> >>> there are 2 compilers in the hotspot, the c1 and opto. which one is used ? >>> >>> Xin >>> >>> On Thu, Nov 22, 2012 at 12:06 PM, Aleksey Shipilev >>> wrote: >>>> On 11/22/2012 09:00 PM, Xin Tong wrote: >>>>> Is there a way to turn off all the optimizations the hotpot compiler >>>>> will do to the bytecode when JITting it. >>>> Use plain old interpreter with "-Xint"? >>>> >>>> -Aleksey. >>>> From nils.eliasson at oracle.com Mon Nov 26 07:04:11 2012 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 26 Nov 2012 16:04:11 +0100 Subject: RFR(S): 8003983 Fix of broken logcompilation tool Message-ID: <50B384EB.4030207@oracle.com> Fixing LogCompilation tool so that I can do my own additions later. Includes fixes for: c1 missing parse tag that is required to surround method tag c1 call tag requires count attribute c1 phase tag requires nodes (set to zero since there is no nodes concept in c1) Method tag must handle missing bytes, iicount and flags attributes when unloading=1 is set Wrong description in help for '-n'. http://cr.openjdk.java.net/~neliasso/8003983/webrev.01/ Tested with running HelloDate on tiered with -Xcomp. Will add this as jtreg test separately. Thanks, Nils Eliasson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121126/3f19131a/attachment.html From mikael.vidstedt at oracle.com Mon Nov 26 08:45:33 2012 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 26 Nov 2012 08:45:33 -0800 Subject: Removing LogCleanUpReader In-Reply-To: <5634D59B-303B-46CB-94B8-D1B52F4F1328@oracle.com> References: <50A4B1E4.8040805@oracle.com> <50A51FA0.6050404@oracle.com> <50AED73D.2020207@oracle.com> <5634D59B-303B-46CB-94B8-D1B52F4F1328@oracle.com> Message-ID: <50B39CAD.1000201@oracle.com> I don't know how this exact tool is being used, but we can continue improving it in the older branches if needed. If it doesn't work with the current version it should be deprecated and removed, otherwise we'll just end up with lots of effectively dead code over time, right? Cheers, Mikael On 11/22/2012 11:12 PM, Vladimir Kozlov wrote: > Current version has more fixes in it and we can extract more information from logs from previous VM versions. Why kill compatibility if we can keep it without any cost to us? > > Regards, > Vladimir > > On Nov 22, 2012, at 5:54 PM, Mikael Vidstedt wrote: > >> That in itself isn't a reason to keep it, you can always get the code from the version control system. More important is whether it's helpful for the current sources and if anybody is actually using it? >> >> Cheers, >> Mikael >> >> On 2012-11-15 09:00, Vladimir Kozlov wrote: >>> No, keep it. LogCompilation tool is not release dependent so we can build it from current sources and use it to parse logs from previous jdk releases. >>> >>> Vladimir >>> >>> On 11/15/12 01:12, Nils Eliasson wrote: >>>> Anyone against removing the LogCleanUpReader from share/tools? >>>> >>>> According to the comments it was used for 1.5/1.6 to handle malformed >>>> xml from LogCompilation. >>>> >>>> //Nils From Vladimir.Kozlov at oracle.com Mon Nov 26 11:30:02 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 26 Nov 2012 11:30:02 -0800 Subject: RFR(S): 8003983 Fix of broken logcompilation tool In-Reply-To: <50B384EB.4030207@oracle.com> References: <50B384EB.4030207@oracle.com> Message-ID: <50B3C33A.8090109@oracle.com> Looks good. Thanks, Vladimir On 11/26/12 07:04, Nils Eliasson wrote: > Fixing LogCompilation tool so that I can do my own additions later. > > Includes fixes for: > c1 missing parse tag that is required to surround method tag > c1 call tag requires count attribute > c1 phase tag requires nodes (set to zero since there is no nodes concept > in c1) > Method tag must handle missing bytes, iicount and flags attributes when > unloading=1 is set > Wrong description in help for '-n'. > > http://cr.openjdk.java.net/~neliasso/8003983/webrev.01/ > > Tested with running HelloDate on tiered with -Xcomp. Will add this as > jtreg test separately. > > Thanks, > Nils Eliasson From Vladimir.Kozlov at oracle.com Mon Nov 26 15:28:01 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 26 Nov 2012 15:28:01 -0800 Subject: RFR (S): 8003850: add support for constants in stub code [Was: Re: RFR (S): Issue constants to constant pool in stub code] In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF699BB90@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> <201207F2-DC70-4DDC-8CA2-F7D25E0FAE82@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF667377D@DEWDFECCR03.wdf.sap.corp> <139AA4B4-0875-4E3E-BEFE-D1F33E37011C@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BB90@DEWDFECCR03.wdf.sap.corp> Message-ID: <50B3FB01.6090409@oracle.com> Goetz, This looks good. Few suggestions: 1. Change the first comment line (coping is done already): < // First copy all sections, then relocate. --- > // Do relocation after all sections are copied. 2. Use SECT_FIRST as in the original loop to show that second loop iterates over the same sections. Thanks, Vladimir On 11/22/12 13:53, Lindenmaier, Goetz wrote: > Hi Chris, > > I fixed the other constants and renamed the webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8003850/ > > Cheers, > Goetz. > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Wednesday, November 21, 2012 7:45 PM > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: RFR (S): 8003850: add support for constants in stub code [Was: Re: RFR (S): Issue constants to constant pool in stub code] > > > On Nov 21, 2012, at 12:14 AM, "Lindenmaier, Goetz" wrote: > >> Hi Christian, >> >> you're right, I should fix the other constants too. >> I also can kick out the end_a_const() without argument, as it's no more needed, then. > > I filed: > > 8003850: add support for constants in stub code > > -- Chris > >> >> Thanks, >> Goetz. >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Dienstag, 20. November 2012 22:11 >> To: Lindenmaier, Goetz >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR (S): Issue constants to constant pool in stub code >> >> >> On Nov 20, 2012, at 2:05 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi, >>> >>> When adding constants to the constant pool, the code_section is switched >>> to the constant pool code_section, and then back again. It was hard coded >>> to switch back to the code_section for code. >>> If constants are issued in stubs, it is switched back to the wrong code section. >>> I changed the code to remember the code section and switch back to the proper >>> one. >>> Further it's necessary to relocate only after copying code and stub section to >>> a new location, as the relocation might affect an address in the stub section. >>> >>> You can find these changes here: >>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/ >> >> That's a nice fix. Recently I touched this code and I was worried about that also. I suppose on PPC you only use address_constant in stubs. What about the other constant emitting methods? >> >> -- Chris >> >>> >>> or in our ppc port: >>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062 >>> >>> Thank you and best regards, >>> Goetz >>> >> > From christian.thalinger at oracle.com Mon Nov 26 16:53:19 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 26 Nov 2012 16:53:19 -0800 Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF6931DF6@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6672CB3@DEWDFECCR03.wdf.sap.corp> <9436FC33-1E4D-41DD-9D54-8CE11D718BC2@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF6673783@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6931DF6@DEWDFECCR03.wdf.sap.corp> Message-ID: On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz" wrote: > Hi Chris, > > We put it into the ad file because it describes an offset into the stub that is > generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), > used by ir node CallStaticJavaDirect. Maybe I should not call it stub, but it's > generated into the stubs section of the code buffer. > If that stub generator is moved out of the ad file to shared compiler code, one should > move the field with it, but for the current implementation I think that's fine. > > Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature? > If so, one could protect the whole thing by #ifdef COMPILER2. Why do you need all these shared code changes when you have this in emit_java_to_interp_stub? // Create a static stub relocation which relates this stub // with the call instruction at insts_call_instruction_offset in the // instructions code-section. __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset)); Do you need two relocations? I'm confused. -- Chris > > Thanks for all the bugids! > > Best regards, > Goetz. > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Mittwoch, 21. November 2012 19:53 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] > > > On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz" wrote: > >> Hi Chris, >> >> yes, there is no C1 on ppc. >> We do tiered compilation with a stripped C2. > > Right. But some other architecture (or in the future) might need this for C1 as well. We should find a better place for the value than the ad file. The obvious place would be compiledIC_.hpp but we don't have that file, yet. > > I filed: > > 8003853: specify offset of IC load in java_to_interp stub > > -- Chris > >> >> Best regards, >> Goetz >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Dienstag, 20. November 2012 22:19 >> To: Lindenmaier, Goetz >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub. >> >> >> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi, >>> >>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub >>> to update the IC with NativeMovConstReg. The current implementation assumes that >>> the load is always the first instruction in the stub. This is an artificial restriction. E.g., >>> it might be useful to load the constant pool address (MachConstantBase) before the >>> IC load (as we do on PPC). >>> >>> This change adds a constant specifying an offset from the beginning of the stub to >>> the IC load. The offset is platform specific and 0 on sparc and x86. >>> >>> You can find the change here: >>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/ >> >> That should be fixed indeed. >> >> +#ifndef COMPILER2 >> +const int CompiledStaticCall::comp_to_int_load_offset = 0; >> >> There is no C1 for PPC (sorry, I didn't check)? >> >> -- Chris >> >>> >>> or in our ppc port: >>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 >>> >>> Thank you and best regards, >>> Goetz >>> >>> >>> >> > From christian.thalinger at oracle.com Mon Nov 26 17:22:20 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 26 Nov 2012 17:22:20 -0800 Subject: RFR (XL): 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() In-Reply-To: References: <0BFEB1D7-836F-4F5D-9D05-A89EE16D4821@oracle.com> Message-ID: <7802D95E-898E-4345-822E-84D1BF8689DF@oracle.com> I made a couple of smaller changes based on a verbal review from John: - removed (void) casts for null_check* calls - renamed null_check_receiver_as_before_call to null_check_receiver_before_call - removed for_parse argument to GraphKit::compute_stack_effects webrev is updated and I'm going to push that change now. Thanks. -- Chris On Nov 21, 2012, at 5:02 PM, Christian Thalinger wrote: > > On Nov 21, 2012, at 3:56 PM, John Rose wrote: > >> On Nov 20, 2012, at 6:47 PM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/7172640 >> >> That's a lovely cleanup. The "to push or not to push" stuff around null checks is swept to the background. The reexecute_sp cut point clears things up nicely. >> >> I especially like that GraphKit::_sp is now private. The helper methods like get_field_at_bci are tasteful. >> >> The huge swaths of code deletion are great. The number of deleted lines is twice as big as the number of inserted lines! >> >> A few comments: >> >> I think the call to "kit.push_result()" should be guarded (internally or externally) by "kit.stopped()". The guard "result != NULL" is a little off, though it probably doesn't hurt. > > Yes. Done. > >> >> I don't think do_null_check_receiver pulls its weight, though it's OK. Are you sure the argument(0) value can never be top? That would make the assert fail. If you delete the assert, then there's nothing interesting in that method. > > Hmm. No, I'm not sure is can never be top. I added do_null_check_receiver to emphasize that we are checking a receiver. Maybe we don't need it? > >> >> (It seems that null_check_common now wants to be called "do_null_check_common". Actually, the whole "do_" prefix thing is bogus noise. Maybe we can undo "do_" now for those functions?) > > Good idea. I removed all the do_ prefixes. Additionally I added default parameters because we almost always pass in T_OBJECT. > > webrev is updated. > > -- Chris > >> >> ? John > From christian.thalinger at oracle.com Mon Nov 26 20:02:23 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 27 Nov 2012 04:02:23 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() Message-ID: <20121127040227.DF77E47B35@hg.openjdk.java.net> Changeset: beebba0acc11 Author: twisti Date: 2012-11-26 17:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/beebba0acc11 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() Reviewed-by: kvn, jrose ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/type.hpp From john.r.rose at oracle.com Mon Nov 26 22:21:15 2012 From: john.r.rose at oracle.com (John Rose) Date: Mon, 26 Nov 2012 22:21:15 -0800 Subject: RFR (XL): 7172640: C2: instrinsic implementations in LibraryCallKit should use argument() instead of pop() In-Reply-To: References: <0BFEB1D7-836F-4F5D-9D05-A89EE16D4821@oracle.com> Message-ID: Reviewed; ship it. Some comments: The cleanups with Bytecodes::has_receiver and arg_size_for_bc are very good too. I like your renamings: It feels much more rational and regular. The for_parse argument to GraphKit::compute_stack_effects is dead now; you may delete it. I suggest removing "_as" in null_check_receiver_as_before_call; it feels like a "noise word"[1]. We are not in the habit of using "(void)" casts. I think it would require an astronomically high warning level to benefit from them. These are all suggestions. In any case, ship it! ? John [1] https://wikis.oracle.com/display/HotSpotInternals/StyleGuide#StyleGuide-Naming On Nov 21, 2012, at 5:02 PM, Christian Thalinger wrote: > On Nov 21, 2012, at 3:56 PM, John Rose wrote: > >> On Nov 20, 2012, at 6:47 PM, Christian Thalinger wrote: >> >>> http://cr.openjdk.java.net/~twisti/7172640 >> >> That's a lovely cleanup... > > webrev is updated. From goetz.lindenmaier at sap.com Tue Nov 27 01:22:46 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 27 Nov 2012 10:22:46 +0100 Subject: RFR (S): 8003850: add support for constants in stub code [Was: Re: RFR (S): Issue constants to constant pool in stub code] In-Reply-To: <50B3FB01.6090409@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> <201207F2-DC70-4DDC-8CA2-F7D25E0FAE82@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF667377D@DEWDFECCR03.wdf.sap.corp> <139AA4B4-0875-4E3E-BEFE-D1F33E37011C@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BB90@DEWDFECCR03.wdf.sap.corp> <50B3FB01.6090409@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF6C38D30@DEWDFECCR03.wdf.sap.corp> Hi Vladimir, You're right, good points, fixed: http://cr.openjdk.java.net/~goetz/webrevs/8003850/ Best regards, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:Vladimir.Kozlov at oracle.com] Sent: Dienstag, 27. November 2012 00:28 To: Lindenmaier, Goetz Cc: 'Christian Thalinger'; 'hotspot-compiler-dev at openjdk.java.net' Subject: Re: RFR (S): 8003850: add support for constants in stub code [Was: Re: RFR (S): Issue constants to constant pool in stub code] Goetz, This looks good. Few suggestions: 1. Change the first comment line (coping is done already): < // First copy all sections, then relocate. --- > // Do relocation after all sections are copied. 2. Use SECT_FIRST as in the original loop to show that second loop iterates over the same sections. Thanks, Vladimir On 11/22/12 13:53, Lindenmaier, Goetz wrote: > Hi Chris, > > I fixed the other constants and renamed the webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8003850/ > > Cheers, > Goetz. > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Wednesday, November 21, 2012 7:45 PM > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: RFR (S): 8003850: add support for constants in stub code [Was: Re: RFR (S): Issue constants to constant pool in stub code] > > > On Nov 21, 2012, at 12:14 AM, "Lindenmaier, Goetz" wrote: > >> Hi Christian, >> >> you're right, I should fix the other constants too. >> I also can kick out the end_a_const() without argument, as it's no more needed, then. > > I filed: > > 8003850: add support for constants in stub code > > -- Chris > >> >> Thanks, >> Goetz. >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Dienstag, 20. November 2012 22:11 >> To: Lindenmaier, Goetz >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR (S): Issue constants to constant pool in stub code >> >> >> On Nov 20, 2012, at 2:05 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi, >>> >>> When adding constants to the constant pool, the code_section is switched >>> to the constant pool code_section, and then back again. It was hard coded >>> to switch back to the code_section for code. >>> If constants are issued in stubs, it is switched back to the wrong code section. >>> I changed the code to remember the code section and switch back to the proper >>> one. >>> Further it's necessary to relocate only after copying code and stub section to >>> a new location, as the relocation might affect an address in the stub section. >>> >>> You can find these changes here: >>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/ >> >> That's a nice fix. Recently I touched this code and I was worried about that also. I suppose on PPC you only use address_constant in stubs. What about the other constant emitting methods? >> >> -- Chris >> >>> >>> or in our ppc port: >>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062 >>> >>> Thank you and best regards, >>> Goetz >>> >> > From goetz.lindenmaier at sap.com Tue Nov 27 04:24:42 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 27 Nov 2012 13:24:42 +0100 Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] In-Reply-To: References: <140FA3E3585AD840A3316D2853F974DC1BF6672CB3@DEWDFECCR03.wdf.sap.corp> <9436FC33-1E4D-41DD-9D54-8CE11D718BC2@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF6673783@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6931DF6@DEWDFECCR03.wdf.sap.corp> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF6C39002@DEWDFECCR03.wdf.sap.corp> Hi Chris, > Why do you need all these shared code changes when you have this in emit_java_to_interp_stub? Shared code (class CompiledStaticCall) wants to patch the inline cache in the stub which is emitted in platform code. So the platform code should specify how the shared code can find the inline cache in the stub, which it does through the constant I introduced. > Do you need two relocations? I'm confused. No, three ;) The relocation you mention is used to find the stub given the call. The other relocations are needed to find the inline cache / call target once the stub is found (see CompiledStaticCall::set_to_interpreted()). It's just the same on x86_64: // static stub relocation stores the instruction address of the call __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64); // static stub relocation also tags the methodOop in the code-stream. __ movoop(rbx, (jobject) NULL); // method is zapped till fixup time // This is recognized as unresolved by relocs/nativeinst/ic code __ jump(RuntimeAddress(__ pc())); On PPC, we have to load the base of the constant table after generating the static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is exactly what we store in the CompiledStaticCall::comp_to_int_load_offset constant. Best regards, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Dienstag, 27. November 2012 01:53 To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz" wrote: > Hi Chris, > > We put it into the ad file because it describes an offset into the stub that is > generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), > used by ir node CallStaticJavaDirect. Maybe I should not call it stub, but it's > generated into the stubs section of the code buffer. > If that stub generator is moved out of the ad file to shared compiler code, one should > move the field with it, but for the current implementation I think that's fine. > > Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature? > If so, one could protect the whole thing by #ifdef COMPILER2. Why do you need all these shared code changes when you have this in emit_java_to_interp_stub? // Create a static stub relocation which relates this stub // with the call instruction at insts_call_instruction_offset in the // instructions code-section. __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset)); Do you need two relocations? I'm confused. -- Chris > > Thanks for all the bugids! > > Best regards, > Goetz. > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Mittwoch, 21. November 2012 19:53 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] > > > On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz" wrote: > >> Hi Chris, >> >> yes, there is no C1 on ppc. >> We do tiered compilation with a stripped C2. > > Right. But some other architecture (or in the future) might need this for C1 as well. We should find a better place for the value than the ad file. The obvious place would be compiledIC_.hpp but we don't have that file, yet. > > I filed: > > 8003853: specify offset of IC load in java_to_interp stub > > -- Chris > >> >> Best regards, >> Goetz >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Dienstag, 20. November 2012 22:19 >> To: Lindenmaier, Goetz >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub. >> >> >> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi, >>> >>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub >>> to update the IC with NativeMovConstReg. The current implementation assumes that >>> the load is always the first instruction in the stub. This is an artificial restriction. E.g., >>> it might be useful to load the constant pool address (MachConstantBase) before the >>> IC load (as we do on PPC). >>> >>> This change adds a constant specifying an offset from the beginning of the stub to >>> the IC load. The offset is platform specific and 0 on sparc and x86. >>> >>> You can find the change here: >>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/ >> >> That should be fixed indeed. >> >> +#ifndef COMPILER2 >> +const int CompiledStaticCall::comp_to_int_load_offset = 0; >> >> There is no C1 for PPC (sorry, I didn't check)? >> >> -- Chris >> >>> >>> or in our ppc port: >>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 >>> >>> Thank you and best regards, >>> Goetz >>> >>> >>> >> > From Vladimir.Kozlov at oracle.com Tue Nov 27 08:31:16 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Nov 2012 08:31:16 -0800 Subject: RFR (S): 8003850: add support for constants in stub code [Was: Re: RFR (S): Issue constants to constant pool in stub code] In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF6C38D30@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6672B53@DEWDFECCR03.wdf.sap.corp> <201207F2-DC70-4DDC-8CA2-F7D25E0FAE82@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF667377D@DEWDFECCR03.wdf.sap.corp> <139AA4B4-0875-4E3E-BEFE-D1F33E37011C@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF699BB90@DEWDFECCR03.wdf.sap.corp> <50B3FB01.6090409@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF6C38D30@DEWDFECCR03.wdf.sap.corp> Message-ID: Good. We will push it today. Thanks, Vladimir On Nov 27, 2012, at 1:22 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > You're right, good points, fixed: > http://cr.openjdk.java.net/~goetz/webrevs/8003850/ > > Best regards, > Goetz. > > -----Original Message----- > From: Vladimir Kozlov [mailto:Vladimir.Kozlov at oracle.com] > Sent: Dienstag, 27. November 2012 00:28 > To: Lindenmaier, Goetz > Cc: 'Christian Thalinger'; 'hotspot-compiler-dev at openjdk.java.net' > Subject: Re: RFR (S): 8003850: add support for constants in stub code [Was: Re: RFR (S): Issue constants to constant pool in stub code] > > Goetz, > > This looks good. Few suggestions: > > 1. Change the first comment line (coping is done already): > > < // First copy all sections, then relocate. > --- >> // Do relocation after all sections are copied. > > 2. Use SECT_FIRST as in the original loop to show that second loop > iterates over the same sections. > > > Thanks, > Vladimir > > On 11/22/12 13:53, Lindenmaier, Goetz wrote: >> Hi Chris, >> >> I fixed the other constants and renamed the webrev: >> http://cr.openjdk.java.net/~goetz/webrevs/8003850/ >> >> Cheers, >> Goetz. >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Wednesday, November 21, 2012 7:45 PM >> To: Lindenmaier, Goetz >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: RFR (S): 8003850: add support for constants in stub code [Was: Re: RFR (S): Issue constants to constant pool in stub code] >> >> >> On Nov 21, 2012, at 12:14 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi Christian, >>> >>> you're right, I should fix the other constants too. >>> I also can kick out the end_a_const() without argument, as it's no more needed, then. >> >> I filed: >> >> 8003850: add support for constants in stub code >> >> -- Chris >> >>> >>> Thanks, >>> Goetz. >>> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Dienstag, 20. November 2012 22:11 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-compiler-dev at openjdk.java.net >>> Subject: Re: RFR (S): Issue constants to constant pool in stub code >>> >>> >>> On Nov 20, 2012, at 2:05 AM, "Lindenmaier, Goetz" wrote: >>> >>>> Hi, >>>> >>>> When adding constants to the constant pool, the code_section is switched >>>> to the constant pool code_section, and then back again. It was hard coded >>>> to switch back to the code_section for code. >>>> If constants are issued in stubs, it is switched back to the wrong code section. >>>> I changed the code to remember the code section and switch back to the proper >>>> one. >>>> Further it's necessary to relocate only after copying code and stub section to >>>> a new location, as the relocation might affect an address in the stub section. >>>> >>>> You can find these changes here: >>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/ >>> >>> That's a nice fix. Recently I touched this code and I was worried about that also. I suppose on PPC you only use address_constant in stubs. What about the other constant emitting methods? >>> >>> -- Chris >>> >>>> >>>> or in our ppc port: >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062 >>>> >>>> Thank you and best regards, >>>> Goetz >>>> >>> >> From christian.thalinger at oracle.com Tue Nov 27 14:44:04 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Tue, 27 Nov 2012 22:44:04 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8003868: fix shark for latest HotSpot and LLVM Message-ID: <20121127224409.27C2A47B55@hg.openjdk.java.net> Changeset: 2cd5e15048e6 Author: twisti Date: 2012-11-27 12:48 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2cd5e15048e6 8003868: fix shark for latest HotSpot and LLVM Reviewed-by: twisti Contributed-by: Roman Kennke ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/shark/llvmHeaders.hpp ! src/share/vm/shark/llvmValue.hpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkBuilder.cpp ! src/share/vm/shark/sharkBuilder.hpp ! src/share/vm/shark/sharkCacheDecache.cpp ! src/share/vm/shark/sharkCacheDecache.hpp ! src/share/vm/shark/sharkCodeBuffer.hpp ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkContext.cpp ! src/share/vm/shark/sharkContext.hpp ! src/share/vm/shark/sharkFunction.hpp ! src/share/vm/shark/sharkIntrinsics.cpp ! src/share/vm/shark/sharkMemoryManager.cpp ! src/share/vm/shark/sharkMemoryManager.hpp ! src/share/vm/shark/sharkNativeWrapper.cpp ! src/share/vm/shark/sharkStack.cpp ! src/share/vm/shark/sharkStack.hpp ! src/share/vm/shark/sharkState.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp ! src/share/vm/shark/sharkTopLevelBlock.hpp ! src/share/vm/shark/sharkType.hpp ! src/share/vm/shark/sharkValue.cpp ! src/share/vm/shark/shark_globals.hpp From bharadwaj.yadavalli at oracle.com Tue Nov 27 16:04:58 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Tue, 27 Nov 2012 19:04:58 -0500 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50AF85F0.3020103@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> <509D3EE3.303@oracle.com> <50ABDC69.8050604@oracle.com> <50ACCE8F.1080701@oracle.com> <50AD6E25.3080100@oracle.com> <50AF85F0.3020103@oracle.com> Message-ID: <50B5552A.3050009@oracle.com> Updated the webrev http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ Added the ability in LogCompilation tool to print out live nodes info from log file. Please review. Thanks, Bharadwaj On 11/23/2012 9:19 AM, Vladimir Ivanov wrote: >>> if (_log != NULL) { >>> - _log->done("phase nodes='%d'", C->unique()); >>> + _log->done("phase name='%s'", _phase_name); >>> } >>> Phase name is redundant here - it duplicates info from the head. But I >> >> It is not redundant with nested phases and big methods you don't see the >> head so it is nice to see which phase ends. > Valid point. I'm not against this change, just looking at it from > automated parsing perspective. Current format isn't human-friendly > anyway :-) > > Best regards, > Vladimir Ivanov > >>> would leave nodes count as is and add live nodes count. >> >> Agree. It could be duplicated in the head of the following phase but >> more info is good. >> >> Vladimir K. >> >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 11/20/12 10:39 PM, Bharadwaj Yadavalli wrote: >>>> >>>> Please review the updated webrev at >>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ >>>> >>>> Hopefully I have addressed all the review comments/suggestions. >>>> >>>> Thanks, >>>> >>>> Bharadwaj >>>> >>>> On 11/9/2012 12:35 PM, Vladimir Kozlov wrote: >>>>> Bharadwaj, >>>>> >>>>> Nils just reminded me (for his changes) that you need to fix our >>>>> LogCompilation parsing tool to recognize new "unique='n' >>>>> live_tracked='n'" values (old was "nodes='n'"): >>>>> >>>>> src/share/tools/LogCompilation/ >>>>> >>>>> Also live_tracked could be simple "live". >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> Vladimir Kozlov wrote: >>>>>> VerifyIdealNodeCount flag should be also notproduct since it is used >>>>>> only in debug VM. >>>>>> >>>>>> The next assert is not needed because it duplicates assert in >>>>>> live_nodes(): >>>>>> >>>>>> bool check_node_count(uint margin, const char* reason) { >>>>>> if (unique() + margin > (uint)MaxNodeLimit) { >>>>>> + assert(dead_node_count() <= unique(), "number of dead nodes >>>>>> more than created"); >>>>>> >>>>>> Also don't split the assert in live_nodes() into 2 lines and maybe >>>>>> use err_msg_res() to print _unique and _dead_node_count values. Also >>>>>> I think it should return unsigned int type value as unique() method. >>>>>> >>>>>> Second Compile() constructor does not set _dead_node_count(0). >>>>>> >>>>>> count_live_nodes_by_graph_walk() and NotANode() methods are now used >>>>>> only in debug code so put them under #ifdef ASSERT. >>>>>> >>>>>> >>>>>> print_missing_nodes() should call count_live_nodes_by_graph_walk() >>>>>> instead of duplicating code. And it should print to _log itself. >>>>>> TracePhase() code will have only call to it: >>>>>> >>>>>> 3133 if (VerifyIdealNodeCount) { >>>>>> 3134 Compile::current()->print_missing_nodes(); >>>>>> 3135 } >>>>>> >>>>>> And do not check VerifyIdealNodeCount in print_missing_nodes() to >>>>>> allow call it in debugger without VerifyIdealNodeCount set. >>>>>> >>>>>> I think VerifyIdealNodeCount code should be in ~TracePhase() (end of >>>>>> phase). >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Bharadwaj Yadavalli wrote: >>>>>>> Addressed comments on my previous RFR. Changes at >>>>>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_02/ >>>>>>> >>>>>>> These changes are made to keep an (almost) accurate running >>>>>>> count of >>>>>>> the reachable (live) flow graph nodes. This will result in a more >>>>>>> realistic node count for various phases of C2 to decide on whether >>>>>>> to proceed with optimizations or not. Prior to these changes, C2 >>>>>>> bails out of compilation based on the number of nodes created which >>>>>>> typically larger than the number of reachable (live) nodes. >>>>>>> From Vladimir.Kozlov at oracle.com Tue Nov 27 16:43:09 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Nov 2012 16:43:09 -0800 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50B5552A.3050009@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> <509D3EE3.303@oracle.com> <50ABDC69.8050604@oracle.com> <50ACCE8F.1080701@oracle.com> <50AD6E25.3080100@oracle.com> <50AF85F0.3020103@oracle.com> <50B5552A.3050009@oracle.com> Message-ID: <50B55E1D.8040609@oracle.com> This is very nice. Thanks, Vladimir On 11/27/12 16:04, Bharadwaj Yadavalli wrote: > > Updated the webrev > > http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ > > Added the ability in LogCompilation tool to print out live nodes info > from log file. > > Please review. > > Thanks, > > Bharadwaj > > On 11/23/2012 9:19 AM, Vladimir Ivanov wrote: >>>> if (_log != NULL) { >>>> - _log->done("phase nodes='%d'", C->unique()); >>>> + _log->done("phase name='%s'", _phase_name); >>>> } >>>> Phase name is redundant here - it duplicates info from the head. But I >>> >>> It is not redundant with nested phases and big methods you don't see the >>> head so it is nice to see which phase ends. >> Valid point. I'm not against this change, just looking at it from >> automated parsing perspective. Current format isn't human-friendly >> anyway :-) >> >> Best regards, >> Vladimir Ivanov >> >>>> would leave nodes count as is and add live nodes count. >>> >>> Agree. It could be duplicated in the head of the following phase but >>> more info is good. >>> >>> Vladimir K. >>> >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 11/20/12 10:39 PM, Bharadwaj Yadavalli wrote: >>>>> >>>>> Please review the updated webrev at >>>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ >>>>> >>>>> Hopefully I have addressed all the review comments/suggestions. >>>>> >>>>> Thanks, >>>>> >>>>> Bharadwaj >>>>> >>>>> On 11/9/2012 12:35 PM, Vladimir Kozlov wrote: >>>>>> Bharadwaj, >>>>>> >>>>>> Nils just reminded me (for his changes) that you need to fix our >>>>>> LogCompilation parsing tool to recognize new "unique='n' >>>>>> live_tracked='n'" values (old was "nodes='n'"): >>>>>> >>>>>> src/share/tools/LogCompilation/ >>>>>> >>>>>> Also live_tracked could be simple "live". >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Vladimir Kozlov wrote: >>>>>>> VerifyIdealNodeCount flag should be also notproduct since it is used >>>>>>> only in debug VM. >>>>>>> >>>>>>> The next assert is not needed because it duplicates assert in >>>>>>> live_nodes(): >>>>>>> >>>>>>> bool check_node_count(uint margin, const char* reason) { >>>>>>> if (unique() + margin > (uint)MaxNodeLimit) { >>>>>>> + assert(dead_node_count() <= unique(), "number of dead nodes >>>>>>> more than created"); >>>>>>> >>>>>>> Also don't split the assert in live_nodes() into 2 lines and maybe >>>>>>> use err_msg_res() to print _unique and _dead_node_count values. Also >>>>>>> I think it should return unsigned int type value as unique() method. >>>>>>> >>>>>>> Second Compile() constructor does not set _dead_node_count(0). >>>>>>> >>>>>>> count_live_nodes_by_graph_walk() and NotANode() methods are now used >>>>>>> only in debug code so put them under #ifdef ASSERT. >>>>>>> >>>>>>> >>>>>>> print_missing_nodes() should call count_live_nodes_by_graph_walk() >>>>>>> instead of duplicating code. And it should print to _log itself. >>>>>>> TracePhase() code will have only call to it: >>>>>>> >>>>>>> 3133 if (VerifyIdealNodeCount) { >>>>>>> 3134 Compile::current()->print_missing_nodes(); >>>>>>> 3135 } >>>>>>> >>>>>>> And do not check VerifyIdealNodeCount in print_missing_nodes() to >>>>>>> allow call it in debugger without VerifyIdealNodeCount set. >>>>>>> >>>>>>> I think VerifyIdealNodeCount code should be in ~TracePhase() (end of >>>>>>> phase). >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> Bharadwaj Yadavalli wrote: >>>>>>>> Addressed comments on my previous RFR. Changes at >>>>>>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_02/ >>>>>>>> >>>>>>>> These changes are made to keep an (almost) accurate running >>>>>>>> count of >>>>>>>> the reachable (live) flow graph nodes. This will result in a more >>>>>>>> realistic node count for various phases of C2 to decide on whether >>>>>>>> to proceed with optimizations or not. Prior to these changes, C2 >>>>>>>> bails out of compilation based on the number of nodes created which >>>>>>>> typically larger than the number of reachable (live) nodes. >>>>>>>> From christian.thalinger at oracle.com Tue Nov 27 16:50:41 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 27 Nov 2012 16:50:41 -0800 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50B5552A.3050009@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> <509D3EE3.303@oracle.com> <50ABDC69.8050604@oracle.com> <50ACCE8F.1080701@oracle.com> <50AD6E25.3080100@oracle.com> <50AF85F0.3020103@oracle.com> <50B5552A.3050009@oracle.com> Message-ID: On Nov 27, 2012, at 4:04 PM, Bharadwaj Yadavalli wrote: > > Updated the webrev > > http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ > > Added the ability in LogCompilation tool to print out live nodes info from log file. src/share/vm/opto/parse1.cpp: + if (log) log->done("parse nodes='%d' live='%d' memory='%d'", There are two spaces before live (I know it doesn't matter but it's a waste of disk space ;-). Otherwise this looks good. -- Chris > > Please review. > > Thanks, > > Bharadwaj > > On 11/23/2012 9:19 AM, Vladimir Ivanov wrote: >>>> if (_log != NULL) { >>>> - _log->done("phase nodes='%d'", C->unique()); >>>> + _log->done("phase name='%s'", _phase_name); >>>> } >>>> Phase name is redundant here - it duplicates info from the head. But I >>> >>> It is not redundant with nested phases and big methods you don't see the >>> head so it is nice to see which phase ends. >> Valid point. I'm not against this change, just looking at it from automated parsing perspective. Current format isn't human-friendly anyway :-) >> >> Best regards, >> Vladimir Ivanov >> >>>> would leave nodes count as is and add live nodes count. >>> >>> Agree. It could be duplicated in the head of the following phase but >>> more info is good. >>> >>> Vladimir K. >>> >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 11/20/12 10:39 PM, Bharadwaj Yadavalli wrote: >>>>> >>>>> Please review the updated webrev at >>>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ >>>>> >>>>> Hopefully I have addressed all the review comments/suggestions. >>>>> >>>>> Thanks, >>>>> >>>>> Bharadwaj >>>>> >>>>> On 11/9/2012 12:35 PM, Vladimir Kozlov wrote: >>>>>> Bharadwaj, >>>>>> >>>>>> Nils just reminded me (for his changes) that you need to fix our >>>>>> LogCompilation parsing tool to recognize new "unique='n' >>>>>> live_tracked='n'" values (old was "nodes='n'"): >>>>>> >>>>>> src/share/tools/LogCompilation/ >>>>>> >>>>>> Also live_tracked could be simple "live". >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> Vladimir Kozlov wrote: >>>>>>> VerifyIdealNodeCount flag should be also notproduct since it is used >>>>>>> only in debug VM. >>>>>>> >>>>>>> The next assert is not needed because it duplicates assert in >>>>>>> live_nodes(): >>>>>>> >>>>>>> bool check_node_count(uint margin, const char* reason) { >>>>>>> if (unique() + margin > (uint)MaxNodeLimit) { >>>>>>> + assert(dead_node_count() <= unique(), "number of dead nodes >>>>>>> more than created"); >>>>>>> >>>>>>> Also don't split the assert in live_nodes() into 2 lines and maybe >>>>>>> use err_msg_res() to print _unique and _dead_node_count values. Also >>>>>>> I think it should return unsigned int type value as unique() method. >>>>>>> >>>>>>> Second Compile() constructor does not set _dead_node_count(0). >>>>>>> >>>>>>> count_live_nodes_by_graph_walk() and NotANode() methods are now used >>>>>>> only in debug code so put them under #ifdef ASSERT. >>>>>>> >>>>>>> >>>>>>> print_missing_nodes() should call count_live_nodes_by_graph_walk() >>>>>>> instead of duplicating code. And it should print to _log itself. >>>>>>> TracePhase() code will have only call to it: >>>>>>> >>>>>>> 3133 if (VerifyIdealNodeCount) { >>>>>>> 3134 Compile::current()->print_missing_nodes(); >>>>>>> 3135 } >>>>>>> >>>>>>> And do not check VerifyIdealNodeCount in print_missing_nodes() to >>>>>>> allow call it in debugger without VerifyIdealNodeCount set. >>>>>>> >>>>>>> I think VerifyIdealNodeCount code should be in ~TracePhase() (end of >>>>>>> phase). >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> Bharadwaj Yadavalli wrote: >>>>>>>> Addressed comments on my previous RFR. Changes at >>>>>>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_02/ >>>>>>>> >>>>>>>> These changes are made to keep an (almost) accurate running count of >>>>>>>> the reachable (live) flow graph nodes. This will result in a more >>>>>>>> realistic node count for various phases of C2 to decide on whether >>>>>>>> to proceed with optimizations or not. Prior to these changes, C2 >>>>>>>> bails out of compilation based on the number of nodes created which >>>>>>>> typically larger than the number of reachable (live) nodes. >>>>>>>> From Vladimir.Kozlov at oracle.com Tue Nov 27 17:13:59 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Nov 2012 17:13:59 -0800 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> <509D3EE3.303@oracle.com> <50ABDC69.8050604@oracle.com> <50ACCE8F.1080701@oracle.com> <50AD6E25.3080100@oracle.com> <50AF85F0.3020103@oracle.com> <50B5552A.3050009@oracle.com> Message-ID: <50B56557.4010506@oracle.com> I will push this changes. Thanks, Vladimir On 11/27/12 16:50, Christian Thalinger wrote: > > On Nov 27, 2012, at 4:04 PM, Bharadwaj Yadavalli wrote: > >> >> Updated the webrev >> >> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ >> >> Added the ability in LogCompilation tool to print out live nodes info from log file. > > src/share/vm/opto/parse1.cpp: > > + if (log) log->done("parse nodes='%d' live='%d' memory='%d'", > > There are two spaces before live (I know it doesn't matter but it's a waste of disk space ;-). > > Otherwise this looks good. > > -- Chris > >> >> Please review. >> >> Thanks, >> >> Bharadwaj >> >> On 11/23/2012 9:19 AM, Vladimir Ivanov wrote: >>>>> if (_log != NULL) { >>>>> - _log->done("phase nodes='%d'", C->unique()); >>>>> + _log->done("phase name='%s'", _phase_name); >>>>> } >>>>> Phase name is redundant here - it duplicates info from the head. But I >>>> >>>> It is not redundant with nested phases and big methods you don't see the >>>> head so it is nice to see which phase ends. >>> Valid point. I'm not against this change, just looking at it from automated parsing perspective. Current format isn't human-friendly anyway :-) >>> >>> Best regards, >>> Vladimir Ivanov >>> >>>>> would leave nodes count as is and add live nodes count. >>>> >>>> Agree. It could be duplicated in the head of the following phase but >>>> more info is good. >>>> >>>> Vladimir K. >>>> >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 11/20/12 10:39 PM, Bharadwaj Yadavalli wrote: >>>>>> >>>>>> Please review the updated webrev at >>>>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ >>>>>> >>>>>> Hopefully I have addressed all the review comments/suggestions. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Bharadwaj >>>>>> >>>>>> On 11/9/2012 12:35 PM, Vladimir Kozlov wrote: >>>>>>> Bharadwaj, >>>>>>> >>>>>>> Nils just reminded me (for his changes) that you need to fix our >>>>>>> LogCompilation parsing tool to recognize new "unique='n' >>>>>>> live_tracked='n'" values (old was "nodes='n'"): >>>>>>> >>>>>>> src/share/tools/LogCompilation/ >>>>>>> >>>>>>> Also live_tracked could be simple "live". >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> Vladimir Kozlov wrote: >>>>>>>> VerifyIdealNodeCount flag should be also notproduct since it is used >>>>>>>> only in debug VM. >>>>>>>> >>>>>>>> The next assert is not needed because it duplicates assert in >>>>>>>> live_nodes(): >>>>>>>> >>>>>>>> bool check_node_count(uint margin, const char* reason) { >>>>>>>> if (unique() + margin> (uint)MaxNodeLimit) { >>>>>>>> + assert(dead_node_count()<= unique(), "number of dead nodes >>>>>>>> more than created"); >>>>>>>> >>>>>>>> Also don't split the assert in live_nodes() into 2 lines and maybe >>>>>>>> use err_msg_res() to print _unique and _dead_node_count values. Also >>>>>>>> I think it should return unsigned int type value as unique() method. >>>>>>>> >>>>>>>> Second Compile() constructor does not set _dead_node_count(0). >>>>>>>> >>>>>>>> count_live_nodes_by_graph_walk() and NotANode() methods are now used >>>>>>>> only in debug code so put them under #ifdef ASSERT. >>>>>>>> >>>>>>>> >>>>>>>> print_missing_nodes() should call count_live_nodes_by_graph_walk() >>>>>>>> instead of duplicating code. And it should print to _log itself. >>>>>>>> TracePhase() code will have only call to it: >>>>>>>> >>>>>>>> 3133 if (VerifyIdealNodeCount) { >>>>>>>> 3134 Compile::current()->print_missing_nodes(); >>>>>>>> 3135 } >>>>>>>> >>>>>>>> And do not check VerifyIdealNodeCount in print_missing_nodes() to >>>>>>>> allow call it in debugger without VerifyIdealNodeCount set. >>>>>>>> >>>>>>>> I think VerifyIdealNodeCount code should be in ~TracePhase() (end of >>>>>>>> phase). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> Bharadwaj Yadavalli wrote: >>>>>>>>> Addressed comments on my previous RFR. Changes at >>>>>>>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_02/ >>>>>>>>> >>>>>>>>> These changes are made to keep an (almost) accurate running count of >>>>>>>>> the reachable (live) flow graph nodes. This will result in a more >>>>>>>>> realistic node count for various phases of C2 to decide on whether >>>>>>>>> to proceed with optimizations or not. Prior to these changes, C2 >>>>>>>>> bails out of compilation based on the number of nodes created which >>>>>>>>> typically larger than the number of reachable (live) nodes. >>>>>>>>> > From xerox.time.tech at gmail.com Tue Nov 27 18:36:39 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Tue, 27 Nov 2012 21:36:39 -0500 Subject: Insert Special Code Sequence After Object allocation Message-ID: I would like to insert a special binary code sequence after the allocation of a java object in the opto JIT code. can anyone tell me how to do that ? Xin From bharadwaj.yadavalli at oracle.com Tue Nov 27 18:50:12 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Tue, 27 Nov 2012 21:50:12 -0500 Subject: Request for Reviews(M): 7092905: C2: Keep track of the number of dead nodes In-Reply-To: <50B56557.4010506@oracle.com> References: <508DF417.7090906@oracle.com> <04038883-A951-4916-BA99-F52D71B4B928@oracle.com> <425293F5-F884-4827-8BE5-2AD2B471277E@oracle.com> <508ED445.3090401@oracle.com> <508FE8D2.3080803@oracle.com> <50914104.5020401@oracle.com> <50916B78.7090207@oracle.com> <509818D8.8090007@oracle.com> <50982213.3090602@oracle.com> <854CB956-5AD4-4716-BCB0-54A6E18C0EE0@oracle.com> <509C2215.4010302@oracle.com> <509C5460.4050608@oracle.com> <509D3EE3.303@oracle.com> <50ABDC69.8050604@oracle.com> <50ACCE8F.1080701@oracle.com> <50AD6E25.3080100@oracle.com> <50AF85F0.3020103@oracle.com> <50B5552A.3050009@oracle.com> <50B56557.4010506@oracle.com> Message-ID: <50B57BE4.9070709@oracle.com> Thanks for your reviews Vladimir and Christian. I deleted the extra white space and updated the webrev (and saved the disk space :-)) Bharadwaj On 11/27/2012 8:13 PM, Vladimir Kozlov wrote: > I will push this changes. > > Thanks, > Vladimir > > On 11/27/12 16:50, Christian Thalinger wrote: >> >> On Nov 27, 2012, at 4:04 PM, Bharadwaj >> Yadavalli wrote: >> >>> >>> Updated the webrev >>> >>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ >>> >>> Added the ability in LogCompilation tool to print out live nodes >>> info from log file. >> >> src/share/vm/opto/parse1.cpp: >> >> + if (log) log->done("parse nodes='%d' live='%d' memory='%d'", >> >> There are two spaces before live (I know it doesn't matter but it's a >> waste of disk space ;-). >> >> Otherwise this looks good. >> >> -- Chris >> >>> >>> Please review. >>> >>> Thanks, >>> >>> Bharadwaj >>> >>> On 11/23/2012 9:19 AM, Vladimir Ivanov wrote: >>>>>> if (_log != NULL) { >>>>>> - _log->done("phase nodes='%d'", C->unique()); >>>>>> + _log->done("phase name='%s'", _phase_name); >>>>>> } >>>>>> Phase name is redundant here - it duplicates info from the head. >>>>>> But I >>>>> >>>>> It is not redundant with nested phases and big methods you don't >>>>> see the >>>>> head so it is nice to see which phase ends. >>>> Valid point. I'm not against this change, just looking at it from >>>> automated parsing perspective. Current format isn't human-friendly >>>> anyway :-) >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>>>> would leave nodes count as is and add live nodes count. >>>>> >>>>> Agree. It could be duplicated in the head of the following phase but >>>>> more info is good. >>>>> >>>>> Vladimir K. >>>>> >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 11/20/12 10:39 PM, Bharadwaj Yadavalli wrote: >>>>>>> >>>>>>> Please review the updated webrev at >>>>>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_03/ >>>>>>> >>>>>>> Hopefully I have addressed all the review comments/suggestions. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Bharadwaj >>>>>>> >>>>>>> On 11/9/2012 12:35 PM, Vladimir Kozlov wrote: >>>>>>>> Bharadwaj, >>>>>>>> >>>>>>>> Nils just reminded me (for his changes) that you need to fix our >>>>>>>> LogCompilation parsing tool to recognize new "unique='n' >>>>>>>> live_tracked='n'" values (old was "nodes='n'"): >>>>>>>> >>>>>>>> src/share/tools/LogCompilation/ >>>>>>>> >>>>>>>> Also live_tracked could be simple "live". >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> Vladimir Kozlov wrote: >>>>>>>>> VerifyIdealNodeCount flag should be also notproduct since it >>>>>>>>> is used >>>>>>>>> only in debug VM. >>>>>>>>> >>>>>>>>> The next assert is not needed because it duplicates assert in >>>>>>>>> live_nodes(): >>>>>>>>> >>>>>>>>> bool check_node_count(uint margin, const char* reason) { >>>>>>>>> if (unique() + margin> (uint)MaxNodeLimit) { >>>>>>>>> + assert(dead_node_count()<= unique(), "number of dead nodes >>>>>>>>> more than created"); >>>>>>>>> >>>>>>>>> Also don't split the assert in live_nodes() into 2 lines and >>>>>>>>> maybe >>>>>>>>> use err_msg_res() to print _unique and _dead_node_count >>>>>>>>> values. Also >>>>>>>>> I think it should return unsigned int type value as unique() >>>>>>>>> method. >>>>>>>>> >>>>>>>>> Second Compile() constructor does not set _dead_node_count(0). >>>>>>>>> >>>>>>>>> count_live_nodes_by_graph_walk() and NotANode() methods are >>>>>>>>> now used >>>>>>>>> only in debug code so put them under #ifdef ASSERT. >>>>>>>>> >>>>>>>>> >>>>>>>>> print_missing_nodes() should call >>>>>>>>> count_live_nodes_by_graph_walk() >>>>>>>>> instead of duplicating code. And it should print to _log itself. >>>>>>>>> TracePhase() code will have only call to it: >>>>>>>>> >>>>>>>>> 3133 if (VerifyIdealNodeCount) { >>>>>>>>> 3134 Compile::current()->print_missing_nodes(); >>>>>>>>> 3135 } >>>>>>>>> >>>>>>>>> And do not check VerifyIdealNodeCount in print_missing_nodes() to >>>>>>>>> allow call it in debugger without VerifyIdealNodeCount set. >>>>>>>>> >>>>>>>>> I think VerifyIdealNodeCount code should be in ~TracePhase() >>>>>>>>> (end of >>>>>>>>> phase). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> Bharadwaj Yadavalli wrote: >>>>>>>>>> Addressed comments on my previous RFR. Changes at >>>>>>>>>> http://cr.openjdk.java.net/~bharadwaj/7092905/webrev_02/ >>>>>>>>>> >>>>>>>>>> These changes are made to keep an (almost) accurate running >>>>>>>>>> count of >>>>>>>>>> the reachable (live) flow graph nodes. This will result in a >>>>>>>>>> more >>>>>>>>>> realistic node count for various phases of C2 to decide on >>>>>>>>>> whether >>>>>>>>>> to proceed with optimizations or not. Prior to these changes, C2 >>>>>>>>>> bails out of compilation based on the number of nodes created >>>>>>>>>> which >>>>>>>>>> typically larger than the number of reachable (live) nodes. >>>>>>>>>> >> From vladimir.kozlov at oracle.com Tue Nov 27 19:36:36 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 28 Nov 2012 03:36:36 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 7092905: C2: Keep track of the number of dead nodes Message-ID: <20121128033640.84D6447B5D@hg.openjdk.java.net> Changeset: 2aff40cb4703 Author: bharadwaj Date: 2012-11-27 17:24 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2aff40cb4703 7092905: C2: Keep track of the number of dead nodes Summary: keep an (almost) accurate running count of the reachable (live) flow graph nodes. Reviewed-by: kvn, twisti, jrose, vlivanov ! src/share/tools/LogCompilation/README ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java ! src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java ! src/share/vm/opto/block.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/stringopts.cpp From krystal.mo at oracle.com Tue Nov 27 20:23:49 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Wed, 28 Nov 2012 12:23:49 +0800 Subject: Insert Special Code Sequence After Object allocation In-Reply-To: References: Message-ID: <50B591D5.7010909@oracle.com> Hi Xin, Depends on what the code sequence is and what it does. If the code sequence you're inserting can be represented in C2's IR nodes, then you can try to add those nodes in either PhaseMacroExpand::expand_allocate_common() or PhaseMacroExpand::initialize_object(), or somewhere else around. If your code sequence cannot be represented in C2's IR, well, that will take some effort. The AllocateNode is lost after PhaseMacroExpand, so you can't use it as a mark to insert your code. You might want to use prefetchAlloc in the AD files as a place to insert code, if that works for your purpose. That said, though, if the code sequence could be written in Java bytecode, that'll be the easiest solution: don't have to touch the VM, just do bytecode instrumentation. - Kris On 2012/11/28 10:36, Xin Tong wrote: > I would like to insert a special binary code sequence after the > allocation of a java object in the opto JIT code. can anyone tell me > how to do that ? > > Xin From xerox.time.tech at gmail.com Tue Nov 27 21:58:12 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Wed, 28 Nov 2012 00:58:12 -0500 Subject: Insert Special Code Sequence After Object allocation In-Reply-To: <50B591D5.7010909@oracle.com> References: <50B591D5.7010909@oracle.com> Message-ID: On Tue, Nov 27, 2012 at 11:23 PM, Krystal Mo wrote: > Hi Xin, > > Depends on what the code sequence is and what it does. > > If the code sequence you're inserting can be represented in C2's IR nodes, > then you can try to add those nodes in either > PhaseMacroExpand::expand_allocate_common() or > PhaseMacroExpand::initialize_object(), or somewhere else around. > It is a few assembly instructions. can i wrap the assemblies in a function that hasa prologue and epilogue to save everything. and does the IR has any way of calling a function ? Xin > If your code sequence cannot be represented in C2's IR, well, that will take > some effort. The AllocateNode is lost after PhaseMacroExpand, so you can't > use it as a mark to insert your code. You might want to use prefetchAlloc in > the AD files as a place to insert code, if that works for your purpose. > > That said, though, if the code sequence could be written in Java bytecode, > that'll be the easiest solution: don't have to touch the VM, just do > bytecode instrumentation. > > - Kris > > > On 2012/11/28 10:36, Xin Tong wrote: >> >> I would like to insert a special binary code sequence after the >> allocation of a java object in the opto JIT code. can anyone tell me >> how to do that ? >> >> Xin From vladimir.kozlov at oracle.com Tue Nov 27 21:58:20 2012 From: vladimir.kozlov at oracle.com (vladimir.kozlov at oracle.com) Date: Wed, 28 Nov 2012 05:58:20 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8003850: add support for constants in stub code Message-ID: <20121128055825.2926247B63@hg.openjdk.java.net> Changeset: 1acccb7c0b01 Author: kvn Date: 2012-11-27 17:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/1acccb7c0b01 8003850: add support for constants in stub code Summary: remember the code section and switch back to the proper one when adding constants. Reviewed-by: twisti, kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.cpp From xerox.time.tech at gmail.com Tue Nov 27 22:02:06 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Wed, 28 Nov 2012 01:02:06 -0500 Subject: Insert Special Code Sequence After Object allocation In-Reply-To: References: <50B591D5.7010909@oracle.com> Message-ID: On Wed, Nov 28, 2012 at 12:58 AM, Xin Tong wrote: > On Tue, Nov 27, 2012 at 11:23 PM, Krystal Mo wrote: >> Hi Xin, >> >> Depends on what the code sequence is and what it does. >> >> If the code sequence you're inserting can be represented in C2's IR nodes, >> then you can try to add those nodes in either >> PhaseMacroExpand::expand_allocate_common() or >> PhaseMacroExpand::initialize_object(), or somewhere else around. >> > > It is a few assembly instructions. can i wrap the assemblies in a > function that hasa prologue and epilogue to save everything. and does > the IR has any way of calling a function ? > > Xin Or another thing i am willing to do is to force the JIT to always fail on the inlined allocation and force it to the out-of-line ( VM managed) allocation. I just do not want to turn the JIT completely off as that have an big impact on the behaviours of the program. Is this doable ? Xin > >> If your code sequence cannot be represented in C2's IR, well, that will take >> some effort. The AllocateNode is lost after PhaseMacroExpand, so you can't >> use it as a mark to insert your code. You might want to use prefetchAlloc in >> the AD files as a place to insert code, if that works for your purpose. >> >> That said, though, if the code sequence could be written in Java bytecode, >> that'll be the easiest solution: don't have to touch the VM, just do >> bytecode instrumentation. >> >> - Kris >> >> >> On 2012/11/28 10:36, Xin Tong wrote: >>> >>> I would like to insert a special binary code sequence after the >>> allocation of a java object in the opto JIT code. can anyone tell me >>> how to do that ? >>> >>> Xin From xerox.time.tech at gmail.com Tue Nov 27 22:14:30 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Wed, 28 Nov 2012 01:14:30 -0500 Subject: TLB impact on VM performance Message-ID: I recently took some data on the performance of hotspot when hugepage is enabled/disabled. i found a performance difference of ~20% on specjbb with -Xms1024m -Xmx2048m running 4 whs. the nursery heap size is ~600M and tenure is ~500M. OS: Linux socrates 3.2.0-33-generic #52-Ubuntu SMP Thu Oct 18 16:29:15 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux CPU: model name : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz I am wondering does hugepage demostrate performance improvements on other benchmarks as well ? i see a much smaller difference for dacapo benchmarks. Thanks Xin From krystal.mo at oracle.com Tue Nov 27 22:35:12 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Wed, 28 Nov 2012 14:35:12 +0800 Subject: Insert Special Code Sequence After Object allocation In-Reply-To: References: <50B591D5.7010909@oracle.com> Message-ID: <50B5B0A0.1010504@oracle.com> On 11/28/2012 02:02 PM, Xin Tong wrote: > On Wed, Nov 28, 2012 at 12:58 AM, Xin Tong wrote: >> On Tue, Nov 27, 2012 at 11:23 PM, Krystal Mo wrote: >>> Hi Xin, >>> >>> Depends on what the code sequence is and what it does. >>> >>> If the code sequence you're inserting can be represented in C2's IR nodes, >>> then you can try to add those nodes in either >>> PhaseMacroExpand::expand_allocate_common() or >>> PhaseMacroExpand::initialize_object(), or somewhere else around. >>> >> It is a few assembly instructions. can i wrap the assemblies in a >> function that hasa prologue and epilogue to save everything. and does >> the IR has any way of calling a function ? >> >> Xin > Or another thing i am willing to do is to force the JIT to always fail > on the inlined allocation and force it to the out-of-line ( VM > managed) allocation. I just do not want to turn the JIT completely off > as that have an big impact on the behaviours of the program. Is this > doable ? Sure, if you're willing take the performance hit. It's easy: in PhaseMacroExpand::expand_allocate_common(), just make sure the local variables initial_slow_test and always_slow are assigned NULL and true respectively, and there you go. It'll call into OptoRuntime::new_instance_C(). - Kris > Xin > >>> If your code sequence cannot be represented in C2's IR, well, that will take >>> some effort. The AllocateNode is lost after PhaseMacroExpand, so you can't >>> use it as a mark to insert your code. You might want to use prefetchAlloc in >>> the AD files as a place to insert code, if that works for your purpose. >>> >>> That said, though, if the code sequence could be written in Java bytecode, >>> that'll be the easiest solution: don't have to touch the VM, just do >>> bytecode instrumentation. >>> >>> - Kris >>> >>> >>> On 2012/11/28 10:36, Xin Tong wrote: >>>> I would like to insert a special binary code sequence after the >>>> allocation of a java object in the opto JIT code. can anyone tell me >>>> how to do that ? >>>> >>>> Xin From xerox.time.tech at gmail.com Tue Nov 27 22:51:16 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Wed, 28 Nov 2012 01:51:16 -0500 Subject: Insert Special Code Sequence After Object allocation In-Reply-To: <50B5B0A0.1010504@oracle.com> References: <50B591D5.7010909@oracle.com> <50B5B0A0.1010504@oracle.com> Message-ID: On Wed, Nov 28, 2012 at 1:35 AM, Krystal Mo wrote: > On 11/28/2012 02:02 PM, Xin Tong wrote: >> >> On Wed, Nov 28, 2012 at 12:58 AM, Xin Tong >> wrote: >>> >>> On Tue, Nov 27, 2012 at 11:23 PM, Krystal Mo >>> wrote: >>>> >>>> Hi Xin, >>>> >>>> Depends on what the code sequence is and what it does. >>>> >>>> If the code sequence you're inserting can be represented in C2's IR >>>> nodes, >>>> then you can try to add those nodes in either >>>> PhaseMacroExpand::expand_allocate_common() or >>>> PhaseMacroExpand::initialize_object(), or somewhere else around. >>>> >>> It is a few assembly instructions. can i wrap the assemblies in a >>> function that hasa prologue and epilogue to save everything. and does >>> the IR has any way of calling a function ? >>> >>> Xin >> >> Or another thing i am willing to do is to force the JIT to always fail >> on the inlined allocation and force it to the out-of-line ( VM >> managed) allocation. I just do not want to turn the JIT completely off >> as that have an big impact on the behaviours of the program. Is this >> doable ? > > Sure, if you're willing take the performance hit. > > It's easy: in PhaseMacroExpand::expand_allocate_common(), just make sure the > local variables initial_slow_test and always_slow are assigned NULL and true > respectively, and there you go. It'll call into > OptoRuntime::new_instance_C(). > I change the bool always_slow = true; it runs ok. but when i change Node* initial_slow_test = NULL ; //alloc->in(AllocateNode::InitialTest); the VM crashes. Is it necessary to make initial_slow_test to NULL ? is not initial_slow_test used to initialize allocattion from slow path ? # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fd6d0e58572, pid=18333, tid=140560399947520 # # JRE version: 7.0 # Java VM: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode linux-amd64 compressed oops) # Problematic frame: # V [libjvm.so+0x7b6572] BoolNode::make_predicate(Node*, PhaseGVN*)+0x22 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /home/xtong/fastcache/benchmarks/SPECJBB2005/hs_err_pid18333.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # ./run.sh: line 13: 18333 Aborted (core dumped) java -Xms1024m -Xmx2048m spec.jbb.JBBmain -propfile SPECjbb.props Xin > - Kris > > >> Xin >> >>>> If your code sequence cannot be represented in C2's IR, well, that will >>>> take >>>> some effort. The AllocateNode is lost after PhaseMacroExpand, so you >>>> can't >>>> use it as a mark to insert your code. You might want to use >>>> prefetchAlloc in >>>> the AD files as a place to insert code, if that works for your purpose. >>>> >>>> That said, though, if the code sequence could be written in Java >>>> bytecode, >>>> that'll be the easiest solution: don't have to touch the VM, just do >>>> bytecode instrumentation. >>>> >>>> - Kris >>>> >>>> >>>> On 2012/11/28 10:36, Xin Tong wrote: >>>>> >>>>> I would like to insert a special binary code sequence after the >>>>> allocation of a java object in the opto JIT code. can anyone tell me >>>>> how to do that ? >>>>> >>>>> Xin > > From xerox.time.tech at gmail.com Tue Nov 27 23:20:54 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Wed, 28 Nov 2012 02:20:54 -0500 Subject: Insert Special Code Sequence After Object allocation In-Reply-To: References: <50B591D5.7010909@oracle.com> <50B5B0A0.1010504@oracle.com> Message-ID: Is there a way to turn off UseTLAB BTW ? it is turned on by default here. void PhaseMacroExpand::expand_allocate_common( AllocateNode* alloc, // allocation node to be expanded Node* length, // array length for an array allocation const TypeFunc* slow_call_type, // Type of slow call address slow_call_address // Address of slow call ) { ... printf("UseTLAB is %d\n", UseTLAB); if (C->env()->dtrace_alloc_probes() || !UseTLAB && (!Universe::heap()->supports_inline_contig_alloc() || (UseConcMarkSweepGC && CMSIncrementalMode))) { // Force slow-path allocation printf("Force slow-path allocation\n"); always_slow = true; initial_slow_test = NULL; } ... } Xin On Wed, Nov 28, 2012 at 1:51 AM, Xin Tong wrote: > On Wed, Nov 28, 2012 at 1:35 AM, Krystal Mo wrote: >> On 11/28/2012 02:02 PM, Xin Tong wrote: >>> >>> On Wed, Nov 28, 2012 at 12:58 AM, Xin Tong >>> wrote: >>>> >>>> On Tue, Nov 27, 2012 at 11:23 PM, Krystal Mo >>>> wrote: >>>>> >>>>> Hi Xin, >>>>> >>>>> Depends on what the code sequence is and what it does. >>>>> >>>>> If the code sequence you're inserting can be represented in C2's IR >>>>> nodes, >>>>> then you can try to add those nodes in either >>>>> PhaseMacroExpand::expand_allocate_common() or >>>>> PhaseMacroExpand::initialize_object(), or somewhere else around. >>>>> >>>> It is a few assembly instructions. can i wrap the assemblies in a >>>> function that hasa prologue and epilogue to save everything. and does >>>> the IR has any way of calling a function ? >>>> >>>> Xin >>> >>> Or another thing i am willing to do is to force the JIT to always fail >>> on the inlined allocation and force it to the out-of-line ( VM >>> managed) allocation. I just do not want to turn the JIT completely off >>> as that have an big impact on the behaviours of the program. Is this >>> doable ? >> >> Sure, if you're willing take the performance hit. >> >> It's easy: in PhaseMacroExpand::expand_allocate_common(), just make sure the >> local variables initial_slow_test and always_slow are assigned NULL and true >> respectively, and there you go. It'll call into >> OptoRuntime::new_instance_C(). >> > > I change the bool always_slow = true; it runs ok. but when i change > Node* initial_slow_test = NULL ; > //alloc->in(AllocateNode::InitialTest); > the VM crashes. Is it necessary to make initial_slow_test to NULL ? is > not initial_slow_test used to initialize allocattion from slow path ? > > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007fd6d0e58572, pid=18333, tid=140560399947520 > # > # JRE version: 7.0 > # Java VM: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode linux-amd64 > compressed oops) > # Problematic frame: > # V [libjvm.so+0x7b6572] BoolNode::make_predicate(Node*, PhaseGVN*)+0x22 > # > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /home/xtong/fastcache/benchmarks/SPECJBB2005/hs_err_pid18333.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > ./run.sh: line 13: 18333 Aborted (core dumped) java > -Xms1024m -Xmx2048m spec.jbb.JBBmain -propfile SPECjbb.props > > > Xin > > > >> - Kris >> >> >>> Xin >>> >>>>> If your code sequence cannot be represented in C2's IR, well, that will >>>>> take >>>>> some effort. The AllocateNode is lost after PhaseMacroExpand, so you >>>>> can't >>>>> use it as a mark to insert your code. You might want to use >>>>> prefetchAlloc in >>>>> the AD files as a place to insert code, if that works for your purpose. >>>>> >>>>> That said, though, if the code sequence could be written in Java >>>>> bytecode, >>>>> that'll be the easiest solution: don't have to touch the VM, just do >>>>> bytecode instrumentation. >>>>> >>>>> - Kris >>>>> >>>>> >>>>> On 2012/11/28 10:36, Xin Tong wrote: >>>>>> >>>>>> I would like to insert a special binary code sequence after the >>>>>> allocation of a java object in the opto JIT code. can anyone tell me >>>>>> how to do that ? >>>>>> >>>>>> Xin >> >> From aleksey.shipilev at oracle.com Wed Nov 28 02:13:08 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 28 Nov 2012 14:13:08 +0400 Subject: TLB impact on VM performance In-Reply-To: References: Message-ID: <50B5E3B4.2080408@oracle.com> On 11/28/2012 10:14 AM, Xin Tong wrote: > I recently took some data on the performance of hotspot when hugepage > is enabled/disabled. i found a performance difference of ~20% on > specjbb with -Xms1024m -Xmx2048m running 4 whs. the nursery heap size > is ~600M and tenure is ~500M. > > OS: Linux socrates 3.2.0-33-generic #52-Ubuntu SMP Thu Oct 18 16:29:15 > UTC 2012 x86_64 x86_64 x86_64 GNU/Linux > CPU: model name : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz > > I am wondering does hugepage demostrate performance improvements on > other benchmarks as well ? i see a much smaller difference for dacapo > benchmarks. My interpretation: SPECjbb is known to be very memory-access intensive, that is why improving TLB accesses gives you huge payoffs. Many Dacapo benchmarks are compute-bound, and the TLB performance while important is not having the same impacts. Many characteristic Java applications are as promiscuous with memory as SPECjbb, and so large pages demonstrate significant improvements on business workloads we have internally. -Aleksey. From xerox.time.tech at gmail.com Wed Nov 28 09:48:22 2012 From: xerox.time.tech at gmail.com (Xin Tong) Date: Wed, 28 Nov 2012 12:48:22 -0500 Subject: TLB impact on VM performance In-Reply-To: <50B5E3B4.2080408@oracle.com> References: <50B5E3B4.2080408@oracle.com> Message-ID: On Wed, Nov 28, 2012 at 5:13 AM, Aleksey Shipilev wrote: > On 11/28/2012 10:14 AM, Xin Tong wrote: >> I recently took some data on the performance of hotspot when hugepage >> is enabled/disabled. i found a performance difference of ~20% on >> specjbb with -Xms1024m -Xmx2048m running 4 whs. the nursery heap size >> is ~600M and tenure is ~500M. >> >> OS: Linux socrates 3.2.0-33-generic #52-Ubuntu SMP Thu Oct 18 16:29:15 >> UTC 2012 x86_64 x86_64 x86_64 GNU/Linux >> CPU: model name : Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz >> >> I am wondering does hugepage demostrate performance improvements on >> other benchmarks as well ? i see a much smaller difference for dacapo >> benchmarks. > > My interpretation: SPECjbb is known to be very memory-access intensive, > that is why improving TLB accesses gives you huge payoffs. Many Dacapo > benchmarks are compute-bound, and the TLB performance while important is > not having the same impacts. > > Many characteristic Java applications are as promiscuous with memory as > SPECjbb, and so large pages demonstrate significant improvements on > business workloads we have internally. > What other publicly available workloads would demonstrate similar performance benefit with hugepage other than SPECJbb2005 would you think ? maybe JGrande ? Xin > -Aleksey. From christian.thalinger at oracle.com Wed Nov 28 16:35:17 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 28 Nov 2012 16:35:17 -0800 Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF6C39002@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6672CB3@DEWDFECCR03.wdf.sap.corp> <9436FC33-1E4D-41DD-9D54-8CE11D718BC2@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF6673783@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6931DF6@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6C39002@DEWDFECCR03.wdf.sap.corp> Message-ID: On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz" wrote: > Hi Chris, > >> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub? > Shared code (class CompiledStaticCall) wants to patch the inline cache > in the stub which is emitted in platform code. > So the platform code should specify how the shared code can find the inline cache > in the stub, which it does through the constant I introduced. > >> Do you need two relocations? I'm confused. > No, three ;) > The relocation you mention is used to find the stub given the call. > The other relocations are needed to find the inline cache / call target > once the stub is found (see CompiledStaticCall::set_to_interpreted()). > It's just the same on x86_64: > > // static stub relocation stores the instruction address of the call > __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64); > // static stub relocation also tags the methodOop in the code-stream. > __ movoop(rbx, (jobject) NULL); // method is zapped till fixup time > // This is recognized as unresolved by relocs/nativeinst/ic code > __ jump(RuntimeAddress(__ pc())); > > On PPC, we have to load the base of the constant table after generating the > static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is > exactly what we store in the CompiledStaticCall::comp_to_int_load_offset constant. Why can't you point the relocation to the method load instruction? It doesn't seem right to do that in shared code. -- Chris > > Best regards, > Goetz. > > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Dienstag, 27. November 2012 01:53 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] > > > On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz" wrote: > >> Hi Chris, >> >> We put it into the ad file because it describes an offset into the stub that is >> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), >> used by ir node CallStaticJavaDirect. Maybe I should not call it stub, but it's >> generated into the stubs section of the code buffer. >> If that stub generator is moved out of the ad file to shared compiler code, one should >> move the field with it, but for the current implementation I think that's fine. >> >> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature? >> If so, one could protect the whole thing by #ifdef COMPILER2. > > Why do you need all these shared code changes when you have this in emit_java_to_interp_stub? > > // Create a static stub relocation which relates this stub > // with the call instruction at insts_call_instruction_offset in the > // instructions code-section. > __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset)); > > Do you need two relocations? I'm confused. > > -- Chris > >> >> Thanks for all the bugids! >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Mittwoch, 21. November 2012 19:53 >> To: Lindenmaier, Goetz >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] >> >> >> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi Chris, >>> >>> yes, there is no C1 on ppc. >>> We do tiered compilation with a stripped C2. >> >> Right. But some other architecture (or in the future) might need this for C1 as well. We should find a better place for the value than the ad file. The obvious place would be compiledIC_.hpp but we don't have that file, yet. >> >> I filed: >> >> 8003853: specify offset of IC load in java_to_interp stub >> >> -- Chris >> >>> >>> Best regards, >>> Goetz >>> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Dienstag, 20. November 2012 22:19 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-compiler-dev at openjdk.java.net >>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub. >>> >>> >>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" wrote: >>> >>>> Hi, >>>> >>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub >>>> to update the IC with NativeMovConstReg. The current implementation assumes that >>>> the load is always the first instruction in the stub. This is an artificial restriction. E.g., >>>> it might be useful to load the constant pool address (MachConstantBase) before the >>>> IC load (as we do on PPC). >>>> >>>> This change adds a constant specifying an offset from the beginning of the stub to >>>> the IC load. The offset is platform specific and 0 on sparc and x86. >>>> >>>> You can find the change here: >>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/ >>> >>> That should be fixed indeed. >>> >>> +#ifndef COMPILER2 >>> +const int CompiledStaticCall::comp_to_int_load_offset = 0; >>> >>> There is no C1 for PPC (sorry, I didn't check)? >>> >>> -- Chris >>> >>>> >>>> or in our ppc port: >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 >>>> >>>> Thank you and best regards, >>>> Goetz >>>> >>>> >>>> >>> >> > From christian.thalinger at oracle.com Wed Nov 28 17:02:23 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 28 Nov 2012 17:02:23 -0800 Subject: RFR (XXL): 8003240: x86: move MacroAssembler into a separate file Message-ID: <2EE7968E-1E69-4EFF-BB37-283219CCC363@oracle.com> [Prologue: The patch is classified as XXL but in fact it's not so bad. The biggest changes are a verbatim move from assembler_x86.{cpp,hpp} into macroAssembler_x86.{cpp,hpp}. The rest is adjustments of includes to make everything work. I also took the liberty to clean up some stuff.] http://cr.openjdk.java.net/~twisti/8003240/ 8003240: x86: move MacroAssembler into a separate file Reviewed-by: The assembler_.{cpp,hpp} files are already very big and we should split them into two files: assembler_.{cpp,hpp} macroAssembler_.{cpp,hpp} This is for x86. src/share/vm/asm/macroAssembler.hpp src/share/vm/asm/macroAssembler.inline.hpp src/cpu/x86/vm/assembler_x86.cpp src/cpu/x86/vm/macroAssembler_x86.cpp src/cpu/x86/vm/assembler_x86.hpp src/cpu/x86/vm/macroAssembler_x86.hpp src/cpu/x86/vm/assembler_x86.inline.hpp src/cpu/sparc/vm/assembler_sparc.cpp src/cpu/sparc/vm/codeBuffer_sparc.hpp src/cpu/sparc/vm/frame_sparc.hpp src/cpu/sparc/vm/frame_sparc.inline.hpp src/cpu/x86/vm/c1_LIRAssembler_x86.cpp src/cpu/x86/vm/cppInterpreter_x86.cpp src/cpu/x86/vm/frame_x86.inline.hpp src/cpu/x86/vm/icache_x86.cpp src/cpu/x86/vm/icBuffer_x86.cpp src/cpu/x86/vm/interp_masm_x86_32.hpp src/cpu/x86/vm/interp_masm_x86_64.hpp src/cpu/x86/vm/interpreter_x86_32.cpp src/cpu/x86/vm/interpreter_x86_64.cpp src/cpu/x86/vm/jniFastGetField_x86_32.cpp src/cpu/x86/vm/jniFastGetField_x86_64.cpp src/cpu/x86/vm/metaspaceShared_x86_32.cpp src/cpu/x86/vm/metaspaceShared_x86_64.cpp src/cpu/x86/vm/methodHandles_x86.cpp src/cpu/x86/vm/nativeInst_x86.cpp src/cpu/x86/vm/relocInfo_x86.cpp src/cpu/x86/vm/runtime_x86_32.cpp src/cpu/x86/vm/runtime_x86_64.cpp src/cpu/x86/vm/sharedRuntime_x86_32.cpp src/cpu/x86/vm/sharedRuntime_x86_64.cpp src/cpu/x86/vm/stubGenerator_x86_32.cpp src/cpu/x86/vm/stubGenerator_x86_64.cpp src/cpu/x86/vm/templateInterpreter_x86_32.cpp src/cpu/x86/vm/templateInterpreter_x86_64.cpp src/cpu/x86/vm/templateTable_x86_32.cpp src/cpu/x86/vm/templateTable_x86_64.cpp src/cpu/x86/vm/vm_version_x86.cpp src/cpu/x86/vm/vtableStubs_x86_32.cpp src/cpu/x86/vm/vtableStubs_x86_64.cpp src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp src/os_cpu/linux_x86/vm/os_linux_x86.cpp src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp src/os_cpu/windows_x86/vm/os_windows_x86.cpp src/os/bsd/vm/os_bsd.cpp src/os/bsd/vm/os_bsd.inline.hpp src/os/bsd/vm/osThread_bsd.cpp src/os/linux/vm/os_linux.cpp src/os/linux/vm/os_linux.inline.hpp src/os/linux/vm/osThread_linux.cpp src/os/solaris/vm/os_solaris.cpp src/os/solaris/vm/os_solaris.inline.hpp src/os/solaris/vm/osThread_solaris.cpp src/os/windows/vm/os_windows.cpp src/os/windows/vm/os_windows.inline.hpp src/os/windows/vm/osThread_windows.cpp src/share/vm/asm/assembler.cpp src/share/vm/asm/assembler.hpp src/share/vm/asm/assembler.inline.hpp src/share/vm/asm/codeBuffer.cpp src/share/vm/asm/codeBuffer.hpp src/share/vm/c1/c1_MacroAssembler.hpp src/share/vm/code/icBuffer.cpp src/share/vm/code/relocInfo.cpp src/share/vm/interpreter/interpreter.cpp src/share/vm/interpreter/interpreterRuntime.cpp src/share/vm/opto/compile.cpp src/share/vm/runtime/atomic.cpp src/share/vm/runtime/atomic.hpp src/share/vm/runtime/atomic.inline.hpp src/share/vm/runtime/frame.cpp src/share/vm/runtime/frame.hpp src/share/vm/runtime/sharedRuntime.cpp src/share/vm/runtime/stubCodeGenerator.cpp From Vladimir.Kozlov at oracle.com Wed Nov 28 21:01:06 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 28 Nov 2012 21:01:06 -0800 Subject: RFR (XXL): 8003240: x86: move MacroAssembler into a separate file In-Reply-To: <2EE7968E-1E69-4EFF-BB37-283219CCC363@oracle.com> References: <2EE7968E-1E69-4EFF-BB37-283219CCC363@oracle.com> Message-ID: <50B6EC12.9070105@oracle.com> Looks good to me. Thanks, Vladimir On 11/28/12 17:02, Christian Thalinger wrote: > [Prologue: The patch is classified as XXL but in fact it's not so bad. The biggest changes are a verbatim move from assembler_x86.{cpp,hpp} into macroAssembler_x86.{cpp,hpp}. The rest is adjustments of includes to make everything work. I also took the liberty to clean up some stuff.] > > http://cr.openjdk.java.net/~twisti/8003240/ > > 8003240: x86: move MacroAssembler into a separate file > Reviewed-by: > > The assembler_.{cpp,hpp} files are already very big and we should split them into two files: > > assembler_.{cpp,hpp} > macroAssembler_.{cpp,hpp} > > This is for x86. > > src/share/vm/asm/macroAssembler.hpp > src/share/vm/asm/macroAssembler.inline.hpp > src/cpu/x86/vm/assembler_x86.cpp > src/cpu/x86/vm/macroAssembler_x86.cpp > src/cpu/x86/vm/assembler_x86.hpp > src/cpu/x86/vm/macroAssembler_x86.hpp > src/cpu/x86/vm/assembler_x86.inline.hpp > src/cpu/sparc/vm/assembler_sparc.cpp > src/cpu/sparc/vm/codeBuffer_sparc.hpp > src/cpu/sparc/vm/frame_sparc.hpp > src/cpu/sparc/vm/frame_sparc.inline.hpp > src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > src/cpu/x86/vm/cppInterpreter_x86.cpp > src/cpu/x86/vm/frame_x86.inline.hpp > src/cpu/x86/vm/icache_x86.cpp > src/cpu/x86/vm/icBuffer_x86.cpp > src/cpu/x86/vm/interp_masm_x86_32.hpp > src/cpu/x86/vm/interp_masm_x86_64.hpp > src/cpu/x86/vm/interpreter_x86_32.cpp > src/cpu/x86/vm/interpreter_x86_64.cpp > src/cpu/x86/vm/jniFastGetField_x86_32.cpp > src/cpu/x86/vm/jniFastGetField_x86_64.cpp > src/cpu/x86/vm/metaspaceShared_x86_32.cpp > src/cpu/x86/vm/metaspaceShared_x86_64.cpp > src/cpu/x86/vm/methodHandles_x86.cpp > src/cpu/x86/vm/nativeInst_x86.cpp > src/cpu/x86/vm/relocInfo_x86.cpp > src/cpu/x86/vm/runtime_x86_32.cpp > src/cpu/x86/vm/runtime_x86_64.cpp > src/cpu/x86/vm/sharedRuntime_x86_32.cpp > src/cpu/x86/vm/sharedRuntime_x86_64.cpp > src/cpu/x86/vm/stubGenerator_x86_32.cpp > src/cpu/x86/vm/stubGenerator_x86_64.cpp > src/cpu/x86/vm/templateInterpreter_x86_32.cpp > src/cpu/x86/vm/templateInterpreter_x86_64.cpp > src/cpu/x86/vm/templateTable_x86_32.cpp > src/cpu/x86/vm/templateTable_x86_64.cpp > src/cpu/x86/vm/vm_version_x86.cpp > src/cpu/x86/vm/vtableStubs_x86_32.cpp > src/cpu/x86/vm/vtableStubs_x86_64.cpp > src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp > src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp > src/os_cpu/linux_x86/vm/os_linux_x86.cpp > src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp > src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp > src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp > src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp > src/os_cpu/windows_x86/vm/os_windows_x86.cpp > src/os/bsd/vm/os_bsd.cpp > src/os/bsd/vm/os_bsd.inline.hpp > src/os/bsd/vm/osThread_bsd.cpp > src/os/linux/vm/os_linux.cpp > src/os/linux/vm/os_linux.inline.hpp > src/os/linux/vm/osThread_linux.cpp > src/os/solaris/vm/os_solaris.cpp > src/os/solaris/vm/os_solaris.inline.hpp > src/os/solaris/vm/osThread_solaris.cpp > src/os/windows/vm/os_windows.cpp > src/os/windows/vm/os_windows.inline.hpp > src/os/windows/vm/osThread_windows.cpp > src/share/vm/asm/assembler.cpp > src/share/vm/asm/assembler.hpp > src/share/vm/asm/assembler.inline.hpp > src/share/vm/asm/codeBuffer.cpp > src/share/vm/asm/codeBuffer.hpp > src/share/vm/c1/c1_MacroAssembler.hpp > src/share/vm/code/icBuffer.cpp > src/share/vm/code/relocInfo.cpp > src/share/vm/interpreter/interpreter.cpp > src/share/vm/interpreter/interpreterRuntime.cpp > src/share/vm/opto/compile.cpp > src/share/vm/runtime/atomic.cpp > src/share/vm/runtime/atomic.hpp > src/share/vm/runtime/atomic.inline.hpp > src/share/vm/runtime/frame.cpp > src/share/vm/runtime/frame.hpp > src/share/vm/runtime/sharedRuntime.cpp > src/share/vm/runtime/stubCodeGenerator.cpp > From rednaxelafx at gmail.com Wed Nov 28 21:53:05 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 29 Nov 2012 13:53:05 +0800 Subject: Insert Special Code Sequence After Object allocation In-Reply-To: References: <50B591D5.7010909@oracle.com> <50B5B0A0.1010504@oracle.com> Message-ID: Simply specify -XX:-UseTLAB on the command line, or change its default value in runtime/globals.hpp will do. - Kris On Wed, Nov 28, 2012 at 3:20 PM, Xin Tong wrote: > Is there a way to turn off UseTLAB BTW ? it is turned on by default here. > void PhaseMacroExpand::expand_allocate_common( > AllocateNode* alloc, // allocation node to be expanded > Node* length, // array length for an array allocation > const TypeFunc* slow_call_type, // Type of slow call > address slow_call_address // Address of slow call > ) > > { > ... > printf("UseTLAB is %d\n", UseTLAB); > if (C->env()->dtrace_alloc_probes() || > !UseTLAB && (!Universe::heap()->supports_inline_contig_alloc() || > (UseConcMarkSweepGC && CMSIncrementalMode))) { > // Force slow-path allocation > printf("Force slow-path allocation\n"); > always_slow = true; > initial_slow_test = NULL; > } > ... > } > > > > Xin > > On Wed, Nov 28, 2012 at 1:51 AM, Xin Tong wrote: >> On Wed, Nov 28, 2012 at 1:35 AM, Krystal Mo wrote: >>> On 11/28/2012 02:02 PM, Xin Tong wrote: >>>> >>>> On Wed, Nov 28, 2012 at 12:58 AM, Xin Tong >>>> wrote: >>>>> >>>>> On Tue, Nov 27, 2012 at 11:23 PM, Krystal Mo >>>>> wrote: >>>>>> >>>>>> Hi Xin, >>>>>> >>>>>> Depends on what the code sequence is and what it does. >>>>>> >>>>>> If the code sequence you're inserting can be represented in C2's IR >>>>>> nodes, >>>>>> then you can try to add those nodes in either >>>>>> PhaseMacroExpand::expand_allocate_common() or >>>>>> PhaseMacroExpand::initialize_object(), or somewhere else around. >>>>>> >>>>> It is a few assembly instructions. can i wrap the assemblies in a >>>>> function that hasa prologue and epilogue to save everything. and does >>>>> the IR has any way of calling a function ? >>>>> >>>>> Xin >>>> >>>> Or another thing i am willing to do is to force the JIT to always fail >>>> on the inlined allocation and force it to the out-of-line ( VM >>>> managed) allocation. I just do not want to turn the JIT completely off >>>> as that have an big impact on the behaviours of the program. Is this >>>> doable ? >>> >>> Sure, if you're willing take the performance hit. >>> >>> It's easy: in PhaseMacroExpand::expand_allocate_common(), just make sure the >>> local variables initial_slow_test and always_slow are assigned NULL and true >>> respectively, and there you go. It'll call into >>> OptoRuntime::new_instance_C(). >>> >> >> I change the bool always_slow = true; it runs ok. but when i change >> Node* initial_slow_test = NULL ; >> //alloc->in(AllocateNode::InitialTest); >> the VM crashes. Is it necessary to make initial_slow_test to NULL ? is >> not initial_slow_test used to initialize allocattion from slow path ? >> >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00007fd6d0e58572, pid=18333, tid=140560399947520 >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode linux-amd64 >> compressed oops) >> # Problematic frame: >> # V [libjvm.so+0x7b6572] BoolNode::make_predicate(Node*, PhaseGVN*)+0x22 >> # >> # Failed to write core dump. Core dumps have been disabled. To enable >> core dumping, try "ulimit -c unlimited" before starting Java again >> # >> # An error report file with more information is saved as: >> # /home/xtong/fastcache/benchmarks/SPECJBB2005/hs_err_pid18333.log >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # >> ./run.sh: line 13: 18333 Aborted (core dumped) java >> -Xms1024m -Xmx2048m spec.jbb.JBBmain -propfile SPECjbb.props >> >> >> Xin >> >> >> >>> - Kris >>> >>> >>>> Xin >>>> >>>>>> If your code sequence cannot be represented in C2's IR, well, that will >>>>>> take >>>>>> some effort. The AllocateNode is lost after PhaseMacroExpand, so you >>>>>> can't >>>>>> use it as a mark to insert your code. You might want to use >>>>>> prefetchAlloc in >>>>>> the AD files as a place to insert code, if that works for your purpose. >>>>>> >>>>>> That said, though, if the code sequence could be written in Java >>>>>> bytecode, >>>>>> that'll be the easiest solution: don't have to touch the VM, just do >>>>>> bytecode instrumentation. >>>>>> >>>>>> - Kris >>>>>> >>>>>> >>>>>> On 2012/11/28 10:36, Xin Tong wrote: >>>>>>> >>>>>>> I would like to insert a special binary code sequence after the >>>>>>> allocation of a java object in the opto JIT code. can anyone tell me >>>>>>> how to do that ? >>>>>>> >>>>>>> Xin >>> >>> From rednaxelafx at gmail.com Wed Nov 28 22:09:39 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 29 Nov 2012 14:09:39 +0800 Subject: Insert Special Code Sequence After Object allocation In-Reply-To: References: <50B591D5.7010909@oracle.com> <50B5B0A0.1010504@oracle.com> Message-ID: Simply specify -XX:-UseTLAB on the command line, or change its default value in runtime/globals.hpp will do. - Kris On Wed, Nov 28, 2012 at 3:20 PM, Xin Tong wrote: > Is there a way to turn off UseTLAB BTW ? it is turned on by default here. > void PhaseMacroExpand::expand_allocate_common( > AllocateNode* alloc, // allocation node to be expanded > Node* length, // array length for an array allocation > const TypeFunc* slow_call_type, // Type of slow call > address slow_call_address // Address of slow call > ) > > { > ... > printf("UseTLAB is %d\n", UseTLAB); > if (C->env()->dtrace_alloc_probes() || > !UseTLAB && (!Universe::heap()->supports_inline_contig_alloc() || > (UseConcMarkSweepGC && CMSIncrementalMode))) { > // Force slow-path allocation > printf("Force slow-path allocation\n"); > always_slow = true; > initial_slow_test = NULL; > } > ... > } > > > > Xin > > On Wed, Nov 28, 2012 at 1:51 AM, Xin Tong wrote: >> On Wed, Nov 28, 2012 at 1:35 AM, Krystal Mo wrote: >>> On 11/28/2012 02:02 PM, Xin Tong wrote: >>>> >>>> On Wed, Nov 28, 2012 at 12:58 AM, Xin Tong >>>> wrote: >>>>> >>>>> On Tue, Nov 27, 2012 at 11:23 PM, Krystal Mo >>>>> wrote: >>>>>> >>>>>> Hi Xin, >>>>>> >>>>>> Depends on what the code sequence is and what it does. >>>>>> >>>>>> If the code sequence you're inserting can be represented in C2's IR >>>>>> nodes, >>>>>> then you can try to add those nodes in either >>>>>> PhaseMacroExpand::expand_allocate_common() or >>>>>> PhaseMacroExpand::initialize_object(), or somewhere else around. >>>>>> >>>>> It is a few assembly instructions. can i wrap the assemblies in a >>>>> function that hasa prologue and epilogue to save everything. and does >>>>> the IR has any way of calling a function ? >>>>> >>>>> Xin >>>> >>>> Or another thing i am willing to do is to force the JIT to always fail >>>> on the inlined allocation and force it to the out-of-line ( VM >>>> managed) allocation. I just do not want to turn the JIT completely off >>>> as that have an big impact on the behaviours of the program. Is this >>>> doable ? >>> >>> Sure, if you're willing take the performance hit. >>> >>> It's easy: in PhaseMacroExpand::expand_allocate_common(), just make sure the >>> local variables initial_slow_test and always_slow are assigned NULL and true >>> respectively, and there you go. It'll call into >>> OptoRuntime::new_instance_C(). >>> >> >> I change the bool always_slow = true; it runs ok. but when i change >> Node* initial_slow_test = NULL ; >> //alloc->in(AllocateNode::InitialTest); >> the VM crashes. Is it necessary to make initial_slow_test to NULL ? is >> not initial_slow_test used to initialize allocattion from slow path ? >> >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # SIGSEGV (0xb) at pc=0x00007fd6d0e58572, pid=18333, tid=140560399947520 >> # >> # JRE version: 7.0 >> # Java VM: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode linux-amd64 >> compressed oops) >> # Problematic frame: >> # V [libjvm.so+0x7b6572] BoolNode::make_predicate(Node*, PhaseGVN*)+0x22 >> # >> # Failed to write core dump. Core dumps have been disabled. To enable >> core dumping, try "ulimit -c unlimited" before starting Java again >> # >> # An error report file with more information is saved as: >> # /home/xtong/fastcache/benchmarks/SPECJBB2005/hs_err_pid18333.log >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.sun.com/bugreport/crash.jsp >> # >> ./run.sh: line 13: 18333 Aborted (core dumped) java >> -Xms1024m -Xmx2048m spec.jbb.JBBmain -propfile SPECjbb.props >> >> >> Xin >> >> >> >>> - Kris >>> >>> >>>> Xin >>>> >>>>>> If your code sequence cannot be represented in C2's IR, well, that will >>>>>> take >>>>>> some effort. The AllocateNode is lost after PhaseMacroExpand, so you >>>>>> can't >>>>>> use it as a mark to insert your code. You might want to use >>>>>> prefetchAlloc in >>>>>> the AD files as a place to insert code, if that works for your purpose. >>>>>> >>>>>> That said, though, if the code sequence could be written in Java >>>>>> bytecode, >>>>>> that'll be the easiest solution: don't have to touch the VM, just do >>>>>> bytecode instrumentation. >>>>>> >>>>>> - Kris >>>>>> >>>>>> >>>>>> On 2012/11/28 10:36, Xin Tong wrote: >>>>>>> >>>>>>> I would like to insert a special binary code sequence after the >>>>>>> allocation of a java object in the opto JIT code. can anyone tell me >>>>>>> how to do that ? >>>>>>> >>>>>>> Xin >>> >>> From goetz.lindenmaier at sap.com Thu Nov 29 00:27:02 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 29 Nov 2012 09:27:02 +0100 Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] In-Reply-To: References: <140FA3E3585AD840A3316D2853F974DC1BF6672CB3@DEWDFECCR03.wdf.sap.corp> <9436FC33-1E4D-41DD-9D54-8CE11D718BC2@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF6673783@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6931DF6@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6C39002@DEWDFECCR03.wdf.sap.corp> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF6D1B1DD@DEWDFECCR03.wdf.sap.corp> Hi Chris, > Why can't you point the relocation to the method load instruction? It doesn't seem right to do that in shared code. Because the relocation is used 1.) to find the beginning of the stub to patch the call to go there 2.) to find the load to patch the IC. Just have a look at CompiledStaticCall::set_to_interpreted(), the variable 'stub' is used twice. Best regards, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Donnerstag, 29. November 2012 01:35 To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz" wrote: > Hi Chris, > >> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub? > Shared code (class CompiledStaticCall) wants to patch the inline cache > in the stub which is emitted in platform code. > So the platform code should specify how the shared code can find the inline cache > in the stub, which it does through the constant I introduced. > >> Do you need two relocations? I'm confused. > No, three ;) > The relocation you mention is used to find the stub given the call. > The other relocations are needed to find the inline cache / call target > once the stub is found (see CompiledStaticCall::set_to_interpreted()). > It's just the same on x86_64: > > // static stub relocation stores the instruction address of the call > __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64); > // static stub relocation also tags the methodOop in the code-stream. > __ movoop(rbx, (jobject) NULL); // method is zapped till fixup time > // This is recognized as unresolved by relocs/nativeinst/ic code > __ jump(RuntimeAddress(__ pc())); > > On PPC, we have to load the base of the constant table after generating the > static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is > exactly what we store in the CompiledStaticCall::comp_to_int_load_offset constant. Why can't you point the relocation to the method load instruction? It doesn't seem right to do that in shared code. -- Chris > > Best regards, > Goetz. > > > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Dienstag, 27. November 2012 01:53 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] > > > On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz" wrote: > >> Hi Chris, >> >> We put it into the ad file because it describes an offset into the stub that is >> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), >> used by ir node CallStaticJavaDirect. Maybe I should not call it stub, but it's >> generated into the stubs section of the code buffer. >> If that stub generator is moved out of the ad file to shared compiler code, one should >> move the field with it, but for the current implementation I think that's fine. >> >> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature? >> If so, one could protect the whole thing by #ifdef COMPILER2. > > Why do you need all these shared code changes when you have this in emit_java_to_interp_stub? > > // Create a static stub relocation which relates this stub > // with the call instruction at insts_call_instruction_offset in the > // instructions code-section. > __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset)); > > Do you need two relocations? I'm confused. > > -- Chris > >> >> Thanks for all the bugids! >> >> Best regards, >> Goetz. >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Mittwoch, 21. November 2012 19:53 >> To: Lindenmaier, Goetz >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] >> >> >> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi Chris, >>> >>> yes, there is no C1 on ppc. >>> We do tiered compilation with a stripped C2. >> >> Right. But some other architecture (or in the future) might need this for C1 as well. We should find a better place for the value than the ad file. The obvious place would be compiledIC_.hpp but we don't have that file, yet. >> >> I filed: >> >> 8003853: specify offset of IC load in java_to_interp stub >> >> -- Chris >> >>> >>> Best regards, >>> Goetz >>> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Dienstag, 20. November 2012 22:19 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-compiler-dev at openjdk.java.net >>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub. >>> >>> >>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" wrote: >>> >>>> Hi, >>>> >>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub >>>> to update the IC with NativeMovConstReg. The current implementation assumes that >>>> the load is always the first instruction in the stub. This is an artificial restriction. E.g., >>>> it might be useful to load the constant pool address (MachConstantBase) before the >>>> IC load (as we do on PPC). >>>> >>>> This change adds a constant specifying an offset from the beginning of the stub to >>>> the IC load. The offset is platform specific and 0 on sparc and x86. >>>> >>>> You can find the change here: >>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/ >>> >>> That should be fixed indeed. >>> >>> +#ifndef COMPILER2 >>> +const int CompiledStaticCall::comp_to_int_load_offset = 0; >>> >>> There is no C1 for PPC (sorry, I didn't check)? >>> >>> -- Chris >>> >>>> >>>> or in our ppc port: >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 >>>> >>>> Thank you and best regards, >>>> Goetz >>>> >>>> >>>> >>> >> > From bharadwaj.yadavalli at oracle.com Thu Nov 29 08:07:04 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 29 Nov 2012 11:07:04 -0500 Subject: RFR (S): 8003195 - AbstractAssembler should not store code pointers but use the CodeSection directly Message-ID: <50B78828.4000105@oracle.com> Please review http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ This change is a result of applying the patch from Christian Thalinger attached in the bug report with a couple of minor tweaks and are for x86 architecture only. Thanks, Bharadwaj From christian.thalinger at oracle.com Thu Nov 29 10:33:00 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 29 Nov 2012 10:33:00 -0800 Subject: RFR (S): 8003195 - AbstractAssembler should not store code pointers but use the CodeSection directly In-Reply-To: <50B78828.4000105@oracle.com> References: <50B78828.4000105@oracle.com> Message-ID: <4BFD3B2F-019A-4AFB-9A8E-A728837F850E@oracle.com> On Nov 29, 2012, at 8:07 AM, Bharadwaj Yadavalli wrote: > Please review > http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ > > This change is a result of applying the patch from Christian Thalinger attached in the bug report with a couple of minor tweaks and are for x86 architecture only. Thanks for taking care of this. The change looks good. A test JPRT job was fine? -- Chris > > Thanks, > > Bharadwaj > From bharadwaj.yadavalli at oracle.com Thu Nov 29 10:41:45 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 29 Nov 2012 13:41:45 -0500 Subject: RFR (S): 8003195 - AbstractAssembler should not store code pointers but use the CodeSection directly In-Reply-To: <4BFD3B2F-019A-4AFB-9A8E-A728837F850E@oracle.com> References: <50B78828.4000105@oracle.com> <4BFD3B2F-019A-4AFB-9A8E-A728837F850E@oracle.com> Message-ID: <50B7AC69.50104@oracle.com> On 11/29/2012 1:33 PM, Christian Thalinger wrote: > On Nov 29, 2012, at 8:07 AM, Bharadwaj Yadavalli wrote: > >> Please review >> http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ >> >> This change is a result of applying the patch from Christian Thalinger attached in the bug report with a couple of minor tweaks and are for x86 architecture only. > Thanks for taking care of this. The change looks good. A test JPRT job was fine? Yes. JPRT test succeeded. Thanks, Bharadwaj From christian.thalinger at oracle.com Thu Nov 29 10:53:17 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 29 Nov 2012 10:53:17 -0800 Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] In-Reply-To: <140FA3E3585AD840A3316D2853F974DC1BF6D1B1DD@DEWDFECCR03.wdf.sap.corp> References: <140FA3E3585AD840A3316D2853F974DC1BF6672CB3@DEWDFECCR03.wdf.sap.corp> <9436FC33-1E4D-41DD-9D54-8CE11D718BC2@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF6673783@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6931DF6@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6C39002@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6D1B1DD@DEWDFECCR03.wdf.sap.corp> Message-ID: <2A438E2B-8690-4D49-B15F-8E9B4DEDFE61@oracle.com> On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz" wrote: > Hi Chris, > >> Why can't you point the relocation to the method load instruction? It doesn't seem right to do that in shared code. > Because the relocation is used > 1.) to find the beginning of the stub to patch the call to go there > 2.) to find the load to patch the IC. Got it. > > Just have a look at CompiledStaticCall::set_to_interpreted(), > the variable 'stub' is used twice. Sorry for being so persistent on this :-) What is the reason you have to load the constant from the constant table? On other architectures we materialize the constant. -- Chris > > Best regards, > Goetz. > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Donnerstag, 29. November 2012 01:35 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] > > > On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz" wrote: > >> Hi Chris, >> >>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub? >> Shared code (class CompiledStaticCall) wants to patch the inline cache >> in the stub which is emitted in platform code. >> So the platform code should specify how the shared code can find the inline cache >> in the stub, which it does through the constant I introduced. >> >>> Do you need two relocations? I'm confused. >> No, three ;) >> The relocation you mention is used to find the stub given the call. >> The other relocations are needed to find the inline cache / call target >> once the stub is found (see CompiledStaticCall::set_to_interpreted()). >> It's just the same on x86_64: >> >> // static stub relocation stores the instruction address of the call >> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64); >> // static stub relocation also tags the methodOop in the code-stream. >> __ movoop(rbx, (jobject) NULL); // method is zapped till fixup time >> // This is recognized as unresolved by relocs/nativeinst/ic code >> __ jump(RuntimeAddress(__ pc())); >> >> On PPC, we have to load the base of the constant table after generating the >> static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is >> exactly what we store in the CompiledStaticCall::comp_to_int_load_offset constant. > > Why can't you point the relocation to the method load instruction? It doesn't seem right to do that in shared code. > > -- Chris > >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Dienstag, 27. November 2012 01:53 >> To: Lindenmaier, Goetz >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] >> >> >> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi Chris, >>> >>> We put it into the ad file because it describes an offset into the stub that is >>> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), >>> used by ir node CallStaticJavaDirect. Maybe I should not call it stub, but it's >>> generated into the stubs section of the code buffer. >>> If that stub generator is moved out of the ad file to shared compiler code, one should >>> move the field with it, but for the current implementation I think that's fine. >>> >>> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature? >>> If so, one could protect the whole thing by #ifdef COMPILER2. >> >> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub? >> >> // Create a static stub relocation which relates this stub >> // with the call instruction at insts_call_instruction_offset in the >> // instructions code-section. >> __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset)); >> >> Do you need two relocations? I'm confused. >> >> -- Chris >> >>> >>> Thanks for all the bugids! >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Mittwoch, 21. November 2012 19:53 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-compiler-dev at openjdk.java.net >>> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] >>> >>> >>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz" wrote: >>> >>>> Hi Chris, >>>> >>>> yes, there is no C1 on ppc. >>>> We do tiered compilation with a stripped C2. >>> >>> Right. But some other architecture (or in the future) might need this for C1 as well. We should find a better place for the value than the ad file. The obvious place would be compiledIC_.hpp but we don't have that file, yet. >>> >>> I filed: >>> >>> 8003853: specify offset of IC load in java_to_interp stub >>> >>> -- Chris >>> >>>> >>>> Best regards, >>>> Goetz >>>> >>>> -----Original Message----- >>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> Sent: Dienstag, 20. November 2012 22:19 >>>> To: Lindenmaier, Goetz >>>> Cc: hotspot-compiler-dev at openjdk.java.net >>>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub. >>>> >>>> >>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" wrote: >>>> >>>>> Hi, >>>>> >>>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub >>>>> to update the IC with NativeMovConstReg. The current implementation assumes that >>>>> the load is always the first instruction in the stub. This is an artificial restriction. E.g., >>>>> it might be useful to load the constant pool address (MachConstantBase) before the >>>>> IC load (as we do on PPC). >>>>> >>>>> This change adds a constant specifying an offset from the beginning of the stub to >>>>> the IC load. The offset is platform specific and 0 on sparc and x86. >>>>> >>>>> You can find the change here: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/ >>>> >>>> That should be fixed indeed. >>>> >>>> +#ifndef COMPILER2 >>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0; >>>> >>>> There is no C1 for PPC (sorry, I didn't check)? >>>> >>>> -- Chris >>>> >>>>> >>>>> or in our ppc port: >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 >>>>> >>>>> Thank you and best regards, >>>>> Goetz >>>>> >>>>> >>>>> >>>> >>> >> > From christian.thalinger at oracle.com Thu Nov 29 10:53:52 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 29 Nov 2012 10:53:52 -0800 Subject: RFR (S): 8003195 - AbstractAssembler should not store code pointers but use the CodeSection directly In-Reply-To: <50B7AC69.50104@oracle.com> References: <50B78828.4000105@oracle.com> <4BFD3B2F-019A-4AFB-9A8E-A728837F850E@oracle.com> <50B7AC69.50104@oracle.com> Message-ID: On Nov 29, 2012, at 10:41 AM, Bharadwaj Yadavalli wrote: > On 11/29/2012 1:33 PM, Christian Thalinger wrote: >> On Nov 29, 2012, at 8:07 AM, Bharadwaj Yadavalli wrote: >> >>> Please review >>> http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ >>> >>> This change is a result of applying the patch from Christian Thalinger attached in the bug report with a couple of minor tweaks and are for x86 architecture only. >> Thanks for taking care of this. The change looks good. A test JPRT job was fine? > > Yes. JPRT test succeeded. Great. I will push this one for you. -- Chris > > Thanks, > > Bharadwaj > From bharadwaj.yadavalli at oracle.com Thu Nov 29 10:56:22 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 29 Nov 2012 13:56:22 -0500 Subject: RFR (S): 8003195 - AbstractAssembler should not store code pointers but use the CodeSection directly In-Reply-To: References: <50B78828.4000105@oracle.com> <4BFD3B2F-019A-4AFB-9A8E-A728837F850E@oracle.com> <50B7AC69.50104@oracle.com> Message-ID: <50B7AFD6.8080405@oracle.com> On 11/29/2012 1:53 PM, Christian Thalinger wrote: > Great. I will push this one for you. -- Chris Thank you. Bharadwaj From vladimir.kozlov at oracle.com Thu Nov 29 11:33:02 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Nov 2012 11:33:02 -0800 Subject: RFR (S): 8003195 - AbstractAssembler should not store code pointers but use the CodeSection directly In-Reply-To: <50B78828.4000105@oracle.com> References: <50B78828.4000105@oracle.com> Message-ID: I don't like explicit casting of address to int64 or int32. I would prefer original code moved to codeBuffer as other functions. An other good cleanup would be remove emit_word() and emit_long() which are very confusing sizewise. But it is for next round. Thanks, Vladimir On Nov 29, 2012, at 8:07 AM, Bharadwaj Yadavalli wrote: > Please review > http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ > > This change is a result of applying the patch from Christian Thalinger attached in the bug report with a couple of minor tweaks and are for x86 architecture only. > > Thanks, > > Bharadwaj > From christian.thalinger at oracle.com Thu Nov 29 11:48:37 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 29 Nov 2012 11:48:37 -0800 Subject: RFR (S): 8003195 - AbstractAssembler should not store code pointers but use the CodeSection directly In-Reply-To: References: <50B78828.4000105@oracle.com> Message-ID: On Nov 29, 2012, at 11:33 AM, Vladimir Kozlov wrote: > I don't like explicit casting of address to int64 or int32. I would prefer original code moved to codeBuffer as other functions. You're saying adding: + void emit_address( address x) { *((address*) end()) = x; set_end(end() + sizeof(address)); } to CodeSection? > > An other good cleanup would be remove emit_word() and emit_long() which are very confusing sizewise. But it is for next round. Yes. That's the plan for my other upcoming changes. This is the first step in that direction. -- Chris > > Thanks, > Vladimir > > > On Nov 29, 2012, at 8:07 AM, Bharadwaj Yadavalli wrote: > >> Please review >> http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ >> >> This change is a result of applying the patch from Christian Thalinger attached in the bug report with a couple of minor tweaks and are for x86 architecture only. >> >> Thanks, >> >> Bharadwaj >> > From vladimir.kozlov at oracle.com Thu Nov 29 11:48:40 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Nov 2012 11:48:40 -0800 Subject: RFR (S): 8003195 - AbstractAssembler should not store code pointers but use the CodeSection directly In-Reply-To: References: <50B78828.4000105@oracle.com> Message-ID: <3269FCE1-B766-42A6-8EE6-E62A96F63051@oracle.com> On Nov 29, 2012, at 11:48 AM, Christian Thalinger wrote: > > On Nov 29, 2012, at 11:33 AM, Vladimir Kozlov wrote: > >> I don't like explicit casting of address to int64 or int32. I would prefer original code moved to codeBuffer as other functions. > > You're saying adding: > > + void emit_address( address x) { *((address*) end()) = x; set_end(end() + sizeof(address)); } > > to CodeSection? Yes. > >> >> An other good cleanup would be remove emit_word() and emit_long() which are very confusing sizewise. But it is for next round. > > Yes. That's the plan for my other upcoming changes. This is the first step in that direction. OK. Vladimir > > -- Chris > >> >> Thanks, >> Vladimir >> >> >> On Nov 29, 2012, at 8:07 AM, Bharadwaj Yadavalli wrote: >> >>> Please review >>> http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ >>> >>> This change is a result of applying the patch from Christian Thalinger attached in the bug report with a couple of minor tweaks and are for x86 architecture only. >>> >>> Thanks, >>> >>> Bharadwaj >>> >> > From bharadwaj.yadavalli at oracle.com Thu Nov 29 11:52:07 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Thu, 29 Nov 2012 14:52:07 -0500 Subject: RFR (S): 8003195 - AbstractAssembler should not store code pointers but use the CodeSection directly In-Reply-To: <3269FCE1-B766-42A6-8EE6-E62A96F63051@oracle.com> References: <50B78828.4000105@oracle.com> <3269FCE1-B766-42A6-8EE6-E62A96F63051@oracle.com> Message-ID: <50B7BCE7.3050407@oracle.com> On 11/29/2012 2:48 PM, Vladimir Kozlov wrote: > On Nov 29, 2012, at 11:48 AM, Christian Thalinger wrote: > >> On Nov 29, 2012, at 11:33 AM, Vladimir Kozlov wrote: >> >>> I don't like explicit casting of address to int64 or int32. I would prefer original code moved to codeBuffer as other functions. >> You're saying adding: >> >> + void emit_address( address x) { *((address*) end()) = x; set_end(end() + sizeof(address)); } >> >> to CodeSection? > Yes. OK. I'll try to change that. Bharadwaj From david.r.chase at oracle.com Thu Nov 29 12:48:29 2012 From: david.r.chase at oracle.com (David Chase) Date: Thu, 29 Nov 2012 15:48:29 -0500 Subject: Request for reviews (S): 8001885 : JSR 292 classes should use jdk.internal.org.objectweb.asm Message-ID: <4DAC718F-42DF-427A-BA40-081971790175@oracle.com> JSR 292 should reference the JDK copy (subset, internal use only) of Asm, not the one from jaxws. This change fixes the references. It built, it passed tests. Grepped for other instances of the old package, saw them only in jaxws. http://cr.openjdk.java.net/~drchase/8001885/webrev.00/ thanks, David From christian.thalinger at oracle.com Thu Nov 29 13:33:54 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 29 Nov 2012 13:33:54 -0800 Subject: Request for reviews (S): 8001885 : JSR 292 classes should use jdk.internal.org.objectweb.asm In-Reply-To: <4DAC718F-42DF-427A-BA40-081971790175@oracle.com> References: <4DAC718F-42DF-427A-BA40-081971790175@oracle.com> Message-ID: <46ECBA20-791D-4C7B-BA8F-5F0C90BCD543@oracle.com> Looks good. -- Chris On Nov 29, 2012, at 12:48 PM, David Chase wrote: > > JSR 292 should reference the JDK copy (subset, internal use only) of Asm, not the one from jaxws. > This change fixes the references. > > It built, it passed tests. > Grepped for other instances of the old package, saw them only in jaxws. > > http://cr.openjdk.java.net/~drchase/8001885/webrev.00/ > > thanks, > > David > From vladimir.kozlov at oracle.com Thu Nov 29 13:32:50 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 29 Nov 2012 13:32:50 -0800 Subject: Request for reviews (S): 8001885 : JSR 292 classes should use jdk.internal.org.objectweb.asm In-Reply-To: <4DAC718F-42DF-427A-BA40-081971790175@oracle.com> References: <4DAC718F-42DF-427A-BA40-081971790175@oracle.com> Message-ID: <39A6B142-658E-4557-8A77-C2B6089146EA@oracle.com> Looks good. Vladimir On Nov 29, 2012, at 12:48 PM, David Chase wrote: > > JSR 292 should reference the JDK copy (subset, internal use only) of Asm, not the one from jaxws. > This change fixes the references. > > It built, it passed tests. > Grepped for other instances of the old package, saw them only in jaxws. > > http://cr.openjdk.java.net/~drchase/8001885/webrev.00/ > > thanks, > > David > From goetz.lindenmaier at sap.com Thu Nov 29 14:10:43 2012 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 29 Nov 2012 23:10:43 +0100 Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] In-Reply-To: <2A438E2B-8690-4D49-B15F-8E9B4DEDFE61@oracle.com> References: <140FA3E3585AD840A3316D2853F974DC1BF6672CB3@DEWDFECCR03.wdf.sap.corp> <9436FC33-1E4D-41DD-9D54-8CE11D718BC2@oracle.com> <140FA3E3585AD840A3316D2853F974DC1BF6673783@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6931DF6@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6C39002@DEWDFECCR03.wdf.sap.corp> <140FA3E3585AD840A3316D2853F974DC1BF6D1B1DD@DEWDFECCR03.wdf.sap.corp> <2A438E2B-8690-4D49-B15F-8E9B4DEDFE61@oracle.com> Message-ID: <140FA3E3585AD840A3316D2853F974DC1BF699BB95@DEWDFECCR03.wdf.sap.corp> Hi Chris, Loading the constant takes 5 instructions, the other way only three, in the code only one, if the constant pool base is in a register. The 5 instructions are hard to patch atomically. The constant pool is just a 64 bit store. > Sorry for being so persistent on this :-) That's ok, I already found several places in our VM where it was easy to change our code to get along without the shared changes we did in first place. But I can't redesign everything, and I can not risk to break anything in our product. If you feel like doing so, you can have a look at http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/600ce596eea9 which contains our bytecode interpreter profiling implementation. If you think this is currently of use in the main branch, I would lift it to HS25 (the permgen changes might cause trouble) and contribute it to hsx. Best regards, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Thursday, November 29, 2012 7:53 PM To: Lindenmaier, Goetz Cc: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] On Nov 29, 2012, at 12:27 AM, "Lindenmaier, Goetz" wrote: > Hi Chris, > >> Why can't you point the relocation to the method load instruction? It doesn't seem right to do that in shared code. > Because the relocation is used > 1.) to find the beginning of the stub to patch the call to go there > 2.) to find the load to patch the IC. Got it. > > Just have a look at CompiledStaticCall::set_to_interpreted(), > the variable 'stub' is used twice. Sorry for being so persistent on this :-) What is the reason you have to load the constant from the constant table? On other architectures we materialize the constant. -- Chris > > Best regards, > Goetz. > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Donnerstag, 29. November 2012 01:35 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] > > > On Nov 27, 2012, at 4:24 AM, "Lindenmaier, Goetz" wrote: > >> Hi Chris, >> >>> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub? >> Shared code (class CompiledStaticCall) wants to patch the inline cache >> in the stub which is emitted in platform code. >> So the platform code should specify how the shared code can find the inline cache >> in the stub, which it does through the constant I introduced. >> >>> Do you need two relocations? I'm confused. >> No, three ;) >> The relocation you mention is used to find the stub given the call. >> The other relocations are needed to find the inline cache / call target >> once the stub is found (see CompiledStaticCall::set_to_interpreted()). >> It's just the same on x86_64: >> >> // static stub relocation stores the instruction address of the call >> __ relocate(static_stub_Relocation::spec(mark), RELOC_IMM64); >> // static stub relocation also tags the methodOop in the code-stream. >> __ movoop(rbx, (jobject) NULL); // method is zapped till fixup time >> // This is recognized as unresolved by relocs/nativeinst/ic code >> __ jump(RuntimeAddress(__ pc())); >> >> On PPC, we have to load the base of the constant table after generating the >> static_stub_relocation and before emitting the ppc equivalent for moveoop(). This offset is >> exactly what we store in the CompiledStaticCall::comp_to_int_load_offset constant. > > Why can't you point the relocation to the method load instruction? It doesn't seem right to do that in shared code. > > -- Chris > >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >> Sent: Dienstag, 27. November 2012 01:53 >> To: Lindenmaier, Goetz >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] >> >> >> On Nov 22, 2012, at 8:51 AM, "Lindenmaier, Goetz" wrote: >> >>> Hi Chris, >>> >>> We put it into the ad file because it describes an offset into the stub that is >>> generated from the ad file by emit_java_to_interp(CodeBuffer& cbuf), >>> used by ir node CallStaticJavaDirect. Maybe I should not call it stub, but it's >>> generated into the stubs section of the code buffer. >>> If that stub generator is moved out of the ad file to shared compiler code, one should >>> move the field with it, but for the current implementation I think that's fine. >>> >>> Does C1 generate the same stub? Or is the CompiledStaticCall a C2 feature? >>> If so, one could protect the whole thing by #ifdef COMPILER2. >> >> Why do you need all these shared code changes when you have this in emit_java_to_interp_stub? >> >> // Create a static stub relocation which relates this stub >> // with the call instruction at insts_call_instruction_offset in the >> // instructions code-section. >> __ relocate(static_stub_Relocation::spec(__ code()->insts()->start() + insts_relocation_offset)); >> >> Do you need two relocations? I'm confused. >> >> -- Chris >> >>> >>> Thanks for all the bugids! >>> >>> Best regards, >>> Goetz. >>> >>> -----Original Message----- >>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>> Sent: Mittwoch, 21. November 2012 19:53 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-compiler-dev at openjdk.java.net >>> Subject: RFR (S): 8003853: specify offset of IC load in java_to_interp stub [Was: Re: RFR (S): Specify offset of IC load in java_to_interp stub.] >>> >>> >>> On Nov 21, 2012, at 12:15 AM, "Lindenmaier, Goetz" wrote: >>> >>>> Hi Chris, >>>> >>>> yes, there is no C1 on ppc. >>>> We do tiered compilation with a stripped C2. >>> >>> Right. But some other architecture (or in the future) might need this for C1 as well. We should find a better place for the value than the ad file. The obvious place would be compiledIC_.hpp but we don't have that file, yet. >>> >>> I filed: >>> >>> 8003853: specify offset of IC load in java_to_interp stub >>> >>> -- Chris >>> >>>> >>>> Best regards, >>>> Goetz >>>> >>>> -----Original Message----- >>>> From: Christian Thalinger [mailto:christian.thalinger at oracle.com] >>>> Sent: Dienstag, 20. November 2012 22:19 >>>> To: Lindenmaier, Goetz >>>> Cc: hotspot-compiler-dev at openjdk.java.net >>>> Subject: Re: RFR (S): Specify offset of IC load in java_to_interp stub. >>>> >>>> >>>> On Nov 20, 2012, at 3:08 AM, "Lindenmaier, Goetz" wrote: >>>> >>>>> Hi, >>>>> >>>>> The class CompiledStaticCall must know the location of the IC load in the java_to_interp stub >>>>> to update the IC with NativeMovConstReg. The current implementation assumes that >>>>> the load is always the first instruction in the stub. This is an artificial restriction. E.g., >>>>> it might be useful to load the constant pool address (MachConstantBase) before the >>>>> IC load (as we do on PPC). >>>>> >>>>> This change adds a constant specifying an offset from the beginning of the stub to >>>>> the IC load. The offset is platform specific and 0 on sparc and x86. >>>>> >>>>> You can find the change here: >>>>> http://cr.openjdk.java.net/~goetz/webrevs/webrev-IC_offset/ >>>> >>>> That should be fixed indeed. >>>> >>>> +#ifndef COMPILER2 >>>> +const int CompiledStaticCall::comp_to_int_load_offset = 0; >>>> >>>> There is no C1 for PPC (sorry, I didn't check)? >>>> >>>> -- Chris >>>> >>>>> >>>>> or in our ppc port: >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c6f9c897ea33 >>>>> >>>>> Thank you and best regards, >>>>> Goetz >>>>> >>>>> >>>>> >>>> >>> >> > From azeem.jiva at oracle.com Thu Nov 29 14:36:57 2012 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Thu, 29 Nov 2012 16:36:57 -0600 Subject: Hotspot not building on Solaris SPARC Message-ID: <50B7E389.30207@oracle.com> I'm trying to build HotSpot on Solaris SPARC, and see the following error from a fresh pull from the trunk: "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp", line 3469: Error: Could not find a match for Assembler::swap(Address, RegisterImpl*) needed in LIR_Assembler::atomic_op(LIR_Code, LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*). "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp", line 3476: Error: Could not find a match for Assembler::swap(Address, RegisterImpl*) needed in LIR_Assembler::atomic_op(LIR_Code, LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*). 2 Error(s) detected. gmake[2]: *** [c1_LIRAssembler_sparc.o] Error 2 gmake[2]: *** Waiting for unfinished jobs.... "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/sparc.ad", line 7349: Error: Could not find a match for Assembler::swap(Address, RegisterImpl*) needed in xchgINode::emit(CodeBuffer&, PhaseRegAlloc*) const. "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/sparc.ad", line 7371: Error: Could not find a match for Assembler::swap(Address, RegisterImpl*) needed in xchgNNode::emit(CodeBuffer&, PhaseRegAlloc*) const. 2 Error(s) detected. gmake[2]: *** [ad_sparc.o] Error 2 Ideas? -- Azeem Jiva @javawithjiva From azeem.jiva at oracle.com Thu Nov 29 14:59:30 2012 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Thu, 29 Nov 2012 16:59:30 -0600 Subject: Hotspot not building on Solaris SPARC In-Reply-To: <50B7E389.30207@oracle.com> References: <50B7E389.30207@oracle.com> Message-ID: <50B7E8D2.6080800@oracle.com> Sorry to be more clear, I see that swap() takes both an Address and Register and that offset has a default of zero if not provided (which is true in this case). I'm not sure why this is happening though. I'm hesitant to add a swap that takes just an Address and Register since this is old code, and has compiled before :) On 11/29/2012 04:36 PM, Azeem Jiva wrote: > I'm trying to build HotSpot on Solaris SPARC, and see the following > error from a fresh pull from the trunk: > > "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp", > line 3469: Error: Could not find a match for Assembler::swap(Address, > RegisterImpl*) needed in LIR_Assembler::atomic_op(LIR_Code, > LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*). > "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp", > line 3476: Error: Could not find a match for Assembler::swap(Address, > RegisterImpl*) needed in LIR_Assembler::atomic_op(LIR_Code, > LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*). > 2 Error(s) detected. > gmake[2]: *** [c1_LIRAssembler_sparc.o] Error 2 > gmake[2]: *** Waiting for unfinished jobs.... > "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/sparc.ad", line 7349: > Error: Could not find a match for Assembler::swap(Address, > RegisterImpl*) needed in xchgINode::emit(CodeBuffer&, PhaseRegAlloc*) > const. > "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/sparc.ad", line 7371: > Error: Could not find a match for Assembler::swap(Address, > RegisterImpl*) needed in xchgNNode::emit(CodeBuffer&, PhaseRegAlloc*) > const. > 2 Error(s) detected. > gmake[2]: *** [ad_sparc.o] Error 2 > > Ideas? > -- Azeem Jiva @javawithjiva From krystal.mo at oracle.com Thu Nov 29 15:20:44 2012 From: krystal.mo at oracle.com (Krystal Mo) Date: Fri, 30 Nov 2012 07:20:44 +0800 Subject: Hotspot not building on Solaris SPARC In-Reply-To: <50B7E8D2.6080800@oracle.com> References: <50B7E389.30207@oracle.com> <50B7E8D2.6080800@oracle.com> Message-ID: <50B7EDCC.1060607@oracle.com> Hi Azeem, Did you add a new overload of swap() somewhere in MacroAssembler or in C1_MacroAssembler? If so, you'll need to add a "using Assembler::swap;" declaration along with the declaration of your new overload, otherwise the inherited ones will be hidden. HTH, Kris On 11/30/2012 06:59 AM, Azeem Jiva wrote: > Sorry to be more clear, I see that swap() takes both an Address and > Register and that offset has a default of zero if not provided (which > is true in this case). I'm not sure why this is happening though. > I'm hesitant to add a swap that takes just an Address and Register > since this is old code, and has compiled before :) > > > On 11/29/2012 04:36 PM, Azeem Jiva wrote: >> I'm trying to build HotSpot on Solaris SPARC, and see the following >> error from a fresh pull from the trunk: >> >> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp", >> line 3469: Error: Could not find a match for Assembler::swap(Address, >> RegisterImpl*) needed in LIR_Assembler::atomic_op(LIR_Code, >> LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*). >> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp", >> line 3476: Error: Could not find a match for Assembler::swap(Address, >> RegisterImpl*) needed in LIR_Assembler::atomic_op(LIR_Code, >> LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*). >> 2 Error(s) detected. >> gmake[2]: *** [c1_LIRAssembler_sparc.o] Error 2 >> gmake[2]: *** Waiting for unfinished jobs.... >> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/sparc.ad", line 7349: >> Error: Could not find a match for Assembler::swap(Address, >> RegisterImpl*) needed in xchgINode::emit(CodeBuffer&, PhaseRegAlloc*) >> const. >> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/sparc.ad", line 7371: >> Error: Could not find a match for Assembler::swap(Address, >> RegisterImpl*) needed in xchgNNode::emit(CodeBuffer&, PhaseRegAlloc*) >> const. >> 2 Error(s) detected. >> gmake[2]: *** [ad_sparc.o] Error 2 >> >> Ideas? >> > From azeem.jiva at oracle.com Thu Nov 29 15:21:30 2012 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Thu, 29 Nov 2012 17:21:30 -0600 Subject: Hotspot not building on Solaris SPARC In-Reply-To: <50B7EDCC.1060607@oracle.com> References: <50B7E389.30207@oracle.com> <50B7E8D2.6080800@oracle.com> <50B7EDCC.1060607@oracle.com> Message-ID: <50B7EDFA.3020007@oracle.com> Kris, Nope this is freshly pulled code from the HS trunk. On 11/29/2012 05:20 PM, Krystal Mo wrote: > Hi Azeem, > > Did you add a new overload of swap() somewhere in MacroAssembler or in > C1_MacroAssembler? > If so, you'll need to add a "using Assembler::swap;" declaration along > with the declaration of your new overload, otherwise the inherited > ones will be hidden. > > HTH, > Kris > > On 11/30/2012 06:59 AM, Azeem Jiva wrote: >> Sorry to be more clear, I see that swap() takes both an Address and >> Register and that offset has a default of zero if not provided (which >> is true in this case). I'm not sure why this is happening though. >> I'm hesitant to add a swap that takes just an Address and Register >> since this is old code, and has compiled before :) >> >> >> On 11/29/2012 04:36 PM, Azeem Jiva wrote: >>> I'm trying to build HotSpot on Solaris SPARC, and see the following >>> error from a fresh pull from the trunk: >>> >>> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp", >>> line 3469: Error: Could not find a match for >>> Assembler::swap(Address, RegisterImpl*) needed in >>> LIR_Assembler::atomic_op(LIR_Code, LIR_OprDesc*, LIR_OprDesc*, >>> LIR_OprDesc*, LIR_OprDesc*). >>> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp", >>> line 3476: Error: Could not find a match for >>> Assembler::swap(Address, RegisterImpl*) needed in >>> LIR_Assembler::atomic_op(LIR_Code, LIR_OprDesc*, LIR_OprDesc*, >>> LIR_OprDesc*, LIR_OprDesc*). >>> 2 Error(s) detected. >>> gmake[2]: *** [c1_LIRAssembler_sparc.o] Error 2 >>> gmake[2]: *** Waiting for unfinished jobs.... >>> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/sparc.ad", line 7349: >>> Error: Could not find a match for Assembler::swap(Address, >>> RegisterImpl*) needed in xchgINode::emit(CodeBuffer&, >>> PhaseRegAlloc*) const. >>> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/sparc.ad", line 7371: >>> Error: Could not find a match for Assembler::swap(Address, >>> RegisterImpl*) needed in xchgNNode::emit(CodeBuffer&, >>> PhaseRegAlloc*) const. >>> 2 Error(s) detected. >>> gmake[2]: *** [ad_sparc.o] Error 2 >>> >>> Ideas? >>> >> > -- Azeem Jiva @javawithjiva From azeem.jiva at oracle.com Thu Nov 29 15:25:36 2012 From: azeem.jiva at oracle.com (Azeem Jiva) Date: Thu, 29 Nov 2012 17:25:36 -0600 Subject: Hotspot not building on Solaris SPARC In-Reply-To: <50B7EDFA.3020007@oracle.com> References: <50B7E389.30207@oracle.com> <50B7E8D2.6080800@oracle.com> <50B7EDCC.1060607@oracle.com> <50B7EDFA.3020007@oracle.com> Message-ID: <50B7EEF0.80107@oracle.com> Ahh I figured it out, I was using SolarisStudio12.3, when I switch back to the supported SunStudio12.1 compiler everything works great. On 11/29/2012 05:21 PM, Azeem Jiva wrote: > Kris, > Nope this is freshly pulled code from the HS trunk. > > On 11/29/2012 05:20 PM, Krystal Mo wrote: >> Hi Azeem, >> >> Did you add a new overload of swap() somewhere in MacroAssembler or >> in C1_MacroAssembler? >> If so, you'll need to add a "using Assembler::swap;" declaration >> along with the declaration of your new overload, otherwise the >> inherited ones will be hidden. >> >> HTH, >> Kris >> >> On 11/30/2012 06:59 AM, Azeem Jiva wrote: >>> Sorry to be more clear, I see that swap() takes both an Address and >>> Register and that offset has a default of zero if not provided >>> (which is true in this case). I'm not sure why this is happening >>> though. I'm hesitant to add a swap that takes just an Address and >>> Register since this is old code, and has compiled before :) >>> >>> >>> On 11/29/2012 04:36 PM, Azeem Jiva wrote: >>>> I'm trying to build HotSpot on Solaris SPARC, and see the following >>>> error from a fresh pull from the trunk: >>>> >>>> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp", >>>> line 3469: Error: Could not find a match for >>>> Assembler::swap(Address, RegisterImpl*) needed in >>>> LIR_Assembler::atomic_op(LIR_Code, LIR_OprDesc*, LIR_OprDesc*, >>>> LIR_OprDesc*, LIR_OprDesc*). >>>> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp", >>>> line 3476: Error: Could not find a match for >>>> Assembler::swap(Address, RegisterImpl*) needed in >>>> LIR_Assembler::atomic_op(LIR_Code, LIR_OprDesc*, LIR_OprDesc*, >>>> LIR_OprDesc*, LIR_OprDesc*). >>>> 2 Error(s) detected. >>>> gmake[2]: *** [c1_LIRAssembler_sparc.o] Error 2 >>>> gmake[2]: *** Waiting for unfinished jobs.... >>>> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/sparc.ad", line 7349: >>>> Error: Could not find a match for Assembler::swap(Address, >>>> RegisterImpl*) needed in xchgINode::emit(CodeBuffer&, >>>> PhaseRegAlloc*) const. >>>> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/sparc.ad", line 7371: >>>> Error: Could not find a match for Assembler::swap(Address, >>>> RegisterImpl*) needed in xchgNNode::emit(CodeBuffer&, >>>> PhaseRegAlloc*) const. >>>> 2 Error(s) detected. >>>> gmake[2]: *** [ad_sparc.o] Error 2 >>>> >>>> Ideas? >>>> >>> >> > -- Azeem Jiva @javawithjiva From christian.thalinger at oracle.com Thu Nov 29 16:22:54 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 29 Nov 2012 16:22:54 -0800 Subject: Hotspot not building on Solaris SPARC In-Reply-To: <50B7EEF0.80107@oracle.com> References: <50B7E389.30207@oracle.com> <50B7E8D2.6080800@oracle.com> <50B7EDCC.1060607@oracle.com> <50B7EDFA.3020007@oracle.com> <50B7EEF0.80107@oracle.com> Message-ID: On Nov 29, 2012, at 3:25 PM, Azeem Jiva wrote: > Ahh I figured it out, I was using SolarisStudio12.3, when I switch back to the supported SunStudio12.1 compiler everything works great. Doh. > > > On 11/29/2012 05:21 PM, Azeem Jiva wrote: >> Kris, >> Nope this is freshly pulled code from the HS trunk. >> >> On 11/29/2012 05:20 PM, Krystal Mo wrote: >>> Hi Azeem, >>> >>> Did you add a new overload of swap() somewhere in MacroAssembler or in C1_MacroAssembler? >>> If so, you'll need to add a "using Assembler::swap;" declaration along with the declaration of your new overload, otherwise the inherited ones will be hidden. >>> >>> HTH, >>> Kris >>> >>> On 11/30/2012 06:59 AM, Azeem Jiva wrote: >>>> Sorry to be more clear, I see that swap() takes both an Address and Register and that offset has a default of zero if not provided (which is true in this case). I'm not sure why this is happening though. I'm hesitant to add a swap that takes just an Address and Register since this is old code, and has compiled before :) >>>> >>>> >>>> On 11/29/2012 04:36 PM, Azeem Jiva wrote: >>>>> I'm trying to build HotSpot on Solaris SPARC, and see the following error from a fresh pull from the trunk: >>>>> >>>>> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp", line 3469: Error: Could not find a match for Assembler::swap(Address, RegisterImpl*) needed in LIR_Assembler::atomic_op(LIR_Code, LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*). >>>>> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp", line 3476: Error: Could not find a match for Assembler::swap(Address, RegisterImpl*) needed in LIR_Assembler::atomic_op(LIR_Code, LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*, LIR_OprDesc*). >>>>> 2 Error(s) detected. >>>>> gmake[2]: *** [c1_LIRAssembler_sparc.o] Error 2 >>>>> gmake[2]: *** Waiting for unfinished jobs.... >>>>> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/sparc.ad", line 7349: Error: Could not find a match for Assembler::swap(Address, RegisterImpl*) needed in xchgINode::emit(CodeBuffer&, PhaseRegAlloc*) const. >>>>> "/net/pae-t5two-04/root/hsx/src/cpu/sparc/vm/sparc.ad", line 7371: Error: Could not find a match for Assembler::swap(Address, RegisterImpl*) needed in xchgNNode::emit(CodeBuffer&, PhaseRegAlloc*) const. >>>>> 2 Error(s) detected. >>>>> gmake[2]: *** [ad_sparc.o] Error 2 >>>>> >>>>> Ideas? >>>>> >>>> >>> >> > > -- > Azeem Jiva > @javawithjiva > From john.r.rose at oracle.com Thu Nov 29 17:45:05 2012 From: john.r.rose at oracle.com (John Rose) Date: Thu, 29 Nov 2012 17:45:05 -0800 Subject: Request for reviews (S): 8001885 : JSR 292 classes should use jdk.internal.org.objectweb.asm In-Reply-To: <4DAC718F-42DF-427A-BA40-081971790175@oracle.com> References: <4DAC718F-42DF-427A-BA40-081971790175@oracle.com> Message-ID: On Nov 29, 2012, at 12:48 PM, David Chase wrote: > http://cr.openjdk.java.net/~drchase/8001885/webrev.00/ I'm relieved to see no code changes. The ASM version we are using is now 4, which has significant incompatible changes from 3. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121129/3c98cd4e/attachment.html From john.coomes at oracle.com Thu Nov 29 20:48:15 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Nov 2012 04:48:15 +0000 Subject: hg: hsx/hotspot-comp/jaxws: Added tag jdk8-b66 for changeset 3eb7f11cb4e0 Message-ID: <20121130044819.62A3F47C07@hg.openjdk.java.net> Changeset: eb06aa51dfc2 Author: katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxws/rev/eb06aa51dfc2 Added tag jdk8-b66 for changeset 3eb7f11cb4e0 ! .hgtags From john.coomes at oracle.com Thu Nov 29 20:47:54 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Nov 2012 04:47:54 +0000 Subject: hg: hsx/hotspot-comp: 12 new changesets Message-ID: <20121130044754.EC3AF47C04@hg.openjdk.java.net> Changeset: a2df4ee40ecb Author: tbell Date: 2012-11-14 10:05 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/a2df4ee40ecb 8002026: build-infra: deploy repository building Summary: Change the compare script to handle deploy build artifacts. Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl Changeset: c81c4a5d8b50 Author: tbell Date: 2012-11-14 10:13 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/c81c4a5d8b50 8001875: build-infra: We must be able to force static linking of stdc++ Summary: Ensure that we build with static linking when requested, or do not build at all Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: 582c696033f5 Author: tbell Date: 2012-11-14 10:16 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/582c696033f5 8001941: build-infra: --disable-precompiled-headers does not seem to work Summary: With this fix the flag will do what it advertises Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/build-performance.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in Changeset: f59a07f85125 Author: tbell Date: 2012-11-14 10:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/f59a07f85125 8003317: build-infra: Configure fails when current dir is part of a symlink Summary: Call macro for removing symbolic links on a copy of the CURDIR variable before comparing Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: e69396d6d3e8 Author: tbell Date: 2012-11-14 10:20 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/e69396d6d3e8 8003327: build-infra: "/bin/sh: : cannot execute" on solaris Summary: Fix quoting inside cut command used in the pipeline Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! common/makefiles/MakeHelpers.gmk Changeset: 06f146c05f49 Author: tbell Date: 2012-11-15 00:54 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/06f146c05f49 Merge Changeset: ecf751a69f6a Author: tbell Date: 2012-11-19 14:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/ecf751a69f6a 8003300: build-infra: fails on solaris when objcopy is not found Summary: Only call BASIC_FIXUP_EXECUTABLE() if objcopy was found. Reviewed-by: tbell Contributed-by: erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: f8b0bacd4de5 Author: erikj Date: 2012-11-28 13:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/f8b0bacd4de5 8001460: build-infra: Linker warnings on macosx Summary: Only linking against jvm variant specific dirs if they are expected to exist. Reviewed-by: ohair ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: 6ff2e1280dc3 Author: erikj Date: 2012-11-28 13:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/6ff2e1280dc3 8003844: build-infra: docs target isn't working properly Summary: Fixed docs and docs-clean target. Added compare support for docs. Reviewed-by: ohair, jjg, ohrstrom ! common/bin/compare.sh ! common/makefiles/Main.gmk ! common/makefiles/javadoc/Javadoc.gmk Changeset: 7d7dd520ebfd Author: erikj Date: 2012-11-28 13:48 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/7d7dd520ebfd 8003528: build-infra: Diffs in libjava and hotspot libs on solaris. Summary: Linking against server jvm first if available. Adding filters and exceptions for hotspot lib compare on solaris. Reviewed-by: ohair, ohrstrom ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 ! common/bin/compare_exceptions.sh.incl Changeset: 13bb8c326e7b Author: katleman Date: 2012-11-28 14:03 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/13bb8c326e7b Merge Changeset: 16292f54195c Author: katleman Date: 2012-11-29 11:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/rev/16292f54195c Added tag jdk8-b66 for changeset 13bb8c326e7b ! .hgtags From john.coomes at oracle.com Thu Nov 29 20:47:59 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Nov 2012 04:47:59 +0000 Subject: hg: hsx/hotspot-comp/corba: Added tag jdk8-b66 for changeset 65771ad1ca55 Message-ID: <20121130044801.27C1547C05@hg.openjdk.java.net> Changeset: 394515ad2a55 Author: katleman Date: 2012-11-29 11:29 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/corba/rev/394515ad2a55 Added tag jdk8-b66 for changeset 65771ad1ca55 ! .hgtags From john.coomes at oracle.com Thu Nov 29 20:48:05 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Nov 2012 04:48:05 +0000 Subject: hg: hsx/hotspot-comp/jaxp: Added tag jdk8-b66 for changeset e6af1ad464e3 Message-ID: <20121130044810.3E2CA47C06@hg.openjdk.java.net> Changeset: 83df3493ca3c Author: katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jaxp/rev/83df3493ca3c Added tag jdk8-b66 for changeset e6af1ad464e3 ! .hgtags From john.coomes at oracle.com Thu Nov 29 20:48:46 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Nov 2012 04:48:46 +0000 Subject: hg: hsx/hotspot-comp/jdk: 35 new changesets Message-ID: <20121130045549.38E3247C08@hg.openjdk.java.net> Changeset: 03d22c98b30a Author: ceisserer Date: 2012-11-13 16:12 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/03d22c98b30a 7105461: Large JTables are not rendered correctly with Xrender pipeline Reviewed-by: flar, prr ! src/solaris/classes/sun/java2d/xr/XRRenderer.java ! src/solaris/classes/sun/java2d/xr/XRUtils.java Changeset: ed977ca9a969 Author: lana Date: 2012-11-20 11:46 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ed977ca9a969 Merge Changeset: 11ba8795bbe9 Author: kshefov Date: 2012-11-14 11:37 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/11ba8795bbe9 7147408: [macosx] Add autodelay to fix a regression test Reviewed-by: serb, alexsch + test/javax/swing/text/StyledEditorKit/4506788/bug4506788.html + test/javax/swing/text/StyledEditorKit/4506788/bug4506788.java Changeset: f32a0aee7bb9 Author: alitvinov Date: 2012-11-14 18:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f32a0aee7bb9 6789984: JPasswordField can not receive keyboard input Reviewed-by: naoto, anthony ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/awt/im/InputMethodAdapter.java ! src/solaris/classes/sun/awt/X11InputMethod.java Changeset: 0269459afe2a Author: malenkov Date: 2012-11-20 18:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0269459afe2a 8003333: Regression: java/beans/EventHandler/Test6277266.java fails with ACE Reviewed-by: art ! test/java/beans/EventHandler/Test6277266.java Changeset: ea368459cca5 Author: lana Date: 2012-11-20 11:47 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ea368459cca5 Merge Changeset: c3e7ceb22d37 Author: alanb Date: 2012-11-11 10:05 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/c3e7ceb22d37 8003253: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java hang intermittently [win] Reviewed-by: chegar ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java Changeset: 5d3f8f9e6c58 Author: okutsu Date: 2012-11-12 11:12 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/5d3f8f9e6c58 8000986: Split java.util.spi.CalendarDataProvider into week parameters and field names portions Reviewed-by: naoto ! make/java/java/FILES_java.gmk ! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/spi/CalendarDataProvider.java + src/share/classes/java/util/spi/CalendarNameProvider.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java + src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! test/java/util/PluggableLocale/CalendarDataProviderTest.java ! test/java/util/PluggableLocale/CalendarDataProviderTest.sh + test/java/util/PluggableLocale/CalendarNameProviderTest.java + test/java/util/PluggableLocale/CalendarNameProviderTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/barprovider.jar ! test/java/util/PluggableLocale/fooprovider.jar ! test/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java + test/java/util/PluggableLocale/providersrc/CalendarNameProviderImpl.java ! test/java/util/PluggableLocale/providersrc/Makefile + test/java/util/PluggableLocale/providersrc/java.util.spi.CalendarNameProvider Changeset: be1fb42ef696 Author: mduigou Date: 2012-11-13 20:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/be1fb42ef696 7088913: Add compatible static hashCode(primitive) to primitive wrapper classes Summary: Adds static utility methods to each primitive wrapper class to allow calculation of a hashCode value from an unboxed primitive. Reviewed-by: darcy, smarks, dholmes ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! test/java/lang/HashCode.java Changeset: 83765e82cacb Author: zhouyx Date: 2012-11-14 13:26 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/83765e82cacb 7201156: jar tool fails to convert file separation characters for list and extract Reviewed-by: alanb, chegar, sherman ! src/share/classes/sun/tools/jar/Main.java + test/tools/jar/JarBackSlash.java Changeset: 0f54a98f9bc9 Author: alanb Date: 2012-11-14 12:56 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0f54a98f9bc9 8003285: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java fails again [macosx] Reviewed-by: chegar ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java Changeset: 369709a13823 Author: jjg Date: 2012-11-14 07:08 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/369709a13823 8000404: rename javax.tools.GenerateNativeHeader to java.lang.annotation.Native Reviewed-by: alanb + src/share/classes/java/lang/annotation/Native.java Changeset: e24123de581c Author: mduigou Date: 2012-11-13 20:02 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/e24123de581c 7088952: Add size in bytes constant "BYTES" to primitive type wrapper types Summary: Adds a constant BYTES to each of the primitive wrapper classes (Byte, Character, Double, Float, Integer, Long, Short) with the calculation Primitive.SIZE / Byte.SIZE already made. Reviewed-by: dholmes ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java Changeset: f4de6a38f794 Author: lana Date: 2012-11-14 16:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f4de6a38f794 Merge Changeset: ac22a52a732c Author: jgish Date: 2012-11-15 13:46 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ac22a52a732c 6244047: impossible to specify directories to logging FileHandler unless they exist Reviewed-by: alanb ! src/share/classes/java/util/logging/FileHandler.java + test/java/util/logging/CheckLockLocationTest.java Changeset: 51c695958712 Author: weijun Date: 2012-11-16 10:34 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/51c695958712 8003263: redundant cast build failure after 8003120 Reviewed-by: alanb ! src/share/classes/com/sun/naming/internal/ResourceManager.java Changeset: 64a42798ea5e Author: naoto Date: 2012-11-15 20:17 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/64a42798ea5e 7199750: Loading sequence of service provider is changed Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/barprovider.jar ! test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java Changeset: 0ee09f17361e Author: khazra Date: 2012-11-16 12:28 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/0ee09f17361e 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently Summary: Add java/util/prefs to exclusiveAccess.dirs in TEST.ROOT Reviewed-by: alanb, mchung ! test/TEST.ROOT Changeset: 6f20caa6e1e9 Author: bchristi Date: 2012-11-16 17:01 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/6f20caa6e1e9 7178922: (props) re-visit how os.name is determined on Mac Reviewed-by: alanb, mchung, skovatch, serb ! src/solaris/native/java/lang/java_props_macosx.c Changeset: 25e5df117021 Author: xuelei Date: 2012-11-18 01:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/25e5df117021 8003587: Warning cleanup in package javax.net.ssl Summary: Removes unnecessary imports and adds missing Override annotations Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/javax/net/ssl/HandshakeCompletedEvent.java ! src/share/classes/javax/net/ssl/HostnameVerifier.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/KeyManagerFactory.java ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/net/ssl/SSLContextSpi.java ! src/share/classes/javax/net/ssl/SSLEngineResult.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLPermission.java ! src/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/share/classes/javax/net/ssl/SSLSession.java ! src/share/classes/javax/net/ssl/SSLSocket.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java ! src/share/classes/javax/net/ssl/TrustManagerFactory.java ! src/share/classes/javax/net/ssl/X509KeyManager.java Changeset: f740a9ac6eb6 Author: weijun Date: 2012-11-19 11:13 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/f740a9ac6eb6 8002344: Krb5LoginModule config class does not return proper KDC list from DNS Reviewed-by: weijun Contributed-by: Severin Gehwolf , Wang Weijun ! src/share/classes/sun/security/krb5/Config.java + test/sun/security/krb5/config/DNS.java + test/sun/security/krb5/config/NamingManager.java + test/sun/security/krb5/config/dns.sh Changeset: 3877706701b1 Author: alanb Date: 2012-11-19 13:17 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3877706701b1 8003607: More ProblemList.txt updates (11/2012) Reviewed-by: lancea ! test/ProblemList.txt ! test/TEST.ROOT Changeset: 2d08b404cd91 Author: jzavgren Date: 2012-11-20 09:26 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/2d08b404cd91 8000476: Memory Leaks and uninitialized memory access in PKCS11 and other native code Reviewed-by: dsamersoff, valeriep, chegar ! src/share/bin/wildcard.c ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/solaris/bin/java_md_solinux.c Changeset: 914cd9b482c8 Author: ksrini Date: 2012-11-19 19:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/914cd9b482c8 8001533: java launcher must launch javafx applications Reviewed-by: ksrini, mchung, kcr, alanb Contributed-by: david.dehaven at oracle.com ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! test/tools/launcher/TestHelper.java Changeset: b1c364c84d09 Author: ksrini Date: 2012-11-19 19:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/b1c364c84d09 8003660: (launcher) 8001533 regression tests Reviewed-by: ksrini, mchung, kcr, ddehaven Contributed-by: steve.sides at oracle.com + test/tools/launcher/FXLauncherTest.java Changeset: 107a7a52a3c0 Author: lana Date: 2012-11-20 11:49 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/107a7a52a3c0 Merge Changeset: ccff3b663797 Author: tbell Date: 2012-11-14 10:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ccff3b663797 8001906: build-infra: warning: [path] bad path element on Solaris Summary: Remove unnecesary -cp parameter from compile line Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/CompileDemos.gmk Changeset: 716efc201640 Author: tbell Date: 2012-11-15 00:55 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/716efc201640 Merge Changeset: 44e845bb5f76 Author: erikj Date: 2012-11-28 09:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/44e845bb5f76 8003960: build-infra: Jarsigner launcher has wrong classname Summary: Fixed package name in launcher Reviewed-by: alanb, ohair, ohrstrom ! makefiles/CompileLaunchers.gmk Changeset: ad5741112252 Author: erikj Date: 2012-11-28 13:20 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/ad5741112252 8001460: build-infra: Linker warnings on macosx Summary: Remove creation of empty i386 section from fdlibm Reviewed-by: ohair ! makefiles/CompileNativeLibraries.gmk Changeset: 7ecc80d2ff2e Author: erikj Date: 2012-11-28 13:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/7ecc80d2ff2e 8003477: build-infra: Remove explicit source file listings for libs when possible Reviewed-by: ohair, ohrstrom ! makefiles/CompileNativeLibraries.gmk Changeset: 51d2fd6d9850 Author: erikj Date: 2012-11-28 13:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/51d2fd6d9850 8003528: build-infra: Diffs in libjava and hotspot libs on solaris. Summary: Reorder libraries on link command line to match old build. Reviewed-by: ohair, ohrstrom ! makefiles/CompileNativeLibraries.gmk Changeset: 54516ed0f99f Author: erikj Date: 2012-11-28 14:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/54516ed0f99f 8003482: build-infra: Use correct manifest in security jars Reviewed-by: ohair, ohrstrom ! makefiles/CreateJars.gmk Changeset: 4d337fae2250 Author: katleman Date: 2012-11-28 14:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/4d337fae2250 Merge Changeset: df5619994dc3 Author: katleman Date: 2012-11-29 11:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/df5619994dc3 Added tag jdk8-b66 for changeset 4d337fae2250 ! .hgtags From john.coomes at oracle.com Thu Nov 29 20:58:07 2012 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Fri, 30 Nov 2012 04:58:07 +0000 Subject: hg: hsx/hotspot-comp/langtools: 22 new changesets Message-ID: <20121130045901.011A247C09@hg.openjdk.java.net> Changeset: e6b1abdc11ca Author: rfield Date: 2012-11-13 08:06 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/e6b1abdc11ca 8003306: Compiler crash: calculation of inner class access modifier Summary: Fix binary sense lost in transition to hasTag Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/InnerConstructor.java Changeset: 2901c7b5339e Author: jjg Date: 2012-11-13 15:09 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2901c7b5339e 8003299: Cleanup javac Log support for deferred diagnostics Reviewed-by: mcimadamore, jfranck ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java Changeset: f14c693a0e48 Author: jjg Date: 2012-11-14 10:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/f14c693a0e48 8003412: javac needs to understand java.lang.annotation.Native Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! test/tools/javac/nativeHeaders/NativeHeaderTest.java ! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java + test/tools/javac/nativeHeaders/javahComparison/TestClass4.java + test/tools/javac/nativeHeaders/javahComparison/TestClass5.java Changeset: b486794d160d Author: lana Date: 2012-11-14 16:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/b486794d160d Merge Changeset: 33abf479f202 Author: jjg Date: 2012-11-14 17:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/33abf479f202 7021614: extend com.sun.source API to support parsing javadoc comments Reviewed-by: ksrini, strarup ! make/build.xml + src/share/classes/com/sun/source/doctree/AttributeTree.java + src/share/classes/com/sun/source/doctree/AuthorTree.java + src/share/classes/com/sun/source/doctree/BlockTagTree.java + src/share/classes/com/sun/source/doctree/CommentTree.java + src/share/classes/com/sun/source/doctree/DeprecatedTree.java + src/share/classes/com/sun/source/doctree/DocCommentTree.java + src/share/classes/com/sun/source/doctree/DocRootTree.java + src/share/classes/com/sun/source/doctree/DocTree.java + src/share/classes/com/sun/source/doctree/DocTreeVisitor.java + src/share/classes/com/sun/source/doctree/EndElementTree.java + src/share/classes/com/sun/source/doctree/EntityTree.java + src/share/classes/com/sun/source/doctree/ErroneousTree.java + src/share/classes/com/sun/source/doctree/IdentifierTree.java + src/share/classes/com/sun/source/doctree/InheritDocTree.java + src/share/classes/com/sun/source/doctree/InlineTagTree.java + src/share/classes/com/sun/source/doctree/LinkTree.java + src/share/classes/com/sun/source/doctree/LiteralTree.java + src/share/classes/com/sun/source/doctree/ParamTree.java + src/share/classes/com/sun/source/doctree/ReferenceTree.java + src/share/classes/com/sun/source/doctree/ReturnTree.java + src/share/classes/com/sun/source/doctree/SeeTree.java + src/share/classes/com/sun/source/doctree/SerialDataTree.java + src/share/classes/com/sun/source/doctree/SerialFieldTree.java + src/share/classes/com/sun/source/doctree/SerialTree.java + src/share/classes/com/sun/source/doctree/SinceTree.java + src/share/classes/com/sun/source/doctree/StartElementTree.java + src/share/classes/com/sun/source/doctree/TextTree.java + src/share/classes/com/sun/source/doctree/ThrowsTree.java + src/share/classes/com/sun/source/doctree/UnknownBlockTagTree.java + src/share/classes/com/sun/source/doctree/UnknownInlineTagTree.java + src/share/classes/com/sun/source/doctree/ValueTree.java + src/share/classes/com/sun/source/doctree/VersionTree.java + src/share/classes/com/sun/source/doctree/package-info.java ! src/share/classes/com/sun/source/tree/Tree.java + src/share/classes/com/sun/source/util/DocTreeScanner.java + src/share/classes/com/sun/source/util/DocTrees.java + src/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java + src/share/classes/com/sun/tools/javac/parser/LazyDocCommentTable.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java - src/share/classes/com/sun/tools/javac/parser/SimpleDocCommentTable.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + src/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/share/classes/com/sun/tools/javac/tree/DocCommentTable.java + src/share/classes/com/sun/tools/javac/tree/DocPretty.java + src/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! test/tools/javac/diags/CheckExamples.java + test/tools/javac/diags/DocCommentProcessor.java ! test/tools/javac/diags/Example.java ! test/tools/javac/diags/RunExamples.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/BadEntity.java + test/tools/javac/diags/examples/BadGreaterThan.java + test/tools/javac/diags/examples/BadInlineTag.java + test/tools/javac/diags/examples/GreaterThanExpected.java + test/tools/javac/diags/examples/MalformedHTML.java + test/tools/javac/diags/examples/MissingSemicolon.java + test/tools/javac/diags/examples/NoTagName.java + test/tools/javac/diags/examples/RefBadParens.java + test/tools/javac/diags/examples/RefIdentifierExpected.java + test/tools/javac/diags/examples/RefSyntaxError.java + test/tools/javac/diags/examples/RefUnexpectedInput.java + test/tools/javac/diags/examples/UnexpectedContent.java + test/tools/javac/diags/examples/UnterminatedInlineTag.java + test/tools/javac/diags/examples/UnterminatedSignature.java + test/tools/javac/doctree/AttrTest.java + test/tools/javac/doctree/AuthorTest.java + test/tools/javac/doctree/BadTest.java + test/tools/javac/doctree/CodeTest.java + test/tools/javac/doctree/DeprecatedTest.java + test/tools/javac/doctree/DocCommentTester.java + test/tools/javac/doctree/DocRootTest.java + test/tools/javac/doctree/ElementTest.java + test/tools/javac/doctree/EntityTest.java + test/tools/javac/doctree/ExceptionTest.java + test/tools/javac/doctree/FirstSentenceTest.java + test/tools/javac/doctree/InheritDocTest.java + test/tools/javac/doctree/LinkPlainTest.java + test/tools/javac/doctree/LinkTest.java + test/tools/javac/doctree/LiteralTest.java + test/tools/javac/doctree/ParamTest.java + test/tools/javac/doctree/ReferenceTest.java + test/tools/javac/doctree/ReturnTest.java + test/tools/javac/doctree/SeeTest.java + test/tools/javac/doctree/SerialDataTest.java + test/tools/javac/doctree/SerialFieldTest.java + test/tools/javac/doctree/SerialTest.java + test/tools/javac/doctree/SimpleDocTreeVisitorTest.java + test/tools/javac/doctree/SinceTest.java + test/tools/javac/doctree/TagTest.java + test/tools/javac/doctree/ThrowableTest.java + test/tools/javac/doctree/ValueTest.java + test/tools/javac/doctree/VersionTest.java Changeset: bfec2a1cc869 Author: jjg Date: 2012-11-15 09:18 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/bfec2a1cc869 8000800: javadoc uses static non-final fields Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! test/com/sun/javadoc/MetaTag/MetaTag.java ! test/com/sun/javadoc/testHtmlDocument/TestHtmlDocument.java Changeset: 467f4f754368 Author: jjg Date: 2012-11-15 14:41 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/467f4f754368 8003257: refactor javadoc tool option handling Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/Start.java + src/share/classes/com/sun/tools/javadoc/ToolOption.java Changeset: 400a4e8accd3 Author: jjg Date: 2012-11-15 19:54 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/400a4e8accd3 8002079: update DocFile to use a JavaFileManager Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java Changeset: bdcef2ef52d2 Author: jjg Date: 2012-11-15 23:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/bdcef2ef52d2 6493690: javadoc should have a javax.tools.Tool service provider installed in tools.jar Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/Start.java + src/share/classes/com/sun/tools/javadoc/api/JavadocTaskImpl.java + src/share/classes/com/sun/tools/javadoc/api/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties + src/share/classes/javax/tools/DocumentationTool.java ! src/share/classes/javax/tools/JavaCompiler.java ! src/share/classes/javax/tools/ToolProvider.java ! test/tools/javadoc/CheckResourceKeys.java + test/tools/javadoc/api/basic/APITest.java + test/tools/javadoc/api/basic/DocletPathTest.java + test/tools/javadoc/api/basic/GetSourceVersionsTest.java + test/tools/javadoc/api/basic/GetTask_DiagListenerTest.java + test/tools/javadoc/api/basic/GetTask_DocletClassTest.java + test/tools/javadoc/api/basic/GetTask_FileManagerTest.java + test/tools/javadoc/api/basic/GetTask_FileObjectsTest.java + test/tools/javadoc/api/basic/GetTask_OptionsTest.java + test/tools/javadoc/api/basic/GetTask_WriterTest.java + test/tools/javadoc/api/basic/IsSupportedOptionTest.java + test/tools/javadoc/api/basic/JavadocTaskImplTest.java + test/tools/javadoc/api/basic/RunTest.java + test/tools/javadoc/api/basic/TagletPathTest.java + test/tools/javadoc/api/basic/Task_reuseTest.java + test/tools/javadoc/api/basic/pkg/C.java + test/tools/javadoc/api/basic/taglets/UnderlineTaglet.java Changeset: 843d3b191773 Author: jjh Date: 2012-11-16 18:27 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/843d3b191773 8003357: Add support for jtreg -concurrency to langtools/test/Makefile Reviewed-by: jjg ! test/Makefile Changeset: 01c9d4161882 Author: mcimadamore Date: 2012-11-17 19:01 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/01c9d4161882 8003280: Add lambda tests Summary: Turn on lambda expression, method reference and default method support Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Warner.java ! test/tools/javac/conditional/Conditional.java ! test/tools/javac/defaultMethods/ClassReaderTest/ClassReaderTest.java ! test/tools/javac/defaultMethods/Neg01.java ! test/tools/javac/defaultMethods/Neg02.java ! test/tools/javac/defaultMethods/Neg03.java ! test/tools/javac/defaultMethods/Neg04.java ! test/tools/javac/defaultMethods/Neg05.java ! test/tools/javac/defaultMethods/Neg06.java ! test/tools/javac/defaultMethods/Neg07.java ! test/tools/javac/defaultMethods/Neg08.java ! test/tools/javac/defaultMethods/Neg09.java ! test/tools/javac/defaultMethods/Neg10.java ! test/tools/javac/defaultMethods/Neg11.java ! test/tools/javac/defaultMethods/Neg12.java ! test/tools/javac/defaultMethods/Neg12.out ! test/tools/javac/defaultMethods/Neg13.java ! test/tools/javac/defaultMethods/Neg14.java ! test/tools/javac/defaultMethods/Neg15.java ! test/tools/javac/defaultMethods/Neg16.java ! test/tools/javac/defaultMethods/Pos01.java ! test/tools/javac/defaultMethods/Pos02.java ! test/tools/javac/defaultMethods/Pos04.java ! test/tools/javac/defaultMethods/Pos05.java ! test/tools/javac/defaultMethods/Pos06.java ! test/tools/javac/defaultMethods/Pos07.java ! test/tools/javac/defaultMethods/Pos08.java ! test/tools/javac/defaultMethods/Pos10.java ! test/tools/javac/defaultMethods/Pos11.java ! test/tools/javac/defaultMethods/Pos12.java ! test/tools/javac/defaultMethods/Pos13.java ! test/tools/javac/defaultMethods/Pos14.java ! test/tools/javac/defaultMethods/Pos15.java ! test/tools/javac/defaultMethods/Pos16.java ! test/tools/javac/defaultMethods/TestDefaultBody.java ! test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java ! test/tools/javac/defaultMethods/fd/FDTest.java ! test/tools/javac/defaultMethods/separate/Separate.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java - test/tools/javac/diags/examples/CantAccessArgTypeInFunctionalDesc.java ! test/tools/javac/diags/examples/CantAccessInnerClsConstr.java - test/tools/javac/diags/examples/CantAccessReturnTypeInFunctionalDesc.java - test/tools/javac/diags/examples/CantAccessThrownTypesInFunctionalDesc.java ! test/tools/javac/diags/examples/CantApplySymbolFragment.java ! test/tools/javac/diags/examples/CantApplySymbolsFragment.java ! test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java ! test/tools/javac/diags/examples/CantResolveLocationArgsFragment.java ! test/tools/javac/diags/examples/CantResolveLocationArgsParamsFragment.java - test/tools/javac/diags/examples/CantReturnValueForVoid.java + test/tools/javac/diags/examples/ConditionalTargetCantBeVoid.java ! test/tools/javac/diags/examples/CyclicInference.java ! test/tools/javac/diags/examples/DefaultOverridesObjectMember.java ! test/tools/javac/diags/examples/IncompatibleAbstracts.java ! test/tools/javac/diags/examples/IncompatibleArgTypesInLambda.java ! test/tools/javac/diags/examples/IncompatibleDescsInFunctionalIntf.java ! test/tools/javac/diags/examples/IncompatibleRetTypeInLambda.java ! test/tools/javac/diags/examples/IncompatibleRetTypeInMref.java ! test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java ! test/tools/javac/diags/examples/IncompatibleThrownTypesInMref.java ! test/tools/javac/diags/examples/IncompatibleTypesInConditional.java ! test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java ! test/tools/javac/diags/examples/LocalVarNeedsFinal.java ! test/tools/javac/diags/examples/MissingReturnValue.java ! test/tools/javac/diags/examples/MissingReturnValueFragment.java ! test/tools/javac/diags/examples/NoAbstracts.java ! test/tools/javac/diags/examples/NoSuitableFunctionalIntfInst.java ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java ! test/tools/javac/diags/examples/NotAFunctionalIntf.java ! test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessFragment.java ! test/tools/javac/diags/examples/OverriddenDefault.java ! test/tools/javac/diags/examples/PotentialLambdaFound.java ! test/tools/javac/diags/examples/RedundantSupertype.java ! test/tools/javac/diags/examples/RefAmbiguousFragment.java ! test/tools/javac/diags/examples/TypesIncompatibleAbstractDefault.java ! test/tools/javac/diags/examples/TypesIncompatibleUnrelatedDefaults.java ! test/tools/javac/diags/examples/UnexpectedLambda.java ! test/tools/javac/diags/examples/UnexpectedMref.java + test/tools/javac/diags/examples/UnexpectedReturnValue.java ! test/tools/javac/generics/7022054/T7022054pos1.java + test/tools/javac/generics/7022054/T7022054pos1.out ! test/tools/javac/generics/7022054/T7022054pos2.java + test/tools/javac/generics/7022054/T7022054pos2.out + test/tools/javac/lambda/BadAccess.java + test/tools/javac/lambda/BadAccess.out + test/tools/javac/lambda/BadAccess02.java + test/tools/javac/lambda/BadAccess02.out + test/tools/javac/lambda/BadAccess03.java + test/tools/javac/lambda/BadAccess03.out + test/tools/javac/lambda/BadBreakContinue.java + test/tools/javac/lambda/BadBreakContinue.out + test/tools/javac/lambda/BadConv03.java + test/tools/javac/lambda/BadConv03.out + test/tools/javac/lambda/BadConv04.java + test/tools/javac/lambda/BadConv04.out + test/tools/javac/lambda/BadExpressionLambda.java + test/tools/javac/lambda/BadExpressionLambda.out + test/tools/javac/lambda/BadLambdaExpr.java + test/tools/javac/lambda/BadLambdaPos.java + test/tools/javac/lambda/BadLambdaPos.out + test/tools/javac/lambda/BadMethodCall.java + test/tools/javac/lambda/BadMethodCall.out + test/tools/javac/lambda/BadRecovery.java + test/tools/javac/lambda/BadRecovery.out + test/tools/javac/lambda/BadReturn.java + test/tools/javac/lambda/BadReturn.out + test/tools/javac/lambda/BadStatementInLambda.java + test/tools/javac/lambda/BadStatementInLambda.out + test/tools/javac/lambda/BadStatementInLambda02.java + test/tools/javac/lambda/BadStatementInLambda02.out + test/tools/javac/lambda/BadTargetType.java + test/tools/javac/lambda/BadTargetType.out + test/tools/javac/lambda/Conditional01.java + test/tools/javac/lambda/Conditional02.java + test/tools/javac/lambda/Conditional03.java + test/tools/javac/lambda/Conformance01.java + test/tools/javac/lambda/Defender01.java + test/tools/javac/lambda/DisjunctiveTypeTest.java + test/tools/javac/lambda/EffectivelyFinal01.java + test/tools/javac/lambda/EffectivelyFinal01.out ! test/tools/javac/lambda/EffectivelyFinalTest.java ! test/tools/javac/lambda/EffectivelyFinalTest01.out ! test/tools/javac/lambda/EffectivelyFinalTest02.out + test/tools/javac/lambda/ErroneousArg.java + test/tools/javac/lambda/ErroneousArg.out + test/tools/javac/lambda/ErroneousLambdaExpr.java ! test/tools/javac/lambda/InnerConstructor.java + test/tools/javac/lambda/LambdaCapture01.java + test/tools/javac/lambda/LambdaCapture02.java + test/tools/javac/lambda/LambdaCapture03.java + test/tools/javac/lambda/LambdaCapture04.java + test/tools/javac/lambda/LambdaCapture05.java + test/tools/javac/lambda/LambdaCapture06.java + test/tools/javac/lambda/LambdaConv01.java + test/tools/javac/lambda/LambdaConv03.java + test/tools/javac/lambda/LambdaConv05.java + test/tools/javac/lambda/LambdaConv06.java + test/tools/javac/lambda/LambdaConv08.java + test/tools/javac/lambda/LambdaConv09.java + test/tools/javac/lambda/LambdaConv09.out + test/tools/javac/lambda/LambdaConv10.java + test/tools/javac/lambda/LambdaConv10.out + test/tools/javac/lambda/LambdaConv11.java + test/tools/javac/lambda/LambdaConv12.java + test/tools/javac/lambda/LambdaConv13.java + test/tools/javac/lambda/LambdaConv16.java + test/tools/javac/lambda/LambdaConv17.java + test/tools/javac/lambda/LambdaConv18.java + test/tools/javac/lambda/LambdaConv18.out + test/tools/javac/lambda/LambdaConv19.java + test/tools/javac/lambda/LambdaConv20.java + test/tools/javac/lambda/LambdaConv21.java + test/tools/javac/lambda/LambdaConv21.out + test/tools/javac/lambda/LambdaConv22.java + test/tools/javac/lambda/LambdaConv23.java + test/tools/javac/lambda/LambdaConv24.java + test/tools/javac/lambda/LambdaConversionTest.java + test/tools/javac/lambda/LambdaEffectivelyFinalTest.java + test/tools/javac/lambda/LambdaEffectivelyFinalTest.out + test/tools/javac/lambda/LambdaExpr01.java + test/tools/javac/lambda/LambdaExpr02.java + test/tools/javac/lambda/LambdaExpr04.java + test/tools/javac/lambda/LambdaExpr05.java + test/tools/javac/lambda/LambdaExpr06.java + test/tools/javac/lambda/LambdaExpr07.java + test/tools/javac/lambda/LambdaExpr08.java + test/tools/javac/lambda/LambdaExpr09.java + test/tools/javac/lambda/LambdaExpr10.java + test/tools/javac/lambda/LambdaExpr10.out + test/tools/javac/lambda/LambdaExpr11.java + test/tools/javac/lambda/LambdaExpr12.java + test/tools/javac/lambda/LambdaExpr13.java + test/tools/javac/lambda/LambdaExpr14.java + test/tools/javac/lambda/LambdaExpr15.java + test/tools/javac/lambda/LambdaExpr16.java + test/tools/javac/lambda/LambdaExpr17.java + test/tools/javac/lambda/LambdaExpr18.java + test/tools/javac/lambda/LambdaExpr19.java + test/tools/javac/lambda/LambdaExpr19.out + test/tools/javac/lambda/LambdaExpr20.java + test/tools/javac/lambda/LambdaExprNotVoid.java + test/tools/javac/lambda/LambdaExprNotVoid.out ! test/tools/javac/lambda/LambdaParserTest.java + test/tools/javac/lambda/LambdaScope01.java + test/tools/javac/lambda/LambdaScope02.java + test/tools/javac/lambda/LambdaScope03.java + test/tools/javac/lambda/LambdaScope04.java + test/tools/javac/lambda/LambdaScope04.out + test/tools/javac/lambda/LocalBreakAndContinue.java + test/tools/javac/lambda/MethodReference01.java + test/tools/javac/lambda/MethodReference02.java + test/tools/javac/lambda/MethodReference03.java + test/tools/javac/lambda/MethodReference04.java + test/tools/javac/lambda/MethodReference04.out + test/tools/javac/lambda/MethodReference05.java + test/tools/javac/lambda/MethodReference06.java + test/tools/javac/lambda/MethodReference07.java + test/tools/javac/lambda/MethodReference08.java + test/tools/javac/lambda/MethodReference08.out + test/tools/javac/lambda/MethodReference09.java + test/tools/javac/lambda/MethodReference09.out + test/tools/javac/lambda/MethodReference10.java + test/tools/javac/lambda/MethodReference11.java + test/tools/javac/lambda/MethodReference12.java + test/tools/javac/lambda/MethodReference13.java + test/tools/javac/lambda/MethodReference14.java + test/tools/javac/lambda/MethodReference15.java + test/tools/javac/lambda/MethodReference16.java + test/tools/javac/lambda/MethodReference17.java + test/tools/javac/lambda/MethodReference18.java + test/tools/javac/lambda/MethodReference19.java + test/tools/javac/lambda/MethodReference20.java + test/tools/javac/lambda/MethodReference20.out + test/tools/javac/lambda/MethodReference21.java + test/tools/javac/lambda/MethodReference21.out + test/tools/javac/lambda/MethodReference22.java + test/tools/javac/lambda/MethodReference22.out + test/tools/javac/lambda/MethodReference23.java + test/tools/javac/lambda/MethodReference23.out + test/tools/javac/lambda/MethodReference24.java + test/tools/javac/lambda/MethodReference25.java + test/tools/javac/lambda/MethodReference26.java + test/tools/javac/lambda/MethodReference26.out + test/tools/javac/lambda/MethodReference27.java + test/tools/javac/lambda/MethodReference28.java + test/tools/javac/lambda/MethodReference28.out + test/tools/javac/lambda/MethodReference29.java + test/tools/javac/lambda/MethodReference30.java + test/tools/javac/lambda/MethodReference31.java + test/tools/javac/lambda/MethodReference32.java + test/tools/javac/lambda/MethodReference32.out + test/tools/javac/lambda/MethodReference33.java + test/tools/javac/lambda/MethodReference34.java + test/tools/javac/lambda/MethodReference35.java + test/tools/javac/lambda/MethodReference36.java + test/tools/javac/lambda/MethodReference37.java + test/tools/javac/lambda/MethodReference37.out + test/tools/javac/lambda/MethodReference38.java + test/tools/javac/lambda/MethodReference38.out + test/tools/javac/lambda/MethodReference39.java + test/tools/javac/lambda/MethodReference39.out + test/tools/javac/lambda/MethodReference40.java + test/tools/javac/lambda/MethodReference40.out + test/tools/javac/lambda/MethodReference41.java + test/tools/javac/lambda/MethodReference42.java + test/tools/javac/lambda/MethodReference43.java + test/tools/javac/lambda/MethodReference44.java + test/tools/javac/lambda/MethodReference45.java + test/tools/javac/lambda/MethodReference45.out + test/tools/javac/lambda/MethodReference46.java + test/tools/javac/lambda/MethodReference47.java + test/tools/javac/lambda/MethodReference47.out + test/tools/javac/lambda/MethodReference48.java + test/tools/javac/lambda/MethodReference49.java + test/tools/javac/lambda/MethodReference50.java + test/tools/javac/lambda/MethodReference50.out + test/tools/javac/lambda/MethodReference51.java + test/tools/javac/lambda/MethodReference51.out + test/tools/javac/lambda/MethodReference52.java + test/tools/javac/lambda/MethodReference52.out + test/tools/javac/lambda/MethodReference53.java + test/tools/javac/lambda/MethodReference53.out + test/tools/javac/lambda/MethodReference54.java + test/tools/javac/lambda/MethodReference54.out ! test/tools/javac/lambda/MethodReferenceParserTest.java + test/tools/javac/lambda/MostSpecific01.java + test/tools/javac/lambda/MostSpecific01.out + test/tools/javac/lambda/MostSpecific02.java + test/tools/javac/lambda/MostSpecific02.out + test/tools/javac/lambda/MostSpecific03.java + test/tools/javac/lambda/MostSpecific03.out + test/tools/javac/lambda/MostSpecific04.java + test/tools/javac/lambda/MostSpecific05.java + test/tools/javac/lambda/MostSpecific06.java + test/tools/javac/lambda/MostSpecific06.out + test/tools/javac/lambda/MostSpecific07.java + test/tools/javac/lambda/MostSpecific07.out + test/tools/javac/lambda/NakedThis.java + test/tools/javac/lambda/SourceLevelTest.java + test/tools/javac/lambda/SourceLevelTest.out + test/tools/javac/lambda/TargetType01.java + test/tools/javac/lambda/TargetType02.java + test/tools/javac/lambda/TargetType03.java + test/tools/javac/lambda/TargetType04.java + test/tools/javac/lambda/TargetType04.out + test/tools/javac/lambda/TargetType05.java + test/tools/javac/lambda/TargetType06.java + test/tools/javac/lambda/TargetType06.out + test/tools/javac/lambda/TargetType07.java + test/tools/javac/lambda/TargetType08.java + test/tools/javac/lambda/TargetType10.java + test/tools/javac/lambda/TargetType10.out + test/tools/javac/lambda/TargetType11.java + test/tools/javac/lambda/TargetType11.out + test/tools/javac/lambda/TargetType12.java + test/tools/javac/lambda/TargetType13.java + test/tools/javac/lambda/TargetType13.out + test/tools/javac/lambda/TargetType14.java + test/tools/javac/lambda/TargetType14.out + test/tools/javac/lambda/TargetType15.java + test/tools/javac/lambda/TargetType16.java + test/tools/javac/lambda/TargetType16.out + test/tools/javac/lambda/TargetType17.java + test/tools/javac/lambda/TargetType17.out + test/tools/javac/lambda/TargetType18.java + test/tools/javac/lambda/TargetType19.java + test/tools/javac/lambda/TargetType19.out + test/tools/javac/lambda/TargetType20.java + test/tools/javac/lambda/TargetType20.out + test/tools/javac/lambda/TargetType21.java + test/tools/javac/lambda/TargetType21.out + test/tools/javac/lambda/TargetType22.java + test/tools/javac/lambda/TargetType22.out + test/tools/javac/lambda/TargetType23.java + test/tools/javac/lambda/TargetType23.out + test/tools/javac/lambda/TargetType24.java + test/tools/javac/lambda/TargetType24.out + test/tools/javac/lambda/TargetType25.java + test/tools/javac/lambda/TargetType26.java + test/tools/javac/lambda/TargetType26.out + test/tools/javac/lambda/TargetType27.java + test/tools/javac/lambda/TargetType27.out + test/tools/javac/lambda/TargetType28.java + test/tools/javac/lambda/TargetType28.out + test/tools/javac/lambda/TargetType29.java + test/tools/javac/lambda/TargetType30.java + test/tools/javac/lambda/TargetType31.java + test/tools/javac/lambda/TargetType32.java + test/tools/javac/lambda/TargetType33.java + test/tools/javac/lambda/TargetType33.out + test/tools/javac/lambda/TargetType34.java + test/tools/javac/lambda/TargetType35.java + test/tools/javac/lambda/TargetType36.java + test/tools/javac/lambda/TargetType37.java + test/tools/javac/lambda/TargetType38.java + test/tools/javac/lambda/TargetType38.out + test/tools/javac/lambda/TargetType39.java + test/tools/javac/lambda/TargetType39.out + test/tools/javac/lambda/TargetType40.java + test/tools/javac/lambda/TargetType40.out + test/tools/javac/lambda/TargetType41.java + test/tools/javac/lambda/TargetType41.out + test/tools/javac/lambda/TargetType42.java + test/tools/javac/lambda/TargetType43.java + test/tools/javac/lambda/TargetType43.out + test/tools/javac/lambda/TargetType44.java + test/tools/javac/lambda/TargetType44.out + test/tools/javac/lambda/TargetType45.java + test/tools/javac/lambda/TargetType45.out + test/tools/javac/lambda/TargetType46.java + test/tools/javac/lambda/TargetType46.out + test/tools/javac/lambda/TargetType47.java + test/tools/javac/lambda/TargetType48.java + test/tools/javac/lambda/TargetType49.java + test/tools/javac/lambda/TargetType49.out + test/tools/javac/lambda/TargetType50.java + test/tools/javac/lambda/TargetType50.out ! test/tools/javac/lambda/TestInvokeDynamic.java + test/tools/javac/lambda/TestSelfRef.java + test/tools/javac/lambda/VoidCompatibility.java + test/tools/javac/lambda/VoidCompatibility.out + test/tools/javac/lambda/abort/Abort.java + test/tools/javac/lambda/badMemberRefBytecode/Main.java + test/tools/javac/lambda/badMemberRefBytecode/TestBadMemberRefBytecode.java + test/tools/javac/lambda/badMemberRefBytecode/Use.java + test/tools/javac/lambda/funcInterfaces/Helper.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg1.out + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg2.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg2.out + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg3.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg3.out + test/tools/javac/lambda/funcInterfaces/LambdaTest2_SAM1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_SAM2.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_SAM3.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.out + test/tools/javac/lambda/funcInterfaces/NonSAM1.java + test/tools/javac/lambda/funcInterfaces/NonSAM1.out + test/tools/javac/lambda/funcInterfaces/NonSAM2.java + test/tools/javac/lambda/funcInterfaces/NonSAM2.out + test/tools/javac/lambda/funcInterfaces/NonSAM3.java + test/tools/javac/lambda/funcInterfaces/NonSAM3.out + test/tools/javac/lambda/lambdaExpression/AbstractClass_neg.java + test/tools/javac/lambda/lambdaExpression/AbstractClass_neg.out + test/tools/javac/lambda/lambdaExpression/AccessNonStatic_neg.java + test/tools/javac/lambda/lambdaExpression/AccessNonStatic_neg.out + test/tools/javac/lambda/lambdaExpression/EffectivelyFinal_neg.java + test/tools/javac/lambda/lambdaExpression/EffectivelyFinal_neg.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression1.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression1.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression3.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression3.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression4.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression4.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression5.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression5.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression6.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression6.out + test/tools/javac/lambda/lambdaExpression/LambdaTest1.java + test/tools/javac/lambda/lambdaExpression/LambdaTest2.java + test/tools/javac/lambda/lambdaExpression/LambdaTest3.java + test/tools/javac/lambda/lambdaExpression/LambdaTest4.java + test/tools/javac/lambda/lambdaExpression/LambdaTest5.java + test/tools/javac/lambda/lambdaExpression/LambdaTest6.java + test/tools/javac/lambda/lambdaExpression/SamConversion.java + test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java + test/tools/javac/lambda/methodReference/BridgeMethod.java + test/tools/javac/lambda/methodReference/MethodRef1.java + test/tools/javac/lambda/methodReference/MethodRef2.java + test/tools/javac/lambda/methodReference/MethodRef3.java + test/tools/javac/lambda/methodReference/MethodRef4.java + test/tools/javac/lambda/methodReference/MethodRef5.java + test/tools/javac/lambda/methodReference/MethodRef6.java + test/tools/javac/lambda/methodReference/MethodRef7.java + test/tools/javac/lambda/methodReference/MethodRef_neg.java + test/tools/javac/lambda/methodReference/MethodRef_neg.out + test/tools/javac/lambda/methodReference/SamConversion.java + test/tools/javac/lambda/methodReference/SamConversionComboTest.java + test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java + test/tools/javac/lambda/speculative/A.java + test/tools/javac/lambda/speculative/DiamondFinder.java + test/tools/javac/lambda/speculative/Main.java + test/tools/javac/lambda/speculative/Main.out + test/tools/javac/lambda/typeInference/InferenceTest11.java + test/tools/javac/lambda/typeInference/InferenceTest2.java + test/tools/javac/lambda/typeInference/InferenceTest2b.java + test/tools/javac/lambda/typeInference/InferenceTest3.java + test/tools/javac/lambda/typeInference/InferenceTest4.java + test/tools/javac/lambda/typeInference/InferenceTest5.java + test/tools/javac/lambda/typeInference/InferenceTest789.java + test/tools/javac/lambda/typeInference/InferenceTest_neg1_2.java + test/tools/javac/lambda/typeInference/InferenceTest_neg1_2.out + test/tools/javac/lambda/typeInference/InferenceTest_neg5.java + test/tools/javac/lambda/typeInference/InferenceTest_neg5.out + test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java ! test/tools/javac/typeAnnotations/newlocations/BasicTest.out Changeset: c0f0c41cafa0 Author: jjg Date: 2012-11-19 11:38 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/c0f0c41cafa0 8001098: Provide a simple light-weight "plug-in" mechanism for javac Reviewed-by: mcimadamore + src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/plugin/showtype/Identifiers.java + test/tools/javac/plugin/showtype/Identifiers.out + test/tools/javac/plugin/showtype/Identifiers_PI.out + test/tools/javac/plugin/showtype/ShowTypePlugin.java + test/tools/javac/plugin/showtype/Test.java Changeset: 522a1ee72340 Author: bpatel Date: 2012-11-19 16:10 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/522a1ee72340 8002304: Group methods by types in methods summary section Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/script.js ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodTypes.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java + test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java + test/com/sun/javadoc/testMethodTypes/pkg1/A.java + test/com/sun/javadoc/testMethodTypes/pkg1/B.java + test/com/sun/javadoc/testMethodTypes/pkg1/D.java ! test/tools/javadoc/api/basic/APITest.java Changeset: 2531de382983 Author: jjg Date: 2012-11-19 16:40 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/2531de382983 8003655: Add javac.jvm.ClassFile.V52 Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java Changeset: a25c53e12bd0 Author: jjg Date: 2012-11-20 07:21 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/a25c53e12bd0 8003649: regression/langtools: tools/javac/doctree Reviewed-by: ksrini ! test/tools/javac/doctree/DocCommentTester.java Changeset: fb97eaf93d61 Author: jjg Date: 2012-11-20 07:25 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/fb97eaf93d61 8003650: java.lang.Exception: expected string not found: pkg/package-frame.html Reviewed-by: ksrini ! test/tools/javadoc/api/basic/GetTask_WriterTest.java ! test/tools/javadoc/api/basic/RunTest.java Changeset: 7538e419a588 Author: mcimadamore Date: 2012-11-20 15:43 +0000 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/7538e419a588 8003663: lambda test fails on Windows Summary: fix path separator issue in test Reviewed-by: jjg ! test/tools/javac/lambda/abort/Abort.java Changeset: d898d9ee352f Author: rfield Date: 2012-11-20 09:58 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/d898d9ee352f 8003639: convert lambda testng tests to jtreg and add them Reviewed-by: mcimadamore + test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/defaultMethods/fd/FDTest.java - test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java - test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java - test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java - test/tools/javac/defaultMethods/fd/shapegen/Rule.java - test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java - test/tools/javac/defaultMethods/fd/shapegen/TTNode.java - test/tools/javac/defaultMethods/fd/shapegen/TTParser.java - test/tools/javac/defaultMethods/fd/shapegen/TTShape.java + test/tools/javac/lambda/lambdaExecution/InInterface.java + test/tools/javac/lambda/lambdaExecution/InnerConstructor.java + test/tools/javac/lambda/lambdaExecution/LambdaTranslationTest1.java + test/tools/javac/lambda/lambdaExecution/LambdaTranslationTest2.java + test/tools/javac/lambda/lambdaExecution/TBlock.java + test/tools/javac/lambda/lambdaExecution/TMapper.java + test/tools/javac/lambda/lambdaExecution/TPredicate.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestFDCCE.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInnerDefault.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInnerInstance.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInnerVarArgsThis.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInstance.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestNew.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestNewInner.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase1.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase2.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase4.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSuper.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSuperDefault.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestTypeConversion.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgs.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsExt.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsSuper.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsSuperDefault.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsThis.java + test/tools/javac/lambdaShapes/TEST.properties + test/tools/javac/lambdaShapes/org/openjdk/tests/javac/FDTest.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/AttributeInjector.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFile.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFilePreprocessor.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassToInterfaceConverter.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/DirectedClassLoader.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/ClassCase.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/Hierarchy.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/HierarchyGenerator.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/Rule.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/RuleGroup.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/TTNode.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/TTParser.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/TTShape.java + test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java + test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java Changeset: 09ba1bfab344 Author: lana Date: 2012-11-20 11:50 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/09ba1bfab344 Merge - src/share/classes/com/sun/tools/javac/parser/SimpleDocCommentTable.java - test/tools/javac/defaultMethods/fd/FDTest.java - test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java - test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java - test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java - test/tools/javac/defaultMethods/fd/shapegen/Rule.java - test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java - test/tools/javac/defaultMethods/fd/shapegen/TTNode.java - test/tools/javac/defaultMethods/fd/shapegen/TTParser.java - test/tools/javac/defaultMethods/fd/shapegen/TTShape.java - test/tools/javac/diags/examples/CantAccessArgTypeInFunctionalDesc.java - test/tools/javac/diags/examples/CantAccessReturnTypeInFunctionalDesc.java - test/tools/javac/diags/examples/CantAccessThrownTypesInFunctionalDesc.java - test/tools/javac/diags/examples/CantReturnValueForVoid.java Changeset: da48ab364ea4 Author: erikj Date: 2012-11-28 13:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/da48ab364ea4 8003844: build-infra: docs target isn't working properly Summary: Adding resources to bootstrap javadoc.jar. Adding missing .js resource suffix Reviewed-by: ohair, jjg, ohrstrom ! makefiles/BuildLangtools.gmk Changeset: 20230f8b0eef Author: katleman Date: 2012-11-28 14:07 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/20230f8b0eef Merge Changeset: 303b09787a69 Author: katleman Date: 2012-11-29 11:31 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/langtools/rev/303b09787a69 Added tag jdk8-b66 for changeset 20230f8b0eef ! .hgtags From forax at univ-mlv.fr Fri Nov 30 02:29:36 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 30 Nov 2012 11:29:36 +0100 Subject: Request for reviews (S): 8001885 : JSR 292 classes should use jdk.internal.org.objectweb.asm In-Reply-To: References: <4DAC718F-42DF-427A-BA40-081971790175@oracle.com> Message-ID: <50B88A90.20408@univ-mlv.fr> On 11/30/2012 02:45 AM, John Rose wrote: > On Nov 29, 2012, at 12:48 PM, David Chase wrote: > >> http://cr.openjdk.java.net/~drchase/8001885/webrev.00/ >> > > I'm relieved to see no code changes. The ASM version we are using is > now 4, which has significant incompatible changes from 3. ? John yes, ASM4 was changed to be make all future releases of ASM fully binary compatibility. As a side note, the version of ASM currently embedded with the JDK is a little faster/more compact in memory that the one provided as binary on the ASM web site which is 1.4 binary compatible. R?mi ASM developer From agoncharuk at gridgain.com Fri Nov 30 05:05:31 2012 From: agoncharuk at gridgain.com (Alexey Goncharuk) Date: Fri, 30 Nov 2012 17:05:31 +0400 Subject: Broken thread scheduling in indexed loop (missing safepoint?) Message-ID: Hi, We faced some weird issue with thread scheduling. At a first glance it looked like it relates to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not exactly. This is the code we ran: public static void main(String[] args) throws Exception { Thread worker = new Thread() { @Override public void run() { double d = 0; for (int j = 1; j < 2000000000; j++) d += Math.log(Math.E * j); System.out.println(d); } }; Thread reporter = new Thread() { @Override public void run() { try { while (true) { Thread.sleep(1000); System.out.println("Running: " + System.currentTimeMillis()); } } catch (InterruptedException ignored) { Thread.currentThread().interrupt(); } } }; reporter.start(); worker.start(); worker.join(); reporter.interrupt(); } One can expect that printing thread would output messages during all the calculation time, however it hangs after 3-4 iterations. Setting -XX:FreqInlineSize=0 as described in original bug report does not help in this case, but if I extract loop body into a separate method, setting this option works. Example passes with -Xint option as well. (Tested with 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) I saw #7160161 marked as resolved, so I just wanted to confirm if behavior we see really relates to this issue and it was fixed (bug report covers non-Counted loop only). Also, is there any other workarounds rather then extracting the method and specifying FreqInlineSize=0? Thanks, Alexey Goncharuk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/d8e1a3a9/attachment.html From bharadwaj.yadavalli at oracle.com Fri Nov 30 05:07:48 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 30 Nov 2012 08:07:48 -0500 Subject: RFR (S): 8003195 - AbstractAssembler should not store code pointers but use the CodeSection directly In-Reply-To: <3269FCE1-B766-42A6-8EE6-E62A96F63051@oracle.com> References: <50B78828.4000105@oracle.com> <3269FCE1-B766-42A6-8EE6-E62A96F63051@oracle.com> Message-ID: <50B8AFA4.5@oracle.com> Updated webrev. Please review. http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ Re-ran JPRT successfully. Thanks, Bharadwaj On 11/29/2012 2:48 PM, Vladimir Kozlov wrote: > On Nov 29, 2012, at 11:48 AM, Christian Thalinger wrote: > >> On Nov 29, 2012, at 11:33 AM, Vladimir Kozlov wrote: >> >>> I don't like explicit casting of address to int64 or int32. I would prefer original code moved to codeBuffer as other functions. >> You're saying adding: >> >> + void emit_address( address x) { *((address*) end()) = x; set_end(end() + sizeof(address)); } >> >> to CodeSection? > Yes. > >>> An other good cleanup would be remove emit_word() and emit_long() which are very confusing sizewise. But it is for next round. >> Yes. That's the plan for my other upcoming changes. This is the first step in that direction. > OK. > > Vladimir > >> -- Chris >> >>> Thanks, >>> Vladimir >>> >>> >>> On Nov 29, 2012, at 8:07 AM, Bharadwaj Yadavalli wrote: >>> >>>> Please review >>>> http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ >>>> >>>> This change is a result of applying the patch from Christian Thalinger attached in the bug report with a couple of minor tweaks and are for x86 architecture only. >>>> >>>> Thanks, >>>> >>>> Bharadwaj >>>> From vladimir.kozlov at oracle.com Fri Nov 30 09:17:03 2012 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Nov 2012 09:17:03 -0800 Subject: RFR (S): 8003195 - AbstractAssembler should not store code pointers but use the CodeSection directly In-Reply-To: <50B8AFA4.5@oracle.com> References: <50B78828.4000105@oracle.com> <3269FCE1-B766-42A6-8EE6-E62A96F63051@oracle.com> <50B8AFA4.5@oracle.com> Message-ID: It is good. Thanks, Vladimir On Nov 30, 2012, at 5:07 AM, Bharadwaj Yadavalli wrote: > Updated webrev. Please review. > > http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ > > Re-ran JPRT successfully. > > Thanks, > > Bharadwaj > > On 11/29/2012 2:48 PM, Vladimir Kozlov wrote: >> On Nov 29, 2012, at 11:48 AM, Christian Thalinger wrote: >> >>> On Nov 29, 2012, at 11:33 AM, Vladimir Kozlov wrote: >>> >>>> I don't like explicit casting of address to int64 or int32. I would prefer original code moved to codeBuffer as other functions. >>> You're saying adding: >>> >>> + void emit_address( address x) { *((address*) end()) = x; set_end(end() + sizeof(address)); } >>> >>> to CodeSection? >> Yes. >> >>>> An other good cleanup would be remove emit_word() and emit_long() which are very confusing sizewise. But it is for next round. >>> Yes. That's the plan for my other upcoming changes. This is the first step in that direction. >> OK. >> >> Vladimir >> >>> -- Chris >>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On Nov 29, 2012, at 8:07 AM, Bharadwaj Yadavalli wrote: >>>> >>>>> Please review >>>>> http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ >>>>> >>>>> This change is a result of applying the patch from Christian Thalinger attached in the bug report with a couple of minor tweaks and are for x86 architecture only. >>>>> >>>>> Thanks, >>>>> >>>>> Bharadwaj >>>>> From vladimir.x.ivanov at oracle.com Fri Nov 30 10:52:07 2012 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 30 Nov 2012 21:52:07 +0300 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: Message-ID: <50B90057.3030807@oracle.com> Alexey, The reason is different from 7160161: safepoint is omitted, since the loop is counted. After ~3 seconds, safepoint is initiated and sleeping loop enters it. However, other thread blocks the safepoint. That's why you don't see ticks. Try the test with -XX:+TraceSafepoint: Running: 1354301155502 Running: 1354301156503 Running: 1354301157504 Safepoint synchronization initiated. (9) As a possible workaround, I would suggest you to rewrite the loop to make it non-countable. Best regards, Vladimir Ivanov On 11/30/12 4:05 PM, Alexey Goncharuk wrote: > Hi, > > We faced some weird issue with thread scheduling. At a first glance it > looked like it relates to > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not exactly. > > This is the code we ran: > > public static void main(String[] args) throws Exception { Thread worker > = new Thread() { @Override public void run() { double d = 0; for (int j > = 1; j < 2000000000; j++) d += Math.log(Math.E * j); > System.out.println(d); } }; Thread reporter = new Thread() { @Override > public void run() { try { while (true) { Thread.sleep(1000); > System.out.println("Running: " + System.currentTimeMillis()); } } catch > (InterruptedException ignored) { Thread.currentThread().interrupt(); } } > }; reporter.start(); worker.start(); worker.join(); reporter.interrupt(); } > > One can expect that printing thread would output messages during all the > calculation time, however it hangs after 3-4 iterations. Setting > -XX:FreqInlineSize=0 as described in original bug report does not help > in this case, but if I extract loop body into a separate method, setting > this option works. Example passes with -Xint option as well. (Tested > with 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) > > I saw #7160161 marked as resolved, so I just wanted to confirm if > behavior we see really relates to this issue and it was fixed (bug > report covers non-Counted loop only). > > Also, is there any other workarounds rather then extracting the method > and specifying FreqInlineSize=0? > > Thanks, > Alexey Goncharuk > From volker.simonis at gmail.com Fri Nov 30 10:40:02 2012 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 30 Nov 2012 19:40:02 +0100 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: Message-ID: Hi, This is a long standing problem of HotSpot (compared for example to J9). It doesn't put Safepoints into counted int loops (because it assumes they will terminate just "fast enough" which is not the case in your example). You can see another example for this behavior in these slides "http://www.progdoc.de/papers/Jax2012/jax2012.html#%288%29" together with the generated assembler code. You can easily solve the problem by making your loop variable a "long" instead of an "int". In that case, HotSpot will be more cautious and place a safepoint into the loop. Regards, Volker On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk wrote: > Hi, > > We faced some weird issue with thread scheduling. At a first glance it > looked like it relates to > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not exactly. > > This is the code we ran: > > public static void main(String[] args) throws Exception { Thread worker = > new Thread() { @Override public void run() { double d = 0; for (int j = 1; j > < 2000000000; j++) d += Math.log(Math.E * j); System.out.println(d); } }; > Thread reporter = new Thread() { @Override public void run() { try { while > (true) { Thread.sleep(1000); System.out.println("Running: " + > System.currentTimeMillis()); } } catch (InterruptedException ignored) { > Thread.currentThread().interrupt(); } } }; reporter.start(); worker.start(); > worker.join(); reporter.interrupt(); } > > One can expect that printing thread would output messages during all the > calculation time, however it hangs after 3-4 iterations. Setting > -XX:FreqInlineSize=0 as described in original bug report does not help in > this case, but if I extract loop body into a separate method, setting this > option works. Example passes with -Xint option as well. (Tested with > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) > > I saw #7160161 marked as resolved, so I just wanted to confirm if behavior > we see really relates to this issue and it was fixed (bug report covers > non-Counted loop only). > > Also, is there any other workarounds rather then extracting the method and > specifying FreqInlineSize=0? > > Thanks, > Alexey Goncharuk > From christian.thalinger at oracle.com Fri Nov 30 11:36:28 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 30 Nov 2012 11:36:28 -0800 Subject: Request for reviews (S): 8001885 : JSR 292 classes should use jdk.internal.org.objectweb.asm In-Reply-To: References: <4DAC718F-42DF-427A-BA40-081971790175@oracle.com> Message-ID: <541714D0-C76F-4CD9-A576-444C8D68B5E6@oracle.com> On Nov 29, 2012, at 5:45 PM, John Rose wrote: > On Nov 29, 2012, at 12:48 PM, David Chase wrote: > >> http://cr.openjdk.java.net/~drchase/8001885/webrev.00/ > > I'm relieved to see no code changes. The ASM version we are using is now 4, which has significant incompatible changes from 3. ? John We tried to keep it simple :-) David, I'm going to push your change now. -- Chris From vitalyd at gmail.com Fri Nov 30 11:36:35 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 14:36:35 -0500 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: Message-ID: Hi Volker, Just curious - what happens if a STW GC needs to occur right as this type of loop is entered? Does the VM just stall until the loop exits? What if this loop does a fast path allocation on some iteration? Do all allocations check for safepoints internally? Thanks Sent from my phone On Nov 30, 2012 1:41 PM, "Volker Simonis" wrote: > Hi, > > This is a long standing problem of HotSpot (compared for example to > J9). It doesn't put Safepoints into counted int loops (because it > assumes they will terminate just "fast enough" which is not the case > in your example). You can see another example for this behavior in > these slides "http://www.progdoc.de/papers/Jax2012/jax2012.html#%288%29" > together with the generated assembler code. > > You can easily solve the problem by making your loop variable a "long" > instead of an "int". In that case, HotSpot will be more cautious and > place a safepoint into the loop. > > Regards, > Volker > > On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk > wrote: > > Hi, > > > > We faced some weird issue with thread scheduling. At a first glance it > > looked like it relates to > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not > exactly. > > > > This is the code we ran: > > > > public static void main(String[] args) throws Exception { Thread worker = > > new Thread() { @Override public void run() { double d = 0; for (int j = > 1; j > > < 2000000000; j++) d += Math.log(Math.E * j); System.out.println(d); } }; > > Thread reporter = new Thread() { @Override public void run() { try { > while > > (true) { Thread.sleep(1000); System.out.println("Running: " + > > System.currentTimeMillis()); } } catch (InterruptedException ignored) { > > Thread.currentThread().interrupt(); } } }; reporter.start(); > worker.start(); > > worker.join(); reporter.interrupt(); } > > > > One can expect that printing thread would output messages during all the > > calculation time, however it hangs after 3-4 iterations. Setting > > -XX:FreqInlineSize=0 as described in original bug report does not help in > > this case, but if I extract loop body into a separate method, setting > this > > option works. Example passes with -Xint option as well. (Tested with > > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) > > > > I saw #7160161 marked as resolved, so I just wanted to confirm if > behavior > > we see really relates to this issue and it was fixed (bug report covers > > non-Counted loop only). > > > > Also, is there any other workarounds rather then extracting the method > and > > specifying FreqInlineSize=0? > > > > Thanks, > > Alexey Goncharuk > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/04043652/attachment.html From kirk at kodewerk.com Fri Nov 30 11:42:04 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 30 Nov 2012 20:42:04 +0100 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: Message-ID: <00B03FFD-AB48-425C-ABFD-04A8335CAB1B@kodewerk.com> We have an app that in one threads creates objects and never releases them and then in another, does a calculation in a tight loop. I would suggest if you try this you first save everything that you want to keep because when this app is run... the only way to recover is to reboot your computer. It's fun!!!! -- Kirk On 2012-11-30, at 8:36 PM, Vitaly Davidovich wrote: > Hi Volker, > > Just curious - what happens if a STW GC needs to occur right as this type of loop is entered? Does the VM just stall until the loop exits? What if this loop does a fast path allocation on some iteration? Do all allocations check for safepoints internally? > > Thanks > > Sent from my phone > > On Nov 30, 2012 1:41 PM, "Volker Simonis" wrote: > Hi, > > This is a long standing problem of HotSpot (compared for example to > J9). It doesn't put Safepoints into counted int loops (because it > assumes they will terminate just "fast enough" which is not the case > in your example). You can see another example for this behavior in > these slides "http://www.progdoc.de/papers/Jax2012/jax2012.html#%288%29" > together with the generated assembler code. > > You can easily solve the problem by making your loop variable a "long" > instead of an "int". In that case, HotSpot will be more cautious and > place a safepoint into the loop. > > Regards, > Volker > > On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk > wrote: > > Hi, > > > > We faced some weird issue with thread scheduling. At a first glance it > > looked like it relates to > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not exactly. > > > > This is the code we ran: > > > > public static void main(String[] args) throws Exception { Thread worker = > > new Thread() { @Override public void run() { double d = 0; for (int j = 1; j > > < 2000000000; j++) d += Math.log(Math.E * j); System.out.println(d); } }; > > Thread reporter = new Thread() { @Override public void run() { try { while > > (true) { Thread.sleep(1000); System.out.println("Running: " + > > System.currentTimeMillis()); } } catch (InterruptedException ignored) { > > Thread.currentThread().interrupt(); } } }; reporter.start(); worker.start(); > > worker.join(); reporter.interrupt(); } > > > > One can expect that printing thread would output messages during all the > > calculation time, however it hangs after 3-4 iterations. Setting > > -XX:FreqInlineSize=0 as described in original bug report does not help in > > this case, but if I extract loop body into a separate method, setting this > > option works. Example passes with -Xint option as well. (Tested with > > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) > > > > I saw #7160161 marked as resolved, so I just wanted to confirm if behavior > > we see really relates to this issue and it was fixed (bug report covers > > non-Counted loop only). > > > > Also, is there any other workarounds rather then extracting the method and > > specifying FreqInlineSize=0? > > > > Thanks, > > Alexey Goncharuk > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/efa734fc/attachment.html From christian.thalinger at oracle.com Fri Nov 30 11:46:32 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 30 Nov 2012 11:46:32 -0800 Subject: RFR (S): 8003195 - AbstractAssembler should not store code pointers but use the CodeSection directly In-Reply-To: <50B8AFA4.5@oracle.com> References: <50B78828.4000105@oracle.com> <3269FCE1-B766-42A6-8EE6-E62A96F63051@oracle.com> <50B8AFA4.5@oracle.com> Message-ID: <1B731568-4EBC-402D-81D6-3035645A2C31@oracle.com> Looks good. An integration job is in the queue. -- Chris On Nov 30, 2012, at 5:07 AM, Bharadwaj Yadavalli wrote: > Updated webrev. Please review. > > http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ > > Re-ran JPRT successfully. > > Thanks, > > Bharadwaj > > On 11/29/2012 2:48 PM, Vladimir Kozlov wrote: >> On Nov 29, 2012, at 11:48 AM, Christian Thalinger wrote: >> >>> On Nov 29, 2012, at 11:33 AM, Vladimir Kozlov wrote: >>> >>>> I don't like explicit casting of address to int64 or int32. I would prefer original code moved to codeBuffer as other functions. >>> You're saying adding: >>> >>> + void emit_address( address x) { *((address*) end()) = x; set_end(end() + sizeof(address)); } >>> >>> to CodeSection? >> Yes. >> >>>> An other good cleanup would be remove emit_word() and emit_long() which are very confusing sizewise. But it is for next round. >>> Yes. That's the plan for my other upcoming changes. This is the first step in that direction. >> OK. >> >> Vladimir >> >>> -- Chris >>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On Nov 29, 2012, at 8:07 AM, Bharadwaj Yadavalli wrote: >>>> >>>>> Please review >>>>> http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ >>>>> >>>>> This change is a result of applying the patch from Christian Thalinger attached in the bug report with a couple of minor tweaks and are for x86 architecture only. >>>>> >>>>> Thanks, >>>>> >>>>> Bharadwaj >>>>> From vitalyd at gmail.com Fri Nov 30 11:49:46 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 14:49:46 -0500 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: <00B03FFD-AB48-425C-ABFD-04A8335CAB1B@kodewerk.com> References: <00B03FFD-AB48-425C-ABFD-04A8335CAB1B@kodewerk.com> Message-ID: Haha :) So it blows through Xmx, ram, and starts swapping like crazy? Sent from my phone On Nov 30, 2012 2:42 PM, "Kirk Pepperdine" wrote: > We have an app that in one threads creates objects and never releases them > and then in another, does a calculation in a tight loop. I would suggest if > you try this you first save everything that you want to keep because when > this app is run... the only way to recover is to reboot your computer. > > It's fun!!!! > > -- Kirk > > On 2012-11-30, at 8:36 PM, Vitaly Davidovich wrote: > > Hi Volker, > > Just curious - what happens if a STW GC needs to occur right as this type > of loop is entered? Does the VM just stall until the loop exits? What if > this loop does a fast path allocation on some iteration? Do all allocations > check for safepoints internally? > > Thanks > > Sent from my phone > On Nov 30, 2012 1:41 PM, "Volker Simonis" > wrote: > >> Hi, >> >> This is a long standing problem of HotSpot (compared for example to >> J9). It doesn't put Safepoints into counted int loops (because it >> assumes they will terminate just "fast enough" which is not the case >> in your example). You can see another example for this behavior in >> these slides "http://www.progdoc.de/papers/Jax2012/jax2012.html#%288%29" >> together with the generated assembler code. >> >> You can easily solve the problem by making your loop variable a "long" >> instead of an "int". In that case, HotSpot will be more cautious and >> place a safepoint into the loop. >> >> Regards, >> Volker >> >> On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk >> wrote: >> > Hi, >> > >> > We faced some weird issue with thread scheduling. At a first glance it >> > looked like it relates to >> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not >> exactly. >> > >> > This is the code we ran: >> > >> > public static void main(String[] args) throws Exception { Thread worker >> = >> > new Thread() { @Override public void run() { double d = 0; for (int j = >> 1; j >> > < 2000000000; j++) d += Math.log(Math.E * j); System.out.println(d); } >> }; >> > Thread reporter = new Thread() { @Override public void run() { try { >> while >> > (true) { Thread.sleep(1000); System.out.println("Running: " + >> > System.currentTimeMillis()); } } catch (InterruptedException ignored) { >> > Thread.currentThread().interrupt(); } } }; reporter.start(); >> worker.start(); >> > worker.join(); reporter.interrupt(); } >> > >> > One can expect that printing thread would output messages during all the >> > calculation time, however it hangs after 3-4 iterations. Setting >> > -XX:FreqInlineSize=0 as described in original bug report does not help >> in >> > this case, but if I extract loop body into a separate method, setting >> this >> > option works. Example passes with -Xint option as well. (Tested with >> > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) >> > >> > I saw #7160161 marked as resolved, so I just wanted to confirm if >> behavior >> > we see really relates to this issue and it was fixed (bug report covers >> > non-Counted loop only). >> > >> > Also, is there any other workarounds rather then extracting the method >> and >> > specifying FreqInlineSize=0? >> > >> > Thanks, >> > Alexey Goncharuk >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/a236d954/attachment-0001.html From bharadwaj.yadavalli at oracle.com Fri Nov 30 11:50:08 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Fri, 30 Nov 2012 14:50:08 -0500 Subject: RFR (S): 8003195 - AbstractAssembler should not store code pointers but use the CodeSection directly In-Reply-To: <1B731568-4EBC-402D-81D6-3035645A2C31@oracle.com> References: <50B78828.4000105@oracle.com> <3269FCE1-B766-42A6-8EE6-E62A96F63051@oracle.com> <50B8AFA4.5@oracle.com> <1B731568-4EBC-402D-81D6-3035645A2C31@oracle.com> Message-ID: <50B90DF0.9070108@oracle.com> Thanks for the reviews and help to push it. Bharadwaj On 11/30/2012 2:46 PM, Christian Thalinger wrote: > Looks good. An integration job is in the queue. > > -- Chris > > On Nov 30, 2012, at 5:07 AM, Bharadwaj Yadavalli wrote: > >> Updated webrev. Please review. >> >> http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ >> >> Re-ran JPRT successfully. >> >> Thanks, >> >> Bharadwaj >> >> On 11/29/2012 2:48 PM, Vladimir Kozlov wrote: >>> On Nov 29, 2012, at 11:48 AM, Christian Thalinger wrote: >>> >>>> On Nov 29, 2012, at 11:33 AM, Vladimir Kozlov wrote: >>>> >>>>> I don't like explicit casting of address to int64 or int32. I would prefer original code moved to codeBuffer as other functions. >>>> You're saying adding: >>>> >>>> + void emit_address( address x) { *((address*) end()) = x; set_end(end() + sizeof(address)); } >>>> >>>> to CodeSection? >>> Yes. >>> >>>>> An other good cleanup would be remove emit_word() and emit_long() which are very confusing sizewise. But it is for next round. >>>> Yes. That's the plan for my other upcoming changes. This is the first step in that direction. >>> OK. >>> >>> Vladimir >>> >>>> -- Chris >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> On Nov 29, 2012, at 8:07 AM, Bharadwaj Yadavalli wrote: >>>>> >>>>>> Please review >>>>>> http://cr.openjdk.java.net/~bharadwaj/8003195/webrev/ >>>>>> >>>>>> This change is a result of applying the patch from Christian Thalinger attached in the bug report with a couple of minor tweaks and are for x86 architecture only. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Bharadwaj >>>>>> From kirk at kodewerk.com Fri Nov 30 12:19:00 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 30 Nov 2012 21:19:00 +0100 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: <00B03FFD-AB48-425C-ABFD-04A8335CAB1B@kodewerk.com> Message-ID: <07858065-883B-4566-AEDE-D5752279EC02@kodewerk.com> Nope.. not the problem. GC calls for a safe point and all the thread 'cept one obey (guess which one!!!). This make the VM completely unresponsive to any signals. Strangely enough it's also apparently resistant to kill -9.. and since it's burning through CPU.... -- Kirk On 2012-11-30, at 8:49 PM, Vitaly Davidovich wrote: > Haha :) > > So it blows through Xmx, ram, and starts swapping like crazy? > > Sent from my phone > > On Nov 30, 2012 2:42 PM, "Kirk Pepperdine" wrote: > We have an app that in one threads creates objects and never releases them and then in another, does a calculation in a tight loop. I would suggest if you try this you first save everything that you want to keep because when this app is run... the only way to recover is to reboot your computer. > > It's fun!!!! > > -- Kirk > > On 2012-11-30, at 8:36 PM, Vitaly Davidovich wrote: > >> Hi Volker, >> >> Just curious - what happens if a STW GC needs to occur right as this type of loop is entered? Does the VM just stall until the loop exits? What if this loop does a fast path allocation on some iteration? Do all allocations check for safepoints internally? >> >> Thanks >> >> Sent from my phone >> >> On Nov 30, 2012 1:41 PM, "Volker Simonis" wrote: >> Hi, >> >> This is a long standing problem of HotSpot (compared for example to >> J9). It doesn't put Safepoints into counted int loops (because it >> assumes they will terminate just "fast enough" which is not the case >> in your example). You can see another example for this behavior in >> these slides "http://www.progdoc.de/papers/Jax2012/jax2012.html#%288%29" >> together with the generated assembler code. >> >> You can easily solve the problem by making your loop variable a "long" >> instead of an "int". In that case, HotSpot will be more cautious and >> place a safepoint into the loop. >> >> Regards, >> Volker >> >> On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk >> wrote: >> > Hi, >> > >> > We faced some weird issue with thread scheduling. At a first glance it >> > looked like it relates to >> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not exactly. >> > >> > This is the code we ran: >> > >> > public static void main(String[] args) throws Exception { Thread worker = >> > new Thread() { @Override public void run() { double d = 0; for (int j = 1; j >> > < 2000000000; j++) d += Math.log(Math.E * j); System.out.println(d); } }; >> > Thread reporter = new Thread() { @Override public void run() { try { while >> > (true) { Thread.sleep(1000); System.out.println("Running: " + >> > System.currentTimeMillis()); } } catch (InterruptedException ignored) { >> > Thread.currentThread().interrupt(); } } }; reporter.start(); worker.start(); >> > worker.join(); reporter.interrupt(); } >> > >> > One can expect that printing thread would output messages during all the >> > calculation time, however it hangs after 3-4 iterations. Setting >> > -XX:FreqInlineSize=0 as described in original bug report does not help in >> > this case, but if I extract loop body into a separate method, setting this >> > option works. Example passes with -Xint option as well. (Tested with >> > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) >> > >> > I saw #7160161 marked as resolved, so I just wanted to confirm if behavior >> > we see really relates to this issue and it was fixed (bug report covers >> > non-Counted loop only). >> > >> > Also, is there any other workarounds rather then extracting the method and >> > specifying FreqInlineSize=0? >> > >> > Thanks, >> > Alexey Goncharuk >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/3de17af0/attachment.html From volker.simonis at gmail.com Fri Nov 30 12:28:23 2012 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 30 Nov 2012 21:28:23 +0100 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: Message-ID: Hi Vitaly, you're right, even a STW GC will have to wait until this loop without a safepoint will finish. On the other side, if there is an allocation inside the loop, the allocation will be done on the "fast path" (without safepoint check) only until the thread local buffer (TLAB) will be full. After that it will have to take the "slow path" which is a VM call and which has a safe point check. So in practice I think the problem is only with very tight loops which do same small but expensive computations (or with nested int loops which have potentially the same complexity like long loops but no safpoint either). Regards, Volker On Friday, November 30, 2012, Vitaly Davidovich wrote: > Hi Volker, > > Just curious - what happens if a STW GC needs to occur right as this type > of loop is entered? Does the VM just stall until the loop exits? What if > this loop does a fast path allocation on some iteration? Do all allocations > check for safepoints internally? > > Thanks > > Sent from my phone > On Nov 30, 2012 1:41 PM, "Volker Simonis" > > wrote: > >> Hi, >> >> This is a long standing problem of HotSpot (compared for example to >> J9). It doesn't put Safepoints into counted int loops (because it >> assumes they will terminate just "fast enough" which is not the case >> in your example). You can see another example for this behavior in >> these slides "http://www.progdoc.de/papers/Jax2012/jax2012.html#%288%29" >> together with the generated assembler code. >> >> You can easily solve the problem by making your loop variable a "long" >> instead of an "int". In that case, HotSpot will be more cautious and >> place a safepoint into the loop. >> >> Regards, >> Volker >> >> On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk >> > 'agoncharuk at gridgain.com');>> wrote: >> > Hi, >> > >> > We faced some weird issue with thread scheduling. At a first glance it >> > looked like it relates to >> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not >> exactly. >> > >> > This is the code we ran: >> > >> > public static void main(String[] args) throws Exception { Thread worker >> = >> > new Thread() { @Override public void run() { double d = 0; for (int j = >> 1; j >> > < 2000000000; j++) d += Math.log(Math.E * j); System.out.println(d); } >> }; >> > Thread reporter = new Thread() { @Override public void run() { try { >> while >> > (true) { Thread.sleep(1000); System.out.println("Running: " + >> > System.currentTimeMillis()); } } catch (InterruptedException ignored) { >> > Thread.currentThread().interrupt(); } } }; reporter.start(); >> worker.start(); >> > worker.join(); reporter.interrupt(); } >> > >> > One can expect that printing thread would output messages during all the >> > calculation time, however it hangs after 3-4 iterations. Setting >> > -XX:FreqInlineSize=0 as described in original bug report does not help >> in >> > this case, but if I extract loop body into a separate method, setting >> this >> > option works. Example passes with -Xint option as well. (Tested with >> > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) >> > >> > I saw #7160161 marked as resolved, so I just wanted to confirm if >> behavior >> > we see really relates to this issue and it was fixed (bug report covers >> > non-Counted loop only). >> > >> > Also, is there any other workarounds rather then extracting the method >> and >> > specifying FreqInlineSize=0? >> > >> > Thanks, >> > Alexey Goncharuk >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/d171e758/attachment.html From volker.simonis at gmail.com Fri Nov 30 12:33:52 2012 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 30 Nov 2012 21:33:52 +0100 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: <07858065-883B-4566-AEDE-D5752279EC02@kodewerk.com> References: <00B03FFD-AB48-425C-ABFD-04A8335CAB1B@kodewerk.com> <07858065-883B-4566-AEDE-D5752279EC02@kodewerk.com> Message-ID: Hi Kirk, I can not confirm this. I've done quite some experiments with such a kind of scenario and it is true that the VM will not react on Control-C, but I could always kill the VM with kill -9. Maybe you are using a strange operating system:) On Friday, November 30, 2012, Kirk Pepperdine wrote: > Nope.. not the problem. GC calls for a safe point and all the thread > 'cept one obey (guess which one!!!). This make the VM completely > unresponsive to any signals. Strangely enough it's also apparently > resistant to kill -9.. and since it's burning through CPU.... > > -- Kirk > > On 2012-11-30, at 8:49 PM, Vitaly Davidovich > > wrote: > > Haha :) > > So it blows through Xmx, ram, and starts swapping like crazy? > > Sent from my phone > On Nov 30, 2012 2:42 PM, "Kirk Pepperdine" > > wrote: > >> We have an app that in one threads creates objects and never releases >> them and then in another, does a calculation in a tight loop. I would >> suggest if you try this you first save everything that you want to keep >> because when this app is run... the only way to recover is to reboot your >> computer. >> >> It's fun!!!! >> >> -- Kirk >> >> On 2012-11-30, at 8:36 PM, Vitaly Davidovich > >> wrote: >> >> Hi Volker, >> >> Just curious - what happens if a STW GC needs to occur right as this type >> of loop is entered? Does the VM just stall until the loop exits? What if >> this loop does a fast path allocation on some iteration? Do all allocations >> check for safepoints internally? >> >> Thanks >> >> Sent from my phone >> On Nov 30, 2012 1:41 PM, "Volker Simonis" > >> wrote: >> >>> Hi, >>> >>> This is a long standing problem of HotSpot (compared for example to >>> J9). It doesn't put Safepoints into counted int loops (because it >>> assumes they will terminate just "fast enough" which is not the case >>> in your example). You can see another example for this behavior in >>> these slides "http://www.progdoc.de/papers/Jax2012/jax2012.html#%288%29" >>> together with the generated assembler code. >>> >>> You can easily solve the problem by making your loop variable a "long" >>> instead of an "int". In that case, HotSpot will be more cautious and >>> place a safepoint into the loop. >>> >>> Regards, >>> Volker >>> >>> On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk >>> >> 'agoncharuk at gridgain.com');>> wrote: >>> > Hi, >>> > >>> > We faced some weird issue with thread scheduling. At a first glance it >>> > looked like it relates to >>> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not >>> exactly. >>> > >>> > This is the code we ran: >>> > >>> > public static void main(String[] args) throws Exception { Thread >>> worker = >>> > new Thread() { @Override public void run() { double d = 0; for (int j >>> = 1; j >>> > < 2000000000; j++) d += Math.log(Math.E * j); System.out.println(d); } >>> }; >>> > Thread reporter = new Thread() { @Override public void run() { try { >>> while >>> > (true) { Thread.sleep(1000); System.out.println("Running: " + >>> > System.currentTimeMillis()); } } catch (InterruptedException ignored) { >>> > Thread.currentThread().interrupt(); } } }; reporter.start(); >>> worker.start(); >>> > worker.join(); reporter.interrupt(); } >>> > >>> > One can expect that printing thread would output messages during all >>> the >>> > calculation time, however it hangs after 3-4 iterations. Setting >>> > -XX:FreqInlineSize=0 as described in original bug report does not help >>> in >>> > this case, but if I extract loop body into a separate method, setting >>> this >>> > option works. Example passes with -Xint option as well. (Tested with >>> > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) >>> > >>> > I saw #7160161 marked as resolved, so I just wanted to confirm if >>> behavior >>> > we see really relates to this issue and it was fixed (bug report covers >>> > non-Counted loop only). >>> > >>> > Also, is there any other workarounds rather then extracting the method >>> and >>> > specifying FreqInlineSize=0? >>> > >>> > Thanks, >>> > Alexey Goncharuk >>> > >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/783a36b7/attachment-0001.html From kirk at kodewerk.com Fri Nov 30 12:36:13 2012 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Fri, 30 Nov 2012 21:36:13 +0100 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: <00B03FFD-AB48-425C-ABFD-04A8335CAB1B@kodewerk.com> <07858065-883B-4566-AEDE-D5752279EC02@kodewerk.com> Message-ID: <7398CDB5-55A0-41E9-B4E9-0D9B21CD963B@kodewerk.com> OSX, didn't try on Linux On 2012-11-30, at 9:33 PM, Volker Simonis wrote: > Hi Kirk, > > I can not confirm this. I've done quite some experiments with such a kind of scenario and it is true that the VM will not react on Control-C, but I could always kill the VM with kill -9. Maybe you are using a strange operating system:) > > > On Friday, November 30, 2012, Kirk Pepperdine wrote: > Nope.. not the problem. GC calls for a safe point and all the thread 'cept one obey (guess which one!!!). This make the VM completely unresponsive to any signals. Strangely enough it's also apparently resistant to kill -9.. and since it's burning through CPU.... > > -- Kirk > > On 2012-11-30, at 8:49 PM, Vitaly Davidovich wrote: > >> Haha :) >> >> So it blows through Xmx, ram, and starts swapping like crazy? >> >> Sent from my phone >> >> On Nov 30, 2012 2:42 PM, "Kirk Pepperdine" wrote: >> We have an app that in one threads creates objects and never releases them and then in another, does a calculation in a tight loop. I would suggest if you try this you first save everything that you want to keep because when this app is run... the only way to recover is to reboot your computer. >> >> It's fun!!!! >> >> -- Kirk >> >> On 2012-11-30, at 8:36 PM, Vitaly Davidovich wrote: >> >>> Hi Volker, >>> >>> Just curious - what happens if a STW GC needs to occur right as this type of loop is entered? Does the VM just stall until the loop exits? What if this loop does a fast path allocation on some iteration? Do all allocations check for safepoints internally? >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Nov 30, 2012 1:41 PM, "Volker Simonis" wrote: >>> Hi, >>> >>> This is a long standing problem of HotSpot (compared for example to >>> J9). It doesn't put Safepoints into counted int loops (because it >>> assumes they will terminate just "fast enough" which is not the case >>> in your example). You can see another example for this behavior in >>> these slides "http://www.progdoc.de/papers/Jax2012/jax2012.html#%288%29" >>> together with the generated assembler code. >>> >>> You can easily solve the problem by making your loop variable a "long" >>> instead of an "int". In that case, HotSpot will be more cautious and >>> place a safepoint into the loop. >>> >>> Regards, >>> Volker >>> >>> On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk >>> wrote: >>> > Hi, >>> > >>> > We faced some weird issue with thread scheduling. At a first glance it >>> > looked like it relates to >>> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not exactly. >>> > >>> > This is the code we ran: >>> > >>> > public static void main(String[] args) throws Exception { Thread worker = >>> > new Thread() { @Override public void run() { double d = 0; for (int j = 1; j >>> > < 2000000000; j++) d += Math.log(Math.E * j); System.out.println(d); } }; >>> > Thread reporter = new Thread() { @Override public void run() { try { while >>> > (true) { Thread.sleep(1000); System.out.println("Running: " + >>> > System.currentTimeMillis()); } } catch (InterruptedException ignored) { >>> > Thread.currentThread().interrupt(); } } }; reporter.start(); worker.start(); >>> > worker.join(); reporter.interrupt(); } >>> > >>> > One can expect that printing thread would output messages during all the >>> > calculation time, however it hangs after 3-4 iterations. Setting >>> > -XX:FreqInlineSize=0 as described in original bug report does not help in >>> > this case, but if I extract loop body into a separate method, setting this >>> > option works. Example passes with -Xint option as well. (Tested with >>> > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) >>> > >>> > I saw #7160161 marked as resolved, so I just wanted to confirm if behavior >>> > we see really relates to this issue and it was fixed (bug report covers >>> > non-Counted loop only). >>> > >>> > Also, is there any other workarounds rather then extracting the method and >>> > specifying FreqInlineSize=0? >>> > >>> > Thanks, >>> > Alexey Goncharuk >>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/17f3f40e/attachment.html From vitalyd at gmail.com Fri Nov 30 12:44:10 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 15:44:10 -0500 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: Message-ID: Ah, good point about TLAB filling up and slow path ensuing. Thanks for the insight. Sent from my phone On Nov 30, 2012 3:28 PM, "Volker Simonis" wrote: > Hi Vitaly, > > you're right, even a STW GC will have to wait until this loop without a > safepoint will finish. On the other side, if there is an allocation inside > the loop, the allocation will be done on the "fast path" (without safepoint > check) only until the thread local buffer (TLAB) will be full. After that > it will have to take the "slow path" which is a VM call and which has a > safe point check. So in practice I think the problem is only with very > tight loops which do same small but expensive computations (or with nested > int loops which have potentially the same complexity like long loops but no > safpoint either). > > Regards, > Volker > > On Friday, November 30, 2012, Vitaly Davidovich wrote: > >> Hi Volker, >> >> Just curious - what happens if a STW GC needs to occur right as this type >> of loop is entered? Does the VM just stall until the loop exits? What if >> this loop does a fast path allocation on some iteration? Do all allocations >> check for safepoints internally? >> >> Thanks >> >> Sent from my phone >> On Nov 30, 2012 1:41 PM, "Volker Simonis" >> wrote: >> >>> Hi, >>> >>> This is a long standing problem of HotSpot (compared for example to >>> J9). It doesn't put Safepoints into counted int loops (because it >>> assumes they will terminate just "fast enough" which is not the case >>> in your example). You can see another example for this behavior in >>> these slides "http://www.progdoc.de/papers/Jax2012/jax2012.html#%288%29" >>> together with the generated assembler code. >>> >>> You can easily solve the problem by making your loop variable a "long" >>> instead of an "int". In that case, HotSpot will be more cautious and >>> place a safepoint into the loop. >>> >>> Regards, >>> Volker >>> >>> On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk >>> wrote: >>> > Hi, >>> > >>> > We faced some weird issue with thread scheduling. At a first glance it >>> > looked like it relates to >>> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not >>> exactly. >>> > >>> > This is the code we ran: >>> > >>> > public static void main(String[] args) throws Exception { Thread >>> worker = >>> > new Thread() { @Override public void run() { double d = 0; for (int j >>> = 1; j >>> > < 2000000000; j++) d += Math.log(Math.E * j); System.out.println(d); } >>> }; >>> > Thread reporter = new Thread() { @Override public void run() { try { >>> while >>> > (true) { Thread.sleep(1000); System.out.println("Running: " + >>> > System.currentTimeMillis()); } } catch (InterruptedException ignored) { >>> > Thread.currentThread().interrupt(); } } }; reporter.start(); >>> worker.start(); >>> > worker.join(); reporter.interrupt(); } >>> > >>> > One can expect that printing thread would output messages during all >>> the >>> > calculation time, however it hangs after 3-4 iterations. Setting >>> > -XX:FreqInlineSize=0 as described in original bug report does not help >>> in >>> > this case, but if I extract loop body into a separate method, setting >>> this >>> > option works. Example passes with -Xint option as well. (Tested with >>> > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) >>> > >>> > I saw #7160161 marked as resolved, so I just wanted to confirm if >>> behavior >>> > we see really relates to this issue and it was fixed (bug report covers >>> > non-Counted loop only). >>> > >>> > Also, is there any other workarounds rather then extracting the method >>> and >>> > specifying FreqInlineSize=0? >>> > >>> > Thanks, >>> > Alexey Goncharuk >>> > >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/8a123740/attachment.html From vitalyd at gmail.com Fri Nov 30 12:45:24 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 15:45:24 -0500 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: <00B03FFD-AB48-425C-ABFD-04A8335CAB1B@kodewerk.com> <07858065-883B-4566-AEDE-D5752279EC02@kodewerk.com> Message-ID: Right, I'd also think the OS could kill it hence I thought the machine became unusable due to heavy swapping. Sent from my phone On Nov 30, 2012 3:33 PM, "Volker Simonis" wrote: > Hi Kirk, > > I can not confirm this. I've done quite some experiments with such a kind > of scenario and it is true that the VM will not react on Control-C, but I > could always kill the VM with kill -9. Maybe you are using a strange > operating system:) > > > On Friday, November 30, 2012, Kirk Pepperdine wrote: > >> Nope.. not the problem. GC calls for a safe point and all the thread >> 'cept one obey (guess which one!!!). This make the VM completely >> unresponsive to any signals. Strangely enough it's also apparently >> resistant to kill -9.. and since it's burning through CPU.... >> >> -- Kirk >> >> On 2012-11-30, at 8:49 PM, Vitaly Davidovich wrote: >> >> Haha :) >> >> So it blows through Xmx, ram, and starts swapping like crazy? >> >> Sent from my phone >> On Nov 30, 2012 2:42 PM, "Kirk Pepperdine" wrote: >> >>> We have an app that in one threads creates objects and never releases >>> them and then in another, does a calculation in a tight loop. I would >>> suggest if you try this you first save everything that you want to keep >>> because when this app is run... the only way to recover is to reboot your >>> computer. >>> >>> It's fun!!!! >>> >>> -- Kirk >>> >>> On 2012-11-30, at 8:36 PM, Vitaly Davidovich wrote: >>> >>> Hi Volker, >>> >>> Just curious - what happens if a STW GC needs to occur right as this >>> type of loop is entered? Does the VM just stall until the loop exits? What >>> if this loop does a fast path allocation on some iteration? Do all >>> allocations check for safepoints internally? >>> >>> Thanks >>> >>> Sent from my phone >>> On Nov 30, 2012 1:41 PM, "Volker Simonis" >>> wrote: >>> >>>> Hi, >>>> >>>> This is a long standing problem of HotSpot (compared for example to >>>> J9). It doesn't put Safepoints into counted int loops (because it >>>> assumes they will terminate just "fast enough" which is not the case >>>> in your example). You can see another example for this behavior in >>>> these slides "http://www.progdoc.de/papers/Jax2012/jax2012.html#%288%29 >>>> " >>>> together with the generated assembler code. >>>> >>>> You can easily solve the problem by making your loop variable a "long" >>>> instead of an "int". In that case, HotSpot will be more cautious and >>>> place a safepoint into the loop. >>>> >>>> Regards, >>>> Volker >>>> >>>> On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk >>>> wrote: >>>> > Hi, >>>> > >>>> > We faced some weird issue with thread scheduling. At a first glance it >>>> > looked like it relates to >>>> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not >>>> exactly. >>>> > >>>> > This is the code we ran: >>>> > >>>> > public static void main(String[] args) throws Exception { Thread >>>> worker = >>>> > new Thread() { @Override public void run() { double d = 0; for (int j >>>> = 1; j >>>> > < 2000000000; j++) d += Math.log(Math.E * j); System.out.println(d); >>>> } }; >>>> > Thread reporter = new Thread() { @Override public void run() { try { >>>> while >>>> > (true) { Thread.sleep(1000); System.out.println("Running: " + >>>> > System.currentTimeMillis()); } } catch (InterruptedException ignored) >>>> { >>>> > Thread.currentThread().interrupt(); } } }; reporter.start(); >>>> worker.start(); >>>> > worker.join(); reporter.interrupt(); } >>>> > >>>> > One can expect that printing thread would output messages during all >>>> the >>>> > calculation time, however it hangs after 3-4 iterations. Setting >>>> > -XX:FreqInlineSize=0 as described in original bug report does not >>>> help in >>>> > this case, but if I extract loop body into a separate method, setting >>>> this >>>> > option works. Example passes with -Xint option as well. (Tested with >>>> > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) >>>> > >>>> > I saw #7160161 marked as resolved, so I just wanted to confirm if >>>> behavior >>>> > we see really relates to this issue and it was fixed (bug report >>>> covers >>>> > non-Counted loop only). >>>> > >>>> > Also, is there any other workarounds rather then extracting the >>>> method and >>>> > specifying FreqInlineSize=0? >>>> > >>>> > Thanks, >>>> > Alexey Goncharuk >>>> > >>>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/b1fe02a5/attachment-0001.html From vitalyd at gmail.com Fri Nov 30 12:51:35 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 15:51:35 -0500 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: Message-ID: By the way, what would a fix involve? Polling for safepoint every X trips through the loop where X is some reasonable value and then overridable via a JVM arg? I guess otherwise the JVM would have to know/estimate the cost of the loop body, which seems intractable in general. What does J9 do? Does it simply not strip out polling? Thanks Sent from my phone On Nov 30, 2012 3:28 PM, "Volker Simonis" wrote: > Hi Vitaly, > > you're right, even a STW GC will have to wait until this loop without a > safepoint will finish. On the other side, if there is an allocation inside > the loop, the allocation will be done on the "fast path" (without safepoint > check) only until the thread local buffer (TLAB) will be full. After that > it will have to take the "slow path" which is a VM call and which has a > safe point check. So in practice I think the problem is only with very > tight loops which do same small but expensive computations (or with nested > int loops which have potentially the same complexity like long loops but no > safpoint either). > > Regards, > Volker > > On Friday, November 30, 2012, Vitaly Davidovich wrote: > >> Hi Volker, >> >> Just curious - what happens if a STW GC needs to occur right as this type >> of loop is entered? Does the VM just stall until the loop exits? What if >> this loop does a fast path allocation on some iteration? Do all allocations >> check for safepoints internally? >> >> Thanks >> >> Sent from my phone >> On Nov 30, 2012 1:41 PM, "Volker Simonis" >> wrote: >> >>> Hi, >>> >>> This is a long standing problem of HotSpot (compared for example to >>> J9). It doesn't put Safepoints into counted int loops (because it >>> assumes they will terminate just "fast enough" which is not the case >>> in your example). You can see another example for this behavior in >>> these slides "http://www.progdoc.de/papers/Jax2012/jax2012.html#%288%29" >>> together with the generated assembler code. >>> >>> You can easily solve the problem by making your loop variable a "long" >>> instead of an "int". In that case, HotSpot will be more cautious and >>> place a safepoint into the loop. >>> >>> Regards, >>> Volker >>> >>> On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk >>> wrote: >>> > Hi, >>> > >>> > We faced some weird issue with thread scheduling. At a first glance it >>> > looked like it relates to >>> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not >>> exactly. >>> > >>> > This is the code we ran: >>> > >>> > public static void main(String[] args) throws Exception { Thread >>> worker = >>> > new Thread() { @Override public void run() { double d = 0; for (int j >>> = 1; j >>> > < 2000000000; j++) d += Math.log(Math.E * j); System.out.println(d); } >>> }; >>> > Thread reporter = new Thread() { @Override public void run() { try { >>> while >>> > (true) { Thread.sleep(1000); System.out.println("Running: " + >>> > System.currentTimeMillis()); } } catch (InterruptedException ignored) { >>> > Thread.currentThread().interrupt(); } } }; reporter.start(); >>> worker.start(); >>> > worker.join(); reporter.interrupt(); } >>> > >>> > One can expect that printing thread would output messages during all >>> the >>> > calculation time, however it hangs after 3-4 iterations. Setting >>> > -XX:FreqInlineSize=0 as described in original bug report does not help >>> in >>> > this case, but if I extract loop body into a separate method, setting >>> this >>> > option works. Example passes with -Xint option as well. (Tested with >>> > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) >>> > >>> > I saw #7160161 marked as resolved, so I just wanted to confirm if >>> behavior >>> > we see really relates to this issue and it was fixed (bug report covers >>> > non-Counted loop only). >>> > >>> > Also, is there any other workarounds rather then extracting the method >>> and >>> > specifying FreqInlineSize=0? >>> > >>> > Thanks, >>> > Alexey Goncharuk >>> > >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/ac2e9249/attachment.html From Vladimir.Kozlov at oracle.com Fri Nov 30 15:01:13 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Nov 2012 15:01:13 -0800 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: Message-ID: <50B93AB9.4020405@oracle.com> Alexey, Flag -XX:+TraceSafepoint (with debug VM) shows that a safepoint is initiated at that time: Running: 1354316016260 Running: 1354316017270 Running: 1354316018280 Safepoint synchronization initiated. (8) Waiting for 1 thread(s) to block Entering safepoint region: EnableBiasedLocking Leaving safepoint region Running: 1354316065524 And because counted loops does not have safepoint instruction it waits until worker thread is finished. We have RFE to keep safepoint in counted loops for such cases but I can't say when it will be done: 6869327: Add new C2 flag to keep safepoints in counted loops. The workaround for your case is to switch off biased locking: -XX:-UseBiasedLocking But it will not help in case of GC safepoint (heap collection event). Regards, Vladimir On 11/30/12 05:05, Alexey Goncharuk wrote: > Hi, > > We faced some weird issue with thread scheduling. At a first glance it > looked like it relates to > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 but not exactly. > > This is the code we ran: > > public static void main(String[] args) throws Exception { Thread worker > = new Thread() { @Override public void run() { double d = 0; for (int j > = 1; j < 2000000000; j++) d += Math.log(Math.E * j); > System.out.println(d); } }; Thread reporter = new Thread() { @Override > public void run() { try { while (true) { Thread.sleep(1000); > System.out.println("Running: " + System.currentTimeMillis()); } } catch > (InterruptedException ignored) { Thread.currentThread().interrupt(); } } > }; reporter.start(); worker.start(); worker.join(); reporter.interrupt(); } > > One can expect that printing thread would output messages during all the > calculation time, however it hangs after 3-4 iterations. Setting > -XX:FreqInlineSize=0 as described in original bug report does not help > in this case, but if I extract loop body into a separate method, setting > this option works. Example passes with -Xint option as well. (Tested > with 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on Linux) > > I saw #7160161 marked as resolved, so I just wanted to confirm if > behavior we see really relates to this issue and it was fixed (bug > report covers non-Counted loop only). > > Also, is there any other workarounds rather then extracting the method > and specifying FreqInlineSize=0? > > Thanks, > Alexey Goncharuk > From christian.thalinger at oracle.com Fri Nov 30 15:10:29 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Fri, 30 Nov 2012 23:10:29 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8003195: AbstractAssembler should not store code pointers but use the CodeSection directly Message-ID: <20121130231031.9829847C4F@hg.openjdk.java.net> Changeset: 6ab62ad83507 Author: twisti Date: 2012-11-30 11:44 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/6ab62ad83507 8003195: AbstractAssembler should not store code pointers but use the CodeSection directly Reviewed-by: twisti, kvn Contributed-by: Bharadwaj Yadavalli ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/assembler.inline.hpp ! src/share/vm/asm/codeBuffer.hpp From christian.thalinger at oracle.com Fri Nov 30 15:20:05 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 30 Nov 2012 15:20:05 -0800 Subject: RFR (XXL): 8003240: x86: move MacroAssembler into a separate file In-Reply-To: <50B6EC12.9070105@oracle.com> References: <2EE7968E-1E69-4EFF-BB37-283219CCC363@oracle.com> <50B6EC12.9070105@oracle.com> Message-ID: <55B6366C-5BA0-4B12-8FAF-9A12241BC517@oracle.com> Thank you, Vladimir. I merged with Bharadwaj's latest changeset and updated the webrev. There are only trivial differences so I'm going to push this now. -- Chris On Nov 28, 2012, at 9:01 PM, Vladimir Kozlov wrote: > Looks good to me. > > Thanks, > Vladimir > > On 11/28/12 17:02, Christian Thalinger wrote: >> [Prologue: The patch is classified as XXL but in fact it's not so bad. The biggest changes are a verbatim move from assembler_x86.{cpp,hpp} into macroAssembler_x86.{cpp,hpp}. The rest is adjustments of includes to make everything work. I also took the liberty to clean up some stuff.] >> >> http://cr.openjdk.java.net/~twisti/8003240/ >> >> 8003240: x86: move MacroAssembler into a separate file >> Reviewed-by: >> >> The assembler_.{cpp,hpp} files are already very big and we should split them into two files: >> >> assembler_.{cpp,hpp} >> macroAssembler_.{cpp,hpp} >> >> This is for x86. >> >> src/share/vm/asm/macroAssembler.hpp >> src/share/vm/asm/macroAssembler.inline.hpp >> src/cpu/x86/vm/assembler_x86.cpp >> src/cpu/x86/vm/macroAssembler_x86.cpp >> src/cpu/x86/vm/assembler_x86.hpp >> src/cpu/x86/vm/macroAssembler_x86.hpp >> src/cpu/x86/vm/assembler_x86.inline.hpp >> src/cpu/sparc/vm/assembler_sparc.cpp >> src/cpu/sparc/vm/codeBuffer_sparc.hpp >> src/cpu/sparc/vm/frame_sparc.hpp >> src/cpu/sparc/vm/frame_sparc.inline.hpp >> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >> src/cpu/x86/vm/cppInterpreter_x86.cpp >> src/cpu/x86/vm/frame_x86.inline.hpp >> src/cpu/x86/vm/icache_x86.cpp >> src/cpu/x86/vm/icBuffer_x86.cpp >> src/cpu/x86/vm/interp_masm_x86_32.hpp >> src/cpu/x86/vm/interp_masm_x86_64.hpp >> src/cpu/x86/vm/interpreter_x86_32.cpp >> src/cpu/x86/vm/interpreter_x86_64.cpp >> src/cpu/x86/vm/jniFastGetField_x86_32.cpp >> src/cpu/x86/vm/jniFastGetField_x86_64.cpp >> src/cpu/x86/vm/metaspaceShared_x86_32.cpp >> src/cpu/x86/vm/metaspaceShared_x86_64.cpp >> src/cpu/x86/vm/methodHandles_x86.cpp >> src/cpu/x86/vm/nativeInst_x86.cpp >> src/cpu/x86/vm/relocInfo_x86.cpp >> src/cpu/x86/vm/runtime_x86_32.cpp >> src/cpu/x86/vm/runtime_x86_64.cpp >> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >> src/cpu/x86/vm/stubGenerator_x86_32.cpp >> src/cpu/x86/vm/stubGenerator_x86_64.cpp >> src/cpu/x86/vm/templateInterpreter_x86_32.cpp >> src/cpu/x86/vm/templateInterpreter_x86_64.cpp >> src/cpu/x86/vm/templateTable_x86_32.cpp >> src/cpu/x86/vm/templateTable_x86_64.cpp >> src/cpu/x86/vm/vm_version_x86.cpp >> src/cpu/x86/vm/vtableStubs_x86_32.cpp >> src/cpu/x86/vm/vtableStubs_x86_64.cpp >> src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp >> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >> src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp >> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >> src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp >> src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp >> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >> src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp >> src/os_cpu/windows_x86/vm/os_windows_x86.cpp >> src/os/bsd/vm/os_bsd.cpp >> src/os/bsd/vm/os_bsd.inline.hpp >> src/os/bsd/vm/osThread_bsd.cpp >> src/os/linux/vm/os_linux.cpp >> src/os/linux/vm/os_linux.inline.hpp >> src/os/linux/vm/osThread_linux.cpp >> src/os/solaris/vm/os_solaris.cpp >> src/os/solaris/vm/os_solaris.inline.hpp >> src/os/solaris/vm/osThread_solaris.cpp >> src/os/windows/vm/os_windows.cpp >> src/os/windows/vm/os_windows.inline.hpp >> src/os/windows/vm/osThread_windows.cpp >> src/share/vm/asm/assembler.cpp >> src/share/vm/asm/assembler.hpp >> src/share/vm/asm/assembler.inline.hpp >> src/share/vm/asm/codeBuffer.cpp >> src/share/vm/asm/codeBuffer.hpp >> src/share/vm/c1/c1_MacroAssembler.hpp >> src/share/vm/code/icBuffer.cpp >> src/share/vm/code/relocInfo.cpp >> src/share/vm/interpreter/interpreter.cpp >> src/share/vm/interpreter/interpreterRuntime.cpp >> src/share/vm/opto/compile.cpp >> src/share/vm/runtime/atomic.cpp >> src/share/vm/runtime/atomic.hpp >> src/share/vm/runtime/atomic.inline.hpp >> src/share/vm/runtime/frame.cpp >> src/share/vm/runtime/frame.hpp >> src/share/vm/runtime/sharedRuntime.cpp >> src/share/vm/runtime/stubCodeGenerator.cpp >> From Vladimir.Kozlov at oracle.com Fri Nov 30 15:18:59 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Nov 2012 15:18:59 -0800 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: Message-ID: <50B93EE3.2080208@oracle.com> On 11/30/12 12:51, Vitaly Davidovich wrote: > By the way, what would a fix involve? Polling for safepoint every X > trips through the loop where X is some reasonable value and then > overridable via a JVM arg? I guess otherwise the JVM would have to > know/estimate the cost of the loop body, which seems intractable in general. An other approach is "mine stripping" - split a loop into inner and outer loops. Polling not on each iteration requires test and branch which could be more expensive than load with unused result. Current plan (6869327) is simple to keep safepoint in counted loop when the flag is specified. Vladimir > > What does J9 do? Does it simply not strip out polling? > > Thanks > > Sent from my phone > > On Nov 30, 2012 3:28 PM, "Volker Simonis" > wrote: > > Hi Vitaly, > > you're right, even a STW GC will have to wait until this loop > without a safepoint will finish. On the other side, if there is an > allocation inside the loop, the allocation will be done on the "fast > path" (without safepoint check) only until the thread local buffer > (TLAB) will be full. After that it will have to take the "slow path" > which is a VM call and which has a safe point check. So in practice > I think the problem is only with very tight loops which do same > small but expensive computations (or with nested int loops which > have potentially the same complexity like long loops but no safpoint > either). > > Regards, > Volker > > On Friday, November 30, 2012, Vitaly Davidovich wrote: > > Hi Volker, > > Just curious - what happens if a STW GC needs to occur right as > this type of loop is entered? Does the VM just stall until the > loop exits? What if this loop does a fast path allocation on > some iteration? Do all allocations check for safepoints internally? > > Thanks > > Sent from my phone > > On Nov 30, 2012 1:41 PM, "Volker Simonis" > wrote: > > Hi, > > This is a long standing problem of HotSpot (compared for > example to > J9). It doesn't put Safepoints into counted int loops > (because it > assumes they will terminate just "fast enough" which is not > the case > in your example). You can see another example for this > behavior in > these slides > "http://www.progdoc.de/papers/Jax2012/jax2012.html#%288%29" > together with the generated assembler code. > > You can easily solve the problem by making your loop > variable a "long" > instead of an "int". In that case, HotSpot will be more > cautious and > place a safepoint into the loop. > > Regards, > Volker > > On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk > wrote: > > Hi, > > > > We faced some weird issue with thread scheduling. At a > first glance it > > looked like it relates to > > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7160161 > but not exactly. > > > > This is the code we ran: > > > > public static void main(String[] args) throws Exception { > Thread worker = > > new Thread() { @Override public void run() { double d = > 0; for (int j = 1; j > > < 2000000000; j++) d += Math.log(Math.E * j); > System.out.println(d); } }; > > Thread reporter = new Thread() { @Override public void > run() { try { while > > (true) { Thread.sleep(1000); System.out.println("Running: " + > > System.currentTimeMillis()); } } catch > (InterruptedException ignored) { > > Thread.currentThread().interrupt(); } } }; > reporter.start(); worker.start(); > > worker.join(); reporter.interrupt(); } > > > > One can expect that printing thread would output messages > during all the > > calculation time, however it hangs after 3-4 iterations. > Setting > > -XX:FreqInlineSize=0 as described in original bug report > does not help in > > this case, but if I extract loop body into a separate > method, setting this > > option works. Example passes with -Xint option as well. > (Tested with > > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on > Linux) > > > > I saw #7160161 marked as resolved, so I just wanted to > confirm if behavior > > we see really relates to this issue and it was fixed (bug > report covers > > non-Counted loop only). > > > > Also, is there any other workarounds rather then > extracting the method and > > specifying FreqInlineSize=0? > > > > Thanks, > > Alexey Goncharuk > > > From Vladimir.Kozlov at oracle.com Fri Nov 30 15:28:30 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Nov 2012 15:28:30 -0800 Subject: RFR (XXL): 8003240: x86: move MacroAssembler into a separate file In-Reply-To: <55B6366C-5BA0-4B12-8FAF-9A12241BC517@oracle.com> References: <2EE7968E-1E69-4EFF-BB37-283219CCC363@oracle.com> <50B6EC12.9070105@oracle.com> <55B6366C-5BA0-4B12-8FAF-9A12241BC517@oracle.com> Message-ID: <50B9411E.1030103@oracle.com> OK. Vladimir On 11/30/12 15:20, Christian Thalinger wrote: > Thank you, Vladimir. I merged with Bharadwaj's latest changeset and updated the webrev. There are only trivial differences so I'm going to push this now. > > -- Chris > > On Nov 28, 2012, at 9:01 PM, Vladimir Kozlov wrote: > >> Looks good to me. >> >> Thanks, >> Vladimir >> >> On 11/28/12 17:02, Christian Thalinger wrote: >>> [Prologue: The patch is classified as XXL but in fact it's not so bad. The biggest changes are a verbatim move from assembler_x86.{cpp,hpp} into macroAssembler_x86.{cpp,hpp}. The rest is adjustments of includes to make everything work. I also took the liberty to clean up some stuff.] >>> >>> http://cr.openjdk.java.net/~twisti/8003240/ >>> >>> 8003240: x86: move MacroAssembler into a separate file >>> Reviewed-by: >>> >>> The assembler_.{cpp,hpp} files are already very big and we should split them into two files: >>> >>> assembler_.{cpp,hpp} >>> macroAssembler_.{cpp,hpp} >>> >>> This is for x86. >>> >>> src/share/vm/asm/macroAssembler.hpp >>> src/share/vm/asm/macroAssembler.inline.hpp >>> src/cpu/x86/vm/assembler_x86.cpp >>> src/cpu/x86/vm/macroAssembler_x86.cpp >>> src/cpu/x86/vm/assembler_x86.hpp >>> src/cpu/x86/vm/macroAssembler_x86.hpp >>> src/cpu/x86/vm/assembler_x86.inline.hpp >>> src/cpu/sparc/vm/assembler_sparc.cpp >>> src/cpu/sparc/vm/codeBuffer_sparc.hpp >>> src/cpu/sparc/vm/frame_sparc.hpp >>> src/cpu/sparc/vm/frame_sparc.inline.hpp >>> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >>> src/cpu/x86/vm/cppInterpreter_x86.cpp >>> src/cpu/x86/vm/frame_x86.inline.hpp >>> src/cpu/x86/vm/icache_x86.cpp >>> src/cpu/x86/vm/icBuffer_x86.cpp >>> src/cpu/x86/vm/interp_masm_x86_32.hpp >>> src/cpu/x86/vm/interp_masm_x86_64.hpp >>> src/cpu/x86/vm/interpreter_x86_32.cpp >>> src/cpu/x86/vm/interpreter_x86_64.cpp >>> src/cpu/x86/vm/jniFastGetField_x86_32.cpp >>> src/cpu/x86/vm/jniFastGetField_x86_64.cpp >>> src/cpu/x86/vm/metaspaceShared_x86_32.cpp >>> src/cpu/x86/vm/metaspaceShared_x86_64.cpp >>> src/cpu/x86/vm/methodHandles_x86.cpp >>> src/cpu/x86/vm/nativeInst_x86.cpp >>> src/cpu/x86/vm/relocInfo_x86.cpp >>> src/cpu/x86/vm/runtime_x86_32.cpp >>> src/cpu/x86/vm/runtime_x86_64.cpp >>> src/cpu/x86/vm/sharedRuntime_x86_32.cpp >>> src/cpu/x86/vm/sharedRuntime_x86_64.cpp >>> src/cpu/x86/vm/stubGenerator_x86_32.cpp >>> src/cpu/x86/vm/stubGenerator_x86_64.cpp >>> src/cpu/x86/vm/templateInterpreter_x86_32.cpp >>> src/cpu/x86/vm/templateInterpreter_x86_64.cpp >>> src/cpu/x86/vm/templateTable_x86_32.cpp >>> src/cpu/x86/vm/templateTable_x86_64.cpp >>> src/cpu/x86/vm/vm_version_x86.cpp >>> src/cpu/x86/vm/vtableStubs_x86_32.cpp >>> src/cpu/x86/vm/vtableStubs_x86_64.cpp >>> src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp >>> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >>> src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp >>> src/os_cpu/linux_x86/vm/os_linux_x86.cpp >>> src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp >>> src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp >>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp >>> src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp >>> src/os_cpu/windows_x86/vm/os_windows_x86.cpp >>> src/os/bsd/vm/os_bsd.cpp >>> src/os/bsd/vm/os_bsd.inline.hpp >>> src/os/bsd/vm/osThread_bsd.cpp >>> src/os/linux/vm/os_linux.cpp >>> src/os/linux/vm/os_linux.inline.hpp >>> src/os/linux/vm/osThread_linux.cpp >>> src/os/solaris/vm/os_solaris.cpp >>> src/os/solaris/vm/os_solaris.inline.hpp >>> src/os/solaris/vm/osThread_solaris.cpp >>> src/os/windows/vm/os_windows.cpp >>> src/os/windows/vm/os_windows.inline.hpp >>> src/os/windows/vm/osThread_windows.cpp >>> src/share/vm/asm/assembler.cpp >>> src/share/vm/asm/assembler.hpp >>> src/share/vm/asm/assembler.inline.hpp >>> src/share/vm/asm/codeBuffer.cpp >>> src/share/vm/asm/codeBuffer.hpp >>> src/share/vm/c1/c1_MacroAssembler.hpp >>> src/share/vm/code/icBuffer.cpp >>> src/share/vm/code/relocInfo.cpp >>> src/share/vm/interpreter/interpreter.cpp >>> src/share/vm/interpreter/interpreterRuntime.cpp >>> src/share/vm/opto/compile.cpp >>> src/share/vm/runtime/atomic.cpp >>> src/share/vm/runtime/atomic.hpp >>> src/share/vm/runtime/atomic.inline.hpp >>> src/share/vm/runtime/frame.cpp >>> src/share/vm/runtime/frame.hpp >>> src/share/vm/runtime/sharedRuntime.cpp >>> src/share/vm/runtime/stubCodeGenerator.cpp >>> > From vitalyd at gmail.com Fri Nov 30 15:37:56 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 18:37:56 -0500 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: <50B93EE3.2080208@oracle.com> References: <50B93EE3.2080208@oracle.com> Message-ID: What's the reason safepoints were yanked out in the first place? I'd assume safepoints aren't that frequent, at least while a typical loop is running. Once the polling page is in cache (first iteration will bring it in) and assuming the test instruction on it will always go the same way (i.e. safepoint not requested) won't the cache hitting load and perfectly predicted (common case) branch not have noticeable impact on the loop? Or am I underestimating safepoint frequency? Or is the polling test in the loop inhibiting some optimizations due to control flow? Or something else? :) Also, counted loops are only those with a compile time constant limit, right? Or does a read of a final field (or otherwise deduced by JIT to be a runtime constant) whose value is the loop limit also count? Thanks Sent from my phone On Nov 30, 2012 6:19 PM, "Vladimir Kozlov" wrote: > On 11/30/12 12:51, Vitaly Davidovich wrote: > >> By the way, what would a fix involve? Polling for safepoint every X >> trips through the loop where X is some reasonable value and then >> overridable via a JVM arg? I guess otherwise the JVM would have to >> know/estimate the cost of the loop body, which seems intractable in >> general. >> > > An other approach is "mine stripping" - split a loop into inner and outer > loops. > Polling not on each iteration requires test and branch which could be more > expensive than load with unused result. > Current plan (6869327) is simple to keep safepoint in counted loop when > the flag is specified. > > Vladimir > > >> What does J9 do? Does it simply not strip out polling? >> >> Thanks >> >> Sent from my phone >> >> On Nov 30, 2012 3:28 PM, "Volker Simonis" > >> wrote: >> >> Hi Vitaly, >> >> you're right, even a STW GC will have to wait until this loop >> without a safepoint will finish. On the other side, if there is an >> allocation inside the loop, the allocation will be done on the "fast >> path" (without safepoint check) only until the thread local buffer >> (TLAB) will be full. After that it will have to take the "slow path" >> which is a VM call and which has a safe point check. So in practice >> I think the problem is only with very tight loops which do same >> small but expensive computations (or with nested int loops which >> have potentially the same complexity like long loops but no safpoint >> either). >> >> Regards, >> Volker >> >> On Friday, November 30, 2012, Vitaly Davidovich wrote: >> >> Hi Volker, >> >> Just curious - what happens if a STW GC needs to occur right as >> this type of loop is entered? Does the VM just stall until the >> loop exits? What if this loop does a fast path allocation on >> some iteration? Do all allocations check for safepoints >> internally? >> >> Thanks >> >> Sent from my phone >> >> On Nov 30, 2012 1:41 PM, "Volker Simonis" >> wrote: >> >> Hi, >> >> This is a long standing problem of HotSpot (compared for >> example to >> J9). It doesn't put Safepoints into counted int loops >> (because it >> assumes they will terminate just "fast enough" which is not >> the case >> in your example). You can see another example for this >> behavior in >> these slides >> "http://www.progdoc.de/papers/**Jax2012/jax2012.html#%288%29 >> " >> together with the generated assembler code. >> >> You can easily solve the problem by making your loop >> variable a "long" >> instead of an "int". In that case, HotSpot will be more >> cautious and >> place a safepoint into the loop. >> >> Regards, >> Volker >> >> On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk >> wrote: >> > Hi, >> > >> > We faced some weird issue with thread scheduling. At a >> first glance it >> > looked like it relates to >> > >> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_** >> id=7160161 >> but not exactly. >> > >> > This is the code we ran: >> > >> > public static void main(String[] args) throws Exception { >> Thread worker = >> > new Thread() { @Override public void run() { double d = >> 0; for (int j = 1; j >> > < 2000000000; j++) d += Math.log(Math.E * j); >> System.out.println(d); } }; >> > Thread reporter = new Thread() { @Override public void >> run() { try { while >> > (true) { Thread.sleep(1000); System.out.println("Running: >> " + >> > System.currentTimeMillis()); } } catch >> (InterruptedException ignored) { >> > Thread.currentThread().**interrupt(); } } }; >> reporter.start(); worker.start(); >> > worker.join(); reporter.interrupt(); } >> > >> > One can expect that printing thread would output messages >> during all the >> > calculation time, however it hangs after 3-4 iterations. >> Setting >> > -XX:FreqInlineSize=0 as described in original bug report >> does not help in >> > this case, but if I extract loop body into a separate >> method, setting this >> > option works. Example passes with -Xint option as well. >> (Tested with >> > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on >> Linux) >> > >> > I saw #7160161 marked as resolved, so I just wanted to >> confirm if behavior >> > we see really relates to this issue and it was fixed (bug >> report covers >> > non-Counted loop only). >> > >> > Also, is there any other workarounds rather then >> extracting the method and >> > specifying FreqInlineSize=0? >> > >> > Thanks, >> > Alexey Goncharuk >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/bbc136c8/attachment.html From vitalyd at gmail.com Fri Nov 30 15:39:44 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 18:39:44 -0500 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: <50B93EE3.2080208@oracle.com> Message-ID: Of course, the test/jmp eats up a few nstructions but I'd be surprised if that has any impact on icache. Sent from my phone On Nov 30, 2012 6:37 PM, "Vitaly Davidovich" wrote: > What's the reason safepoints were yanked out in the first place? I'd > assume safepoints aren't that frequent, at least while a typical loop is > running. Once the polling page is in cache (first iteration will bring it > in) and assuming the test instruction on it will always go the same way > (i.e. safepoint not requested) won't the cache hitting load and perfectly > predicted (common case) branch not have noticeable impact on the loop? Or > am I underestimating safepoint frequency? Or is the polling test in the > loop inhibiting some optimizations due to control flow? Or something else? > :) > > Also, counted loops are only those with a compile time constant limit, > right? Or does a read of a final field (or otherwise deduced by JIT to be a > runtime constant) whose value is the loop limit also count? > > Thanks > > Sent from my phone > On Nov 30, 2012 6:19 PM, "Vladimir Kozlov" > wrote: > >> On 11/30/12 12:51, Vitaly Davidovich wrote: >> >>> By the way, what would a fix involve? Polling for safepoint every X >>> trips through the loop where X is some reasonable value and then >>> overridable via a JVM arg? I guess otherwise the JVM would have to >>> know/estimate the cost of the loop body, which seems intractable in >>> general. >>> >> >> An other approach is "mine stripping" - split a loop into inner and outer >> loops. >> Polling not on each iteration requires test and branch which could be >> more expensive than load with unused result. >> Current plan (6869327) is simple to keep safepoint in counted loop when >> the flag is specified. >> >> Vladimir >> >> >>> What does J9 do? Does it simply not strip out polling? >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Nov 30, 2012 3:28 PM, "Volker Simonis" >> >> wrote: >>> >>> Hi Vitaly, >>> >>> you're right, even a STW GC will have to wait until this loop >>> without a safepoint will finish. On the other side, if there is an >>> allocation inside the loop, the allocation will be done on the "fast >>> path" (without safepoint check) only until the thread local buffer >>> (TLAB) will be full. After that it will have to take the "slow path" >>> which is a VM call and which has a safe point check. So in practice >>> I think the problem is only with very tight loops which do same >>> small but expensive computations (or with nested int loops which >>> have potentially the same complexity like long loops but no safpoint >>> either). >>> >>> Regards, >>> Volker >>> >>> On Friday, November 30, 2012, Vitaly Davidovich wrote: >>> >>> Hi Volker, >>> >>> Just curious - what happens if a STW GC needs to occur right as >>> this type of loop is entered? Does the VM just stall until the >>> loop exits? What if this loop does a fast path allocation on >>> some iteration? Do all allocations check for safepoints >>> internally? >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Nov 30, 2012 1:41 PM, "Volker Simonis" >>> wrote: >>> >>> Hi, >>> >>> This is a long standing problem of HotSpot (compared for >>> example to >>> J9). It doesn't put Safepoints into counted int loops >>> (because it >>> assumes they will terminate just "fast enough" which is not >>> the case >>> in your example). You can see another example for this >>> behavior in >>> these slides >>> "http://www.progdoc.de/papers/**Jax2012/jax2012.html#%288%29 >>> " >>> together with the generated assembler code. >>> >>> You can easily solve the problem by making your loop >>> variable a "long" >>> instead of an "int". In that case, HotSpot will be more >>> cautious and >>> place a safepoint into the loop. >>> >>> Regards, >>> Volker >>> >>> On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk >>> wrote: >>> > Hi, >>> > >>> > We faced some weird issue with thread scheduling. At a >>> first glance it >>> > looked like it relates to >>> > >>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_** >>> id=7160161 >>> but not exactly. >>> > >>> > This is the code we ran: >>> > >>> > public static void main(String[] args) throws Exception { >>> Thread worker = >>> > new Thread() { @Override public void run() { double d = >>> 0; for (int j = 1; j >>> > < 2000000000; j++) d += Math.log(Math.E * j); >>> System.out.println(d); } }; >>> > Thread reporter = new Thread() { @Override public void >>> run() { try { while >>> > (true) { Thread.sleep(1000); System.out.println("Running: >>> " + >>> > System.currentTimeMillis()); } } catch >>> (InterruptedException ignored) { >>> > Thread.currentThread().**interrupt(); } } }; >>> reporter.start(); worker.start(); >>> > worker.join(); reporter.interrupt(); } >>> > >>> > One can expect that printing thread would output messages >>> during all the >>> > calculation time, however it hangs after 3-4 iterations. >>> Setting >>> > -XX:FreqInlineSize=0 as described in original bug report >>> does not help in >>> > this case, but if I extract loop body into a separate >>> method, setting this >>> > option works. Example passes with -Xint option as well. >>> (Tested with >>> > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on >>> Linux) >>> > >>> > I saw #7160161 marked as resolved, so I just wanted to >>> confirm if behavior >>> > we see really relates to this issue and it was fixed (bug >>> report covers >>> > non-Counted loop only). >>> > >>> > Also, is there any other workarounds rather then >>> extracting the method and >>> > specifying FreqInlineSize=0? >>> > >>> > Thanks, >>> > Alexey Goncharuk >>> > >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/17e5256f/attachment-0001.html From vitalyd at gmail.com Fri Nov 30 15:48:39 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 18:48:39 -0500 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: <50B93EE3.2080208@oracle.com> Message-ID: PhaseIdealLoop::is_counted_loop() answered my 2nd question - it doesn't seem to need compile time constant. Among other conditions, it has to be loop invariant but not constant. That method is a monster btw :) Sent from my phone On Nov 30, 2012 6:37 PM, "Vitaly Davidovich" wrote: > What's the reason safepoints were yanked out in the first place? I'd > assume safepoints aren't that frequent, at least while a typical loop is > running. Once the polling page is in cache (first iteration will bring it > in) and assuming the test instruction on it will always go the same way > (i.e. safepoint not requested) won't the cache hitting load and perfectly > predicted (common case) branch not have noticeable impact on the loop? Or > am I underestimating safepoint frequency? Or is the polling test in the > loop inhibiting some optimizations due to control flow? Or something else? > :) > > Also, counted loops are only those with a compile time constant limit, > right? Or does a read of a final field (or otherwise deduced by JIT to be a > runtime constant) whose value is the loop limit also count? > > Thanks > > Sent from my phone > On Nov 30, 2012 6:19 PM, "Vladimir Kozlov" > wrote: > >> On 11/30/12 12:51, Vitaly Davidovich wrote: >> >>> By the way, what would a fix involve? Polling for safepoint every X >>> trips through the loop where X is some reasonable value and then >>> overridable via a JVM arg? I guess otherwise the JVM would have to >>> know/estimate the cost of the loop body, which seems intractable in >>> general. >>> >> >> An other approach is "mine stripping" - split a loop into inner and outer >> loops. >> Polling not on each iteration requires test and branch which could be >> more expensive than load with unused result. >> Current plan (6869327) is simple to keep safepoint in counted loop when >> the flag is specified. >> >> Vladimir >> >> >>> What does J9 do? Does it simply not strip out polling? >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Nov 30, 2012 3:28 PM, "Volker Simonis" >> >> wrote: >>> >>> Hi Vitaly, >>> >>> you're right, even a STW GC will have to wait until this loop >>> without a safepoint will finish. On the other side, if there is an >>> allocation inside the loop, the allocation will be done on the "fast >>> path" (without safepoint check) only until the thread local buffer >>> (TLAB) will be full. After that it will have to take the "slow path" >>> which is a VM call and which has a safe point check. So in practice >>> I think the problem is only with very tight loops which do same >>> small but expensive computations (or with nested int loops which >>> have potentially the same complexity like long loops but no safpoint >>> either). >>> >>> Regards, >>> Volker >>> >>> On Friday, November 30, 2012, Vitaly Davidovich wrote: >>> >>> Hi Volker, >>> >>> Just curious - what happens if a STW GC needs to occur right as >>> this type of loop is entered? Does the VM just stall until the >>> loop exits? What if this loop does a fast path allocation on >>> some iteration? Do all allocations check for safepoints >>> internally? >>> >>> Thanks >>> >>> Sent from my phone >>> >>> On Nov 30, 2012 1:41 PM, "Volker Simonis" >>> wrote: >>> >>> Hi, >>> >>> This is a long standing problem of HotSpot (compared for >>> example to >>> J9). It doesn't put Safepoints into counted int loops >>> (because it >>> assumes they will terminate just "fast enough" which is not >>> the case >>> in your example). You can see another example for this >>> behavior in >>> these slides >>> "http://www.progdoc.de/papers/**Jax2012/jax2012.html#%288%29 >>> " >>> together with the generated assembler code. >>> >>> You can easily solve the problem by making your loop >>> variable a "long" >>> instead of an "int". In that case, HotSpot will be more >>> cautious and >>> place a safepoint into the loop. >>> >>> Regards, >>> Volker >>> >>> On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk >>> wrote: >>> > Hi, >>> > >>> > We faced some weird issue with thread scheduling. At a >>> first glance it >>> > looked like it relates to >>> > >>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_** >>> id=7160161 >>> but not exactly. >>> > >>> > This is the code we ran: >>> > >>> > public static void main(String[] args) throws Exception { >>> Thread worker = >>> > new Thread() { @Override public void run() { double d = >>> 0; for (int j = 1; j >>> > < 2000000000; j++) d += Math.log(Math.E * j); >>> System.out.println(d); } }; >>> > Thread reporter = new Thread() { @Override public void >>> run() { try { while >>> > (true) { Thread.sleep(1000); System.out.println("Running: >>> " + >>> > System.currentTimeMillis()); } } catch >>> (InterruptedException ignored) { >>> > Thread.currentThread().**interrupt(); } } }; >>> reporter.start(); worker.start(); >>> > worker.join(); reporter.interrupt(); } >>> > >>> > One can expect that printing thread would output messages >>> during all the >>> > calculation time, however it hangs after 3-4 iterations. >>> Setting >>> > -XX:FreqInlineSize=0 as described in original bug report >>> does not help in >>> > this case, but if I extract loop body into a separate >>> method, setting this >>> > option works. Example passes with -Xint option as well. >>> (Tested with >>> > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on >>> Linux) >>> > >>> > I saw #7160161 marked as resolved, so I just wanted to >>> confirm if behavior >>> > we see really relates to this issue and it was fixed (bug >>> report covers >>> > non-Counted loop only). >>> > >>> > Also, is there any other workarounds rather then >>> extracting the method and >>> > specifying FreqInlineSize=0? >>> > >>> > Thanks, >>> > Alexey Goncharuk >>> > >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/ec64a591/attachment.html From Vladimir.Kozlov at oracle.com Fri Nov 30 15:52:59 2012 From: Vladimir.Kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 30 Nov 2012 15:52:59 -0800 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: References: <50B93EE3.2080208@oracle.com> Message-ID: <50B946DB.1060407@oracle.com> On 11/30/12 15:37, Vitaly Davidovich wrote: > What's the reason safepoints were yanked out in the first place? I'd > assume safepoints aren't that frequent, at least while a typical loop is > running. Once the polling page is in cache (first iteration will bring > it in) and assuming the test instruction on it will always go the same > way (i.e. safepoint not requested) won't the cache hitting load and > perfectly predicted (common case) branch not have noticeable impact on > the loop? Or am I underestimating safepoint frequency? Or is the polling > test in the loop inhibiting some optimizations due to control flow? Or > something else? :) It is not simple touch of polling page. It is point where a method could be deoptimized. For that a SafePoint node has edges to live values in a graph (C2 IR). And it affects our current implementation of loop optimizations (unrolling, iterations splitting, vectorization). So C2 will generate less optimal loop code. > > Also, counted loops are only those with a compile time constant limit, > right? Or does a read of a final field (or otherwise deduced by JIT to > be a runtime constant) whose value is the loop limit also count? No. Counted loop in C2 is a loop with constant integer increment, one entry path and one exit path with iteration check at the end of loop's body. Low and upper iterations limits could be variables. Vladimir > > Thanks > > Sent from my phone > > On Nov 30, 2012 6:19 PM, "Vladimir Kozlov" > wrote: > > On 11/30/12 12:51, Vitaly Davidovich wrote: > > By the way, what would a fix involve? Polling for safepoint every X > trips through the loop where X is some reasonable value and then > overridable via a JVM arg? I guess otherwise the JVM would have to > know/estimate the cost of the loop body, which seems intractable > in general. > > > An other approach is "mine stripping" - split a loop into inner and > outer loops. > Polling not on each iteration requires test and branch which could > be more expensive than load with unused result. > Current plan (6869327) is simple to keep safepoint in counted loop > when the flag is specified. > > Vladimir > > > What does J9 do? Does it simply not strip out polling? > > Thanks > > Sent from my phone > > On Nov 30, 2012 3:28 PM, "Volker Simonis" > > >> wrote: > > Hi Vitaly, > > you're right, even a STW GC will have to wait until this loop > without a safepoint will finish. On the other side, if > there is an > allocation inside the loop, the allocation will be done on > the "fast > path" (without safepoint check) only until the thread local > buffer > (TLAB) will be full. After that it will have to take the > "slow path" > which is a VM call and which has a safe point check. So in > practice > I think the problem is only with very tight loops which do same > small but expensive computations (or with nested int loops > which > have potentially the same complexity like long loops but no > safpoint > either). > > Regards, > Volker > > On Friday, November 30, 2012, Vitaly Davidovich wrote: > > Hi Volker, > > Just curious - what happens if a STW GC needs to occur > right as > this type of loop is entered? Does the VM just stall > until the > loop exits? What if this loop does a fast path > allocation on > some iteration? Do all allocations check for safepoints > internally? > > Thanks > > Sent from my phone > > On Nov 30, 2012 1:41 PM, "Volker Simonis" > > wrote: > > Hi, > > This is a long standing problem of HotSpot > (compared for > example to > J9). It doesn't put Safepoints into counted int loops > (because it > assumes they will terminate just "fast enough" > which is not > the case > in your example). You can see another example for this > behavior in > these slides > "http://www.progdoc.de/papers/__Jax2012/jax2012.html#%288%29 > " > together with the generated assembler code. > > You can easily solve the problem by making your loop > variable a "long" > instead of an "int". In that case, HotSpot will be more > cautious and > place a safepoint into the loop. > > Regards, > Volker > > On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk > > wrote: > > Hi, > > > > We faced some weird issue with thread scheduling. At a > first glance it > > looked like it relates to > > > http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=7160161 > > but not exactly. > > > > This is the code we ran: > > > > public static void main(String[] args) throws Exception { > Thread worker = > > new Thread() { @Override public void run() { double d = > 0; for (int j = 1; j > > < 2000000000; j++) d += Math.log(Math.E * j); > System.out.println(d); } }; > > Thread reporter = new Thread() { @Override public void > run() { try { while > > (true) { Thread.sleep(1000); System.out.println("Running: " + > > System.currentTimeMillis()); } } catch > (InterruptedException ignored) { > > Thread.currentThread().__interrupt(); } } }; > reporter.start(); worker.start(); > > worker.join(); reporter.interrupt(); } > > > > One can expect that printing thread would output messages > during all the > > calculation time, however it hangs after 3-4 iterations. > Setting > > -XX:FreqInlineSize=0 as described in original bug report > does not help in > > this case, but if I extract loop body into a separate > method, setting this > > option works. Example passes with -Xint option as well. > (Tested with > > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on > Linux) > > > > I saw #7160161 marked as resolved, so I just wanted to > confirm if behavior > > we see really relates to this issue and it was fixed (bug > report covers > > non-Counted loop only). > > > > Also, is there any other workarounds rather then > extracting the method and > > specifying FreqInlineSize=0? > > > > Thanks, > > Alexey Goncharuk > > > From vitalyd at gmail.com Fri Nov 30 16:03:26 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 30 Nov 2012 19:03:26 -0500 Subject: Broken thread scheduling in indexed loop (missing safepoint?) In-Reply-To: <50B946DB.1060407@oracle.com> References: <50B93EE3.2080208@oracle.com> <50B946DB.1060407@oracle.com> Message-ID: I see, thanks Vladimir. Sent from my phone On Nov 30, 2012 6:53 PM, "Vladimir Kozlov" wrote: > On 11/30/12 15:37, Vitaly Davidovich wrote: > >> What's the reason safepoints were yanked out in the first place? I'd >> assume safepoints aren't that frequent, at least while a typical loop is >> running. Once the polling page is in cache (first iteration will bring >> it in) and assuming the test instruction on it will always go the same >> way (i.e. safepoint not requested) won't the cache hitting load and >> perfectly predicted (common case) branch not have noticeable impact on >> the loop? Or am I underestimating safepoint frequency? Or is the polling >> test in the loop inhibiting some optimizations due to control flow? Or >> something else? :) >> > > It is not simple touch of polling page. It is point where a method could > be deoptimized. For that a SafePoint node has edges to live values in a > graph (C2 IR). And it affects our current implementation of loop > optimizations (unrolling, iterations splitting, vectorization). So C2 will > generate less optimal loop code. > > >> Also, counted loops are only those with a compile time constant limit, >> right? Or does a read of a final field (or otherwise deduced by JIT to >> be a runtime constant) whose value is the loop limit also count? >> > > No. Counted loop in C2 is a loop with constant integer increment, one > entry path and one exit path with iteration check at the end of loop's > body. Low and upper iterations limits could be variables. > > Vladimir > > >> Thanks >> >> Sent from my phone >> >> On Nov 30, 2012 6:19 PM, "Vladimir Kozlov" > >> >> wrote: >> >> On 11/30/12 12:51, Vitaly Davidovich wrote: >> >> By the way, what would a fix involve? Polling for safepoint every >> X >> trips through the loop where X is some reasonable value and then >> overridable via a JVM arg? I guess otherwise the JVM would have to >> know/estimate the cost of the loop body, which seems intractable >> in general. >> >> >> An other approach is "mine stripping" - split a loop into inner and >> outer loops. >> Polling not on each iteration requires test and branch which could >> be more expensive than load with unused result. >> Current plan (6869327) is simple to keep safepoint in counted loop >> when the flag is specified. >> >> Vladimir >> >> >> What does J9 do? Does it simply not strip out polling? >> >> Thanks >> >> Sent from my phone >> >> On Nov 30, 2012 3:28 PM, "Volker Simonis" >> >> > >> > >>> >> wrote: >> >> Hi Vitaly, >> >> you're right, even a STW GC will have to wait until this loop >> without a safepoint will finish. On the other side, if >> there is an >> allocation inside the loop, the allocation will be done on >> the "fast >> path" (without safepoint check) only until the thread local >> buffer >> (TLAB) will be full. After that it will have to take the >> "slow path" >> which is a VM call and which has a safe point check. So in >> practice >> I think the problem is only with very tight loops which do >> same >> small but expensive computations (or with nested int loops >> which >> have potentially the same complexity like long loops but no >> safpoint >> either). >> >> Regards, >> Volker >> >> On Friday, November 30, 2012, Vitaly Davidovich wrote: >> >> Hi Volker, >> >> Just curious - what happens if a STW GC needs to occur >> right as >> this type of loop is entered? Does the VM just stall >> until the >> loop exits? What if this loop does a fast path >> allocation on >> some iteration? Do all allocations check for safepoints >> internally? >> >> Thanks >> >> Sent from my phone >> >> On Nov 30, 2012 1:41 PM, "Volker Simonis" >> >> >> wrote: >> >> Hi, >> >> This is a long standing problem of HotSpot >> (compared for >> example to >> J9). It doesn't put Safepoints into counted int loops >> (because it >> assumes they will terminate just "fast enough" >> which is not >> the case >> in your example). You can see another example for >> this >> behavior in >> these slides >> "http://www.progdoc.de/papers/**__Jax2012/jax2012.html#%288%29 >> >> >" >> together with the generated assembler code. >> >> You can easily solve the problem by making your loop >> variable a "long" >> instead of an "int". In that case, HotSpot will be >> more >> cautious and >> place a safepoint into the loop. >> >> Regards, >> Volker >> >> On Fri, Nov 30, 2012 at 2:05 PM, Alexey Goncharuk >> >> >> wrote: >> > Hi, >> > >> > We faced some weird issue with thread scheduling. At a >> first glance it >> > looked like it relates to >> > >> http://bugs.sun.com/__**bugdatabase/view_bug.do?bug___** >> id=7160161 >> >> > >> but not exactly. >> > >> > This is the code we ran: >> > >> > public static void main(String[] args) throws Exception { >> Thread worker = >> > new Thread() { @Override public void run() { double d = >> 0; for (int j = 1; j >> > < 2000000000; j++) d += Math.log(Math.E * j); >> System.out.println(d); } }; >> > Thread reporter = new Thread() { @Override public void >> run() { try { while >> > (true) { Thread.sleep(1000); System.out.println("Running: " + >> > System.currentTimeMillis()); } } catch >> (InterruptedException ignored) { >> > Thread.currentThread().__**interrupt(); } } }; >> reporter.start(); worker.start(); >> > worker.join(); reporter.interrupt(); } >> > >> > One can expect that printing thread would output messages >> during all the >> > calculation time, however it hangs after 3-4 iterations. >> Setting >> > -XX:FreqInlineSize=0 as described in original bug report >> does not help in >> > this case, but if I extract loop body into a separate >> method, setting this >> > option works. Example passes with -Xint option as well. >> (Tested with >> > 1.6.0_33, 1.6.0_37, 1.7.0_07 on Windows and 1.6.0_33 on >> Linux) >> > >> > I saw #7160161 marked as resolved, so I just wanted to >> confirm if behavior >> > we see really relates to this issue and it was fixed (bug >> report covers >> > non-Counted loop only). >> > >> > Also, is there any other workarounds rather then >> extracting the method and >> > specifying FreqInlineSize=0? >> > >> > Thanks, >> > Alexey Goncharuk >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121130/e8dce5cb/attachment-0001.html From christian.thalinger at oracle.com Fri Nov 30 21:35:26 2012 From: christian.thalinger at oracle.com (christian.thalinger at oracle.com) Date: Sat, 01 Dec 2012 05:35:26 +0000 Subject: hg: hsx/hotspot-comp/hotspot: 8003240: x86: move MacroAssembler into separate file Message-ID: <20121201053530.BFEC947C6B@hg.openjdk.java.net> Changeset: cd3d6a6b95d9 Author: twisti Date: 2012-11-30 15:23 -0800 URL: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/cd3d6a6b95d9 8003240: x86: move MacroAssembler into separate file Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/codeBuffer_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.hpp ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/assembler_x86.inline.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/icBuffer_x86.cpp ! src/cpu/x86/vm/icache_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/jniFastGetField_x86_32.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp + src/cpu/x86/vm/macroAssembler_x86.cpp + src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/metaspaceShared_x86_32.cpp ! src/cpu/x86/vm/metaspaceShared_x86_64.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/nativeInst_x86.cpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/runtime_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/os/bsd/vm/osThread_bsd.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/osThread_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/solaris/vm/osThread_solaris.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/vm/osThread_windows.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/assembler_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_x86/vm/assembler_linux_x86.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/assembler.inline.hpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/asm/codeBuffer.hpp + src/share/vm/asm/macroAssembler.hpp + src/share/vm/asm/macroAssembler.inline.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/runtime/atomic.cpp ! src/share/vm/runtime/atomic.hpp + src/share/vm/runtime/atomic.inline.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp