From dalibor.topic at oracle.com Thu Aug 1 06:39:40 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 01 Aug 2013 15:39:40 +0200 Subject: Avoid using deprecated stat64 on Mac OS X In-Reply-To: References: <51F5FCA7.4090102@oracle.com> Message-ID: <51FA651C.3080109@oracle.com> On 7/29/13 7:34 AM, Krystal Mok wrote: > Hi David, > > Thanks for taking a look. I'm not that familiar with other BSD variants, > and I'm only encountering this on Mac OS X. Looking for help here. > > I think FreeBSD also uses the bsd-port in their downstream OpenJDK package. > FreeBSD uses stat instead of stat64, too. Right now the BSD port is used by NetBSD, OpenBSD, PCBSD, DragonFlyBSD and FreeBSD, at least. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From john.coomes at oracle.com Thu Aug 1 10:31:32 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 01 Aug 2013 17:31:32 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b101 for changeset 9f74a220677d Message-ID: <20130801173132.A02BD48518@hg.openjdk.java.net> Changeset: 5eb3c1dc348f Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/5eb3c1dc348f Added tag jdk8-b101 for changeset 9f74a220677d ! .hgtags From john.coomes at oracle.com Thu Aug 1 10:31:39 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 01 Aug 2013 17:31:39 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b101 for changeset a013024b0747 Message-ID: <20130801173142.7F8E248519@hg.openjdk.java.net> Changeset: 528c7e76eaee Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/528c7e76eaee Added tag jdk8-b101 for changeset a013024b0747 ! .hgtags From john.coomes at oracle.com Thu Aug 1 10:31:56 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 01 Aug 2013 17:31:56 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b101 for changeset 0a7432f898e5 Message-ID: <20130801173203.4CF984851A@hg.openjdk.java.net> Changeset: b8cd8b101ecb Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/b8cd8b101ecb Added tag jdk8-b101 for changeset 0a7432f898e5 ! .hgtags From john.coomes at oracle.com Thu Aug 1 10:32:13 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 01 Aug 2013 17:32:13 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b101 for changeset 60b623a36164 Message-ID: <20130801173219.77C7D4851B@hg.openjdk.java.net> Changeset: 988a5f2ac559 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/988a5f2ac559 Added tag jdk8-b101 for changeset 60b623a36164 ! .hgtags From john.coomes at oracle.com Thu Aug 1 10:32:30 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 01 Aug 2013 17:32:30 +0000 Subject: hg: hsx/hotspot-main/jdk: Added tag jdk8-b101 for changeset 690161232823 Message-ID: <20130801173334.1B6F84851C@hg.openjdk.java.net> Changeset: b52a2ecdb803 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b52a2ecdb803 Added tag jdk8-b101 for changeset 690161232823 ! .hgtags From john.coomes at oracle.com Thu Aug 1 10:35:34 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 01 Aug 2013 17:35:34 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b101 for changeset 0324dbf07b0f Message-ID: <20130801173546.183D04851D@hg.openjdk.java.net> Changeset: 4c42fba7b0e7 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4c42fba7b0e7 Added tag jdk8-b101 for changeset 0324dbf07b0f ! .hgtags From john.coomes at oracle.com Thu Aug 1 10:36:06 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 01 Aug 2013 17:36:06 +0000 Subject: hg: hsx/hotspot-main/nashorn: Added tag jdk8-b101 for changeset a302b05d0ee4 Message-ID: <20130801173609.29A1A4851E@hg.openjdk.java.net> Changeset: 573ccf92d646 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/573ccf92d646 Added tag jdk8-b101 for changeset a302b05d0ee4 ! .hgtags From david.holmes at oracle.com Thu Aug 1 15:49:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 02 Aug 2013 08:49:46 +1000 Subject: Avoid using deprecated stat64 on Mac OS X In-Reply-To: <51FA651C.3080109@oracle.com> References: <51F5FCA7.4090102@oracle.com> <51FA651C.3080109@oracle.com> Message-ID: <51FAE60A.5080902@oracle.com> On 1/08/2013 11:39 PM, Dalibor Topic wrote: > On 7/29/13 7:34 AM, Krystal Mok wrote: >> Hi David, >> >> Thanks for taking a look. I'm not that familiar with other BSD variants, >> and I'm only encountering this on Mac OS X. Looking for help here. >> >> I think FreeBSD also uses the bsd-port in their downstream OpenJDK package. >> FreeBSD uses stat instead of stat64, too. > > Right now the BSD port is used by NetBSD, OpenBSD, PCBSD, DragonFlyBSD and FreeBSD, at least. So more ifdef crud is needed :( Thanks, David > cheers, > dalibor topic > From tao.mao at oracle.com Thu Aug 1 23:28:52 2013 From: tao.mao at oracle.com (tao.mao at oracle.com) Date: Fri, 02 Aug 2013 06:28:52 +0000 Subject: hg: hsx/hotspot-main/hotspot: 9 new changesets Message-ID: <20130802062914.9DB7548560@hg.openjdk.java.net> Changeset: e3c8767c5cf8 Author: tschatzl Date: 2013-07-24 10:07 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e3c8767c5cf8 8020123: Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build" Summary: Remove the @build tag and replace it by a @run tag so that the test gets executed Reviewed-by: brutisso, mgerdin ! test/gc/g1/TestPrintRegionRememberedSetInfo.java Changeset: 7b06ae405d7b Author: jmasa Date: 2013-07-23 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7b06ae405d7b 6990419: CMS Remaining work for 6572569: consistently skewed work distribution in (long) re-mark pauses Reviewed-by: rasbold, tschatzl, jmasa Contributed-by: yamauchi at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/runtime/globals.hpp Changeset: fb7010c7c011 Author: jmasa Date: 2013-07-25 07:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fb7010c7c011 Merge Changeset: ca9dedeebdec Author: jmasa Date: 2013-07-25 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ca9dedeebdec 6412968: CMS Long initial mark pauses Reviewed-by: rasbold, tschatzl, jmasa Contributed-by: yamauchi at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: 8796fd3ac898 Author: tamao Date: 2013-07-26 13:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8796fd3ac898 Merge ! src/share/vm/runtime/globals.hpp Changeset: 313227279a05 Author: brutisso Date: 2013-08-01 07:03 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/313227279a05 8021967: Deprecate -XX:DefaultMaxRAMFraction Reviewed-by: tschatzl, jmasa, kvn, tamao ! src/share/vm/runtime/arguments.cpp + test/gc/startup_warnings/TestDefaultMaxRAMFraction.java Changeset: dae8324fc7d1 Author: brutisso Date: 2013-08-01 09:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dae8324fc7d1 8021879: G1: G1HeapRegionSize flag value not updated correctly Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp + test/gc/arguments/TestG1HeapRegionSize.java Changeset: 8d4ff57af591 Author: brutisso Date: 2013-08-01 17:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8d4ff57af591 8022051: G1: Remove some unused G1 flags Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 69d0dbb53c78 Author: tamao Date: 2013-08-01 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/69d0dbb53c78 Merge From vladimir.danushevsky at oracle.com Fri Aug 2 06:57:14 2013 From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky) Date: Fri, 2 Aug 2013 09:57:14 -0400 Subject: RFR: 8006971: More missing barriers in taskqueues for RMO architectures Message-ID: The issue of missing memory barriers in the GC taskqueue code was first flagged here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html JDK7u40 fix for the same issue is located here: http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ Initially we planned to port same solution to JDK8 however after reviewing the algorithm more we've started questioning a need for a full fence in between 'age' and 'bottom' elements. Since the intent is to keep 'bottom' memory reference from being executed before 'age' would a LoadLoad barrier (which in many cases is a cheaper solution) be sufficient? If so, the webrev below could possible be an adequate solution. http://cr.openjdk.java.net/~vladidan/8006971/webrev.00/ We have tested both cases (fence and LL) on a hexa-core Power5 box running several test suites that currently expose the problem. The results are positive. As a side note - perhaps it is possible to eliminate age/bottom potential reordering by loading both simultaneously through an Atomic class method. That would require though some structural changes to the layout of TaskQueueSuper class to align both fields together and ensure proper integer alignment (depending on 32/64-bit port), therefore this solution is less practical for the short term. Thanks, Vlad From alejandro.murillo at oracle.com Fri Aug 2 07:00:38 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 02 Aug 2013 14:00:38 +0000 Subject: hg: hsx/hsx25/hotspot: 23 new changesets Message-ID: <20130802140130.7A1204856F@hg.openjdk.java.net> Changeset: 7c9885d23744 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7c9885d23744 Added tag jdk8-b101 for changeset f6921c876db1 ! .hgtags Changeset: e84845884c85 Author: amurillo Date: 2013-07-26 04:01 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e84845884c85 8021566: new hotspot build - hs25-b44 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d90d1b96b65b Author: kvn Date: 2013-07-26 12:37 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d90d1b96b65b 8008938: TieredCompilation should be default Summary: switch on TieredCompilation by default Reviewed-by: twisti ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: 1b6395189726 Author: minqi Date: 2013-07-19 14:43 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1b6395189726 8012263: ciReplay: gracefully exit & report meaningful error when replay data parsing fails Summary: find_method could return NULL so need explicitly check if there is error after parse_method, exit on error to avoid crash. Reviewed-by: kvn, twisti Contributed-by: yumin.qi at oracle.com ! src/share/vm/ci/ciReplay.cpp Changeset: 5ad7f8179bf7 Author: minqi Date: 2013-07-24 08:04 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5ad7f8179bf7 Merge Changeset: b6baf306e698 Author: fparain Date: 2013-07-26 05:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b6baf306e698 Merge Changeset: 83ca9dc4564d Author: fparain Date: 2013-07-26 15:24 +0000 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/83ca9dc4564d 8019845: Memory leak during class redefinition Reviewed-by: acorn, jmasa, coleenp, dcubed, mgerdin ! src/share/vm/memory/metaspace.cpp Changeset: f9ee986a9fea Author: ccheung Date: 2013-07-30 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f9ee986a9fea 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases Summary: Added checking for gcc and simplified the sig_handler() in the test case Reviewed-by: dcubed, coleenp, minqi, dlong ! test/runtime/6929067/Test6929067.sh ! test/runtime/7107135/Test7107135.sh ! test/runtime/jsig/Test8017498.sh ! test/runtime/jsig/TestJNI.c Changeset: 0f98cc013b21 Author: fparain Date: 2013-07-31 08:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0f98cc013b21 Merge Changeset: c65045599519 Author: dholmes Date: 2013-07-25 21:05 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c65045599519 8021314: minimal1.make needs to force off components not supported by the minimal VM Reviewed-by: coleenp, bpittore ! make/bsd/makefiles/minimal1.make ! make/linux/makefiles/minimal1.make Changeset: 078e5eb2e52e Author: clucasius Date: 2013-07-27 17:23 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/078e5eb2e52e Merge Changeset: da839a3c5735 Author: dholmes Date: 2013-07-31 19:05 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/da839a3c5735 Merge Changeset: e3c8767c5cf8 Author: tschatzl Date: 2013-07-24 10:07 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e3c8767c5cf8 8020123: Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build" Summary: Remove the @build tag and replace it by a @run tag so that the test gets executed Reviewed-by: brutisso, mgerdin ! test/gc/g1/TestPrintRegionRememberedSetInfo.java Changeset: 7b06ae405d7b Author: jmasa Date: 2013-07-23 09:49 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7b06ae405d7b 6990419: CMS Remaining work for 6572569: consistently skewed work distribution in (long) re-mark pauses Reviewed-by: rasbold, tschatzl, jmasa Contributed-by: yamauchi at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/runtime/globals.hpp Changeset: fb7010c7c011 Author: jmasa Date: 2013-07-25 07:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fb7010c7c011 Merge Changeset: ca9dedeebdec Author: jmasa Date: 2013-07-25 11:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ca9dedeebdec 6412968: CMS Long initial mark pauses Reviewed-by: rasbold, tschatzl, jmasa Contributed-by: yamauchi at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: 8796fd3ac898 Author: tamao Date: 2013-07-26 13:34 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8796fd3ac898 Merge ! src/share/vm/runtime/globals.hpp Changeset: 313227279a05 Author: brutisso Date: 2013-08-01 07:03 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/313227279a05 8021967: Deprecate -XX:DefaultMaxRAMFraction Reviewed-by: tschatzl, jmasa, kvn, tamao ! src/share/vm/runtime/arguments.cpp + test/gc/startup_warnings/TestDefaultMaxRAMFraction.java Changeset: dae8324fc7d1 Author: brutisso Date: 2013-08-01 09:35 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dae8324fc7d1 8021879: G1: G1HeapRegionSize flag value not updated correctly Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp + test/gc/arguments/TestG1HeapRegionSize.java Changeset: 8d4ff57af591 Author: brutisso Date: 2013-08-01 17:29 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8d4ff57af591 8022051: G1: Remove some unused G1 flags Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 69d0dbb53c78 Author: tamao Date: 2013-08-01 17:17 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/69d0dbb53c78 Merge Changeset: 530fe88b3b2c Author: amurillo Date: 2013-08-02 02:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/530fe88b3b2c Merge Changeset: c4697c1c4484 Author: amurillo Date: 2013-08-02 02:54 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c4697c1c4484 Added tag hs25-b44 for changeset 530fe88b3b2c ! .hgtags From volker.simonis at gmail.com Fri Aug 2 08:15:25 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 2 Aug 2013 17:15:25 +0200 Subject: RFR (XL): 8019972: PPC64 (part 9): platform files for interpreter only VM. In-Reply-To: <51F21DC4.9050203@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF5F57@DEWDFEMB12A.global.corp.sap> <51E8CE88.2060801@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6587@DEWDFEMB12A.global.corp.sap> <51ECA679.9030707@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6851@DEWDFEMB12A.global.corp.sap> <51ED1995.3090003@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF69E5@DEWDFEMB12A.global.corp.sap> <51ED6249.5060701@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF6A32@DEWDFEMB12A.global.corp.sap> <51ED9024.3060208@oracle.com> <51EE3699.6000200@oracle.com> <51EE37B3.7090507@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF717A@DEWDFEMB12A.global.corp.sap> <51F0BAF1.1090000@oracle.com> <51F1B6CD.4040902@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF7FB2@DEWDFEMB12A.global.corp.sap> <51F1BF00.4070709@oracle.com> <4295855A5C1DE049A61835A1887419CC0CFF803B@DEWDFEMB12A.global.corp.sap> <51F21DC4.9050203@oracle.com> Message-ID: Hi Vladimir, thank you for syncing our hotspot forest in the staging repository. I have now applied the changes mentioned by Goetz to his webrev: http://cr.openjdk.java.net/~simonis/webrevs/8019972/ It builds and runs fine on Linux/ppc64. Can you please try JPRT and push it if everything works out fine? Thank you and best regards, Volker On Fri, Jul 26, 2013 at 8:57 AM, Vladimir Kozlov wrote: > Thank you for explanation. I assume you will prepare a new 8019972 patch > when 8016131 is pushed into stage repo (should be next week (crossing > fingers)). And I want to push this 8019972 changes using JPRT. > > Regards, > Vladimir > > > On 7/25/13 11:16 PM, Lindenmaier, Goetz wrote: >> >> Hi Vladimir, >> >> the change will be necessary once >> 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in >> 'entry_frame_is_first()' >> arrives in the stage repository. So I'd like to test 0009 once more >> before you >> push it, and adapt it accordingly. >> This should not invalidate your tests, as it's in a ppc file. >> >> Best regards, >> Goetz. >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Freitag, 26. Juli 2013 02:13 >> To: Lindenmaier, Goetz >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >> interpreter only VM. >> >> Hi Goetz, >> >> On 7/25/13 5:02 PM, Lindenmaier, Goetz wrote: >>> >>> Hi Vladimir, >>> >>> thanks for testing! >>> We soon need to apply this to 0009: >> >> >> What do you mean "soon"? >> >> Do you ask me to fix it in your latest ppcfiles-3-hotspot.changeset >> before pushing? Or it will be separate changeset? >> >> thanks, >> Vladimir >> >>> >>> diff -r 63458ae3c26f src/cpu/ppc/vm/frame_ppc.inline.hpp >>> --- a/src/cpu/ppc/vm/frame_ppc.inline.hpp Fri Jul 26 01:17:42 2013 >>> +0200 >>> +++ b/src/cpu/ppc/vm/frame_ppc.inline.hpp Fri Jul 26 01:56:10 2013 >>> +0200 >>> @@ -224,8 +224,8 @@ >>> return &tos[offset + 1]; // prepushed tos >>> } >>> >>> -inline JavaCallWrapper* frame::entry_frame_call_wrapper() const { >>> - return (JavaCallWrapper*)entry_frame_locals()->call_wrapper_address; >>> +inline JavaCallWrapper** frame::entry_frame_call_wrapper_addr() const { >>> + return (JavaCallWrapper**)&entry_frame_locals()->call_wrapper_address; >>> } >>> >>> inline oop frame::saved_oop_result(RegisterMap* map) const { >>> >>> Probably the corresponding change will come with the build change. >>> >>> David, thanks for fixing the build. >>> >>> Best regards, >>> Goetz. >>> >>> >>> -----Original Message----- >>> From: ppc-aix-port-dev-bounces at openjdk.java.net >>> [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Vladimir >>> Kozlov >>> Sent: Friday, July 26, 2013 1:38 AM >>> Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>> interpreter only VM. >>> >>> Hotspot JPRT testing passed. >>> >>> I will push these changes into stage repo when David's changes reach it. >>> >>> Thanks, >>> Vladimir >>> >>> On 7/24/13 10:43 PM, Vladimir Kozlov wrote: >>>> >>>> Thank you, Goetz, >>>> >>>> This looks good. >>>> >>>> David pushed makefile changes (8020799) in group's repo. I will try to >>>> combine all these changes with staged sources and run JPRT test builds >>>> tomorrow. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/24/13 7:46 AM, Lindenmaier, Goetz wrote: >>>>> >>>>> Hi, >>>>> >>>>> I updated the webrev once more. >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>>> >>>>> - I fixed encode_klass_not_null() >>>>> - I cleaned up jni_ppc.h >>>>> - added the guard in copy_ppc.hpp. >>>>> >>>>> Further there were problems on aix. >>>>> I had to rename the condition code registers from CR0-7 to CCR0-7, >>>>> as CR0-3 is defined in an AIX system header. >>>>> >>>>> David, can I mark the change as reviewed by you? >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> -----Original Message----- >>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>> Sent: Dienstag, 23. Juli 2013 09:59 >>>>> To: Lindenmaier, Goetz >>>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>>> hotspot-dev at openjdk.java.net >>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>> interpreter only VM. >>>>> >>>>> PS. Seems src/cpu/ppc/vm/copy_ppc.hpp has the same issue. The atomic >>>>> copies for jlong are only correct on 64-bit. >>>>> >>>>> Is there other code in "bit-neutral" ppc files that is really only >>>>> correct on 64-bit? >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 23/07/2013 5:54 PM, David Holmes wrote: >>>>>> >>>>>> On 23/07/2013 6:03 AM, Vladimir Kozlov wrote: >>>>>>> >>>>>>> On 7/22/13 11:03 AM, Lindenmaier, Goetz wrote: >>>>>>>> >>>>>>>> >>>>>>>> I don't really care about the guard. Just tell me what to do... >>>>>>> >>>>>>> >>>>>>> To be safe leave guards with PPC64 check instead of _lp64 as you >>>>>>> suggested. >>>>>> >>>>>> >>>>>> Yes please do that. I think the guard is important as this is a >>>>>> bit-neutral file. If/when someone creates a 32-bit PPC port we don't >>>>>> want them to have to re-discover the atomicity bugs with jlong/jdouble >>>>>> that were found on the existing platforms. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Do you plan to implement ppc32 or ppc64+lp32 or you can't tell me :) >>>>>>> ? : >>>>>>> >>>>>>> jniTypes_ppc.hpp: >>>>>>> >>>>>>> 48 #ifndef PPC64 >>>>>>> 49 #error "ppc32 support currently not implemented!!!" >>>>>>> 50 #endif // PPC64 >>>>>>> >>>>>>> Our reviews are based on assumption that this port only supports >>>>>>> PPC64+LP64 combination. Is this correct assumption? >>>>>>> >>>>>>> Do you really need to check __APPLE__ in jni_ppc.h? Yes, I have old >>>>>>> ppc >>>>>>> based macbook pro. But do we need it in this port? >>>>>>> >>>>>>> Regards, >>>>>>> Vladimir >>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>>>>>> Sent: Monday, July 22, 2013 6:48 PM >>>>>>>> To: Lindenmaier, Goetz >>>>>>>> Cc: David Holmes; ppc-aix-port-dev at openjdk.java.net; >>>>>>>> hotspot-dev at openjdk.java.net >>>>>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>>>>> interpreter only VM. >>>>>>>> >>>>>>>> On 7/22/13 5:40 AM, Lindenmaier, Goetz wrote: >>>>>>>>>> >>>>>>>>>> ??? Or do you propose to change both of them to PPC64? >>>>>>>>> >>>>>>>>> Yes, sure, I want to change both. >>>>>>>> >>>>>>>> >>>>>>>> Why do we need this error if this code is only for PPC64 port? We >>>>>>>> will >>>>>>>> have other compilation errors if we try to use >>>>>>>> these sources for something else as we found already. Do you have an >>>>>>>> other usage so you need this guard? >>>>>>>> >>>>>>>>>> All of the existing 64-bit ports have a direct correspondence >>>>>>>>>> between >>>>>>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>>>>>> >>>>>>>>> >>>>>>>>> I know. And obviously there is a correspondence, as no one will >>>>>>>>> Implement an LG64 memory model on a 32 bit machine. >>>>>>>>> But the usage intermingles different memory model and architecture: >>>>>>>>> >>>>>>>>> E.g., the register declaration in register_x86_hpp is fine: >>>>>>>>> >>>>>>>>> #ifdef AMD64 >>>>>>>>> CONSTANT_REGISTER_DECLARATION(Register, r8, (8)); >>>>>>>>> >>>>>>>>> But I think this makes no sense (assembler_x86.hpp): >>>>>>>>> >>>>>>>>> #ifdef _LP64 >>>>>>>>> void movsbq(Register dst, Address src); >>>>>>>>> void movsbq(Register dst, Register src); >>>>>>>>> // Move signed 32bit immediate to 64bit extending sign >>>>>>>>> void movslq(Address dst, int32_t imm64); >>>>>>>>> void movslq(Register dst, int32_t imm64); >>>>>>>>> >>>>>>>>> and should be guarded by AMD64. >>>>>>>> >>>>>>>> >>>>>>>> Strictly speaking you are right. But we will never do ilp32 for >>>>>>>> AMD64 >>>>>>>> so using _LP64 works for us. Also using AMD64 >>>>>>>> sometimes rise questions about Intel x64. So using _LP64 is more >>>>>>>> neutral. >>>>>>>> >>>>>>>>> And I want to get the PPC port right in such matters. >>>>>>>> >>>>>>>> >>>>>>>> I agree with this since ppc is more flexible than x86, it seems. >>>>>>>> >>>>>>>>> I'm currently removing the ppc_ prefixes ... big fun:) >>>>>>>> >>>>>>>> >>>>>>>> Sorry about that. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Vladimir >>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> Sent: Montag, 22. Juli 2013 13:38 >>>>>>>>> To: Lindenmaier, Goetz >>>>>>>>> Cc: Vladimir Kozlov; ppc-aix-port-dev at openjdk.java.net; >>>>>>>>> hotspot-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform files for >>>>>>>>> interpreter only VM. >>>>>>>>> >>>>>>>>> On 22/07/2013 5:14 PM, Lindenmaier, Goetz wrote: >>>>>>>>> >>>>>>>>> > Hi David, >>>>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>>> > PPC64: describes an instruction set / machine with all it's >>>>>>>>> specialities. And the instruction set >>>>>>>>> >>>>>>>>> > we implemented the port for has an atomic 64-bit >>>>>>>>> instruction. >>>>>>>>> >>>>>>>>> > LP64 describes a memory model. I.E, long == 64bit, int == >>>>>>>>> 32bit >>>>>>>>> , pointer == 64 bit. >>>>>>>>> >>>>>>>>> > In contraditction to ILP64 (int == 64bit) etc, which you >>>>>>>>> could as >>>>>>>>> well implement with the >>>>>>>>> >>>>>>>>> > PPC64 instruction set. You could also implement a system >>>>>>>>> with >>>>>>>>> ILP32 on PPC64, and then >>>>>>>>> >>>>>>>>> > you would have an atomic 64-bit instruction. >>>>>>>>> >>>>>>>>> That still doesn't explain why you think LP64 is okay for the >>>>>>>>> atomic >>>>>>>>> >>>>>>>>> file but you want PPC64 for the orderAccess file. ??? Or do you >>>>>>>>> propose >>>>>>>>> >>>>>>>>> to change both of them to PPC64? >>>>>>>>> >>>>>>>>> All of the existing 64-bit ports have a direct correspondence >>>>>>>>> between >>>>>>>>> >>>>>>>>> the 64-bit platform designator (sparcv9, amd64, x86_64) and LP64. >>>>>>>>> LP64 >>>>>>>>> >>>>>>>>> is the only 64-bit data model that the OpenJDK sources support. >>>>>>>>> >>>>>>>>> > Compressed oops make sense to protect with LP64, because >>>>>>>>> they >>>>>>>>> are >>>>>>>>> only helpful >>>>>>>>> >>>>>>>>> > with 64 bit pointers. While usage of LP64 is not exactly >>>>>>>>> correct >>>>>>>>> here, ILP64, SLP64 >>>>>>>>> >>>>>>>>> > etc would also use compressed oops. But it's close enough I >>>>>>>>> guess. >>>>>>>>> >>>>>>>>> I'm not concerned about compressed oops. No idea where that came >>>>>>>>> from >>>>>>>>> ;-) >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> ------ >>>>>>>>> >>>>>>>>> > Best regards, >>>>>>>>> >>>>>>>>> > Goetz. >>>>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>>> > -----Original Message----- >>>>>>>>> >>>>>>>>> > From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> >>>>>>>>> > Sent: Montag, 22. Juli 2013 05:27 >>>>>>>>> >>>>>>>>> > To: Lindenmaier, Goetz >>>>>>>>> >>>>>>>>> > Cc: hotspot-dev at openjdk.java.net >>>>>>>>> ; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> ; Vladimir Kozlov >>>>>>>>> >>>>>>>>> > Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform >>>>>>>>> files >>>>>>>>> for interpreter only VM. >>>>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>>> > On 20/07/2013 5:47 AM, Lindenmaier, Goetz wrote: >>>>>>>>> >>>>>>>>> >> Hi David, >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >>> I think orderAccess_linux_ppc.inline.hpp should have: >>>>>>>>> >>>>>>>>> >>> 34 #ifndef _LP64 >>>>>>>>> >>>>>>>>> >>> 35 #error "Atomic currently only impleneted for >>>>>>>>> PPC64" >>>>>>>>> >>>>>>>>> >>> 36 #endif >>>>>>>>> >>>>>>>>> >> You're right, I'll fix this. >>>>>>>>> >>>>>>>>> >> If you don't object I'll guard it by PPC64 as it depends on >>>>>>>>> the >>>>>>>>> >>>>>>>>> >> processor architecture and not the memory model. >>>>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>>> > Is there some case where _LP64 would be true but PPC64 would >>>>>>>>> not >>>>>>>>> be ??? >>>>>>>>> >>>>>>>>> > They seem effectively interchangeable but I don't know why >>>>>>>>> you >>>>>>>>> would use >>>>>>>>> >>>>>>>>> > one in one file and the other in another file ?? >>>>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>>> > Thanks, >>>>>>>>> >>>>>>>>> > David >>>>>>>>> >>>>>>>>> > >>>>>>>>> >>>>>>>>> >> If I will change the ppc_ prefixes that'll take a bit, >>>>>>>>> especially >>>>>>>>> >>>>>>>>> >> as I will have to adapt all the alignments :(. >>>>>>>>> >>>>>>>>> >> But that does not matter, as we need to wait for your build >>>>>>>>> >>>>>>>>> >> change anyways. >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> Best regards, >>>>>>>>> >>>>>>>>> >> Goetz. >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> -----Original Message----- >>>>>>>>> >>>>>>>>> >> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>> >>>>>>>>> >> Sent: Friday, July 19, 2013 7:29 AM >>>>>>>>> >>>>>>>>> >> To: Lindenmaier, Goetz >>>>>>>>> >>>>>>>>> >> Cc: hotspot-dev at openjdk.java.net >>>>>>>>> ; >>>>>>>>> ppc-aix-port-dev at openjdk.java.net >>>>>>>>> ; Vladimir Kozlov >>>>>>>>> >>>>>>>>> >> Subject: Re: RFR (XL): 8019972: PPC64 (part 9): platform >>>>>>>>> files >>>>>>>>> for interpreter only VM. >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> Hi Goetz, >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> Only a brief glance through ... >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> I think orderAccess_linux_ppc.inline.hpp should have: >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> 34 #ifndef _LP64 >>>>>>>>> >>>>>>>>> >> 35 #error "Atomic currently only impleneted for PPC64" >>>>>>>>> >>>>>>>>> >> 36 #endif >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> the same as in atomic_linux_ppc.inline.hpp (the jlong >>>>>>>>> variants >>>>>>>>> will only >>>>>>>>> >>>>>>>>> >> be atomic on ppc64). >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> BTW typo: 35 #error "Atomic currently only impleneted for >>>>>>>>> PPC64" >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> I also find the ppc_ prefix used in the assembly code >>>>>>>>> somewhat >>>>>>>>> redundant. >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> David >>>>>>>>> >>>>>>>>> >> ----- >>>>>>>>> >>>>>>>>> >> >>>>>>>>> >>>>>>>>> >> On 18/07/2013 1:34 AM, Lindenmaier, Goetz wrote: >>>>>>>>> >>>>>>>>> >>> Hi, >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> >>>>>>>>> >>> This time with webrev. Sorry for the double mails. >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> >>>>>>>>> >>> This change contains all the files in cpu/ppc and >>>>>>>>> os_cpu/linux_ppc needed for >>>>>>>>> >>>>>>>>> >>> the PPC64 interpreter port on linux. >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> >>>>>>>>> >>> With this change you can do a core build on ppc64 and run >>>>>>>>> the >>>>>>>>> VM interpreter only. >>>>>>>>> >>>>>>>>> >>> It executes simple programs as jvm98. >>>>>>>>> >>>>>>>>> >>> The change requires >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> >>>>>>>>> >>> * 8016697: Use stubs to implement safefetch >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> >>>>>>>>> >>> * 8020059: The flag introduced by 8014972 is not >>>>>>>>> defined ... >>>>>>>>> >>>>>>>>> >>> which will arrive soon in the staging repository. >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> >>>>>>>>> >>> I marked the change as XL as it contains a lot of code. >>>>>>>>> Nevertheless the >>>>>>>>> >>>>>>>>> >>> code has no impact on the existing Oracle platforms. >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> >>>>>>>>> >>> The change touches a single shared file, globals.hpp, >>>>>>>>> removing a >>>>>>>>> >>>>>>>>> >>> special case introduced for the port. This is because we >>>>>>>>> >>>>>>>>> >>> integrated some changes earlier than originally intended. >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> >>>>>>>>> >>> Please review the change. Does it need testing on Oracle >>>>>>>>> side? >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/webrevs/8019972-ppc_files/ >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> >>>>>>>>> >>> Best regards, >>>>>>>>> >>>>>>>>> >>> Goetz. >>>>>>>>> >>>>>>>>> >>> >>>>>>>>> > From alejandro.murillo at oracle.com Fri Aug 2 08:36:47 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 02 Aug 2013 15:36:47 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130802153709.333ED48573@hg.openjdk.java.net> Changeset: 7c9885d23744 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7c9885d23744 Added tag jdk8-b101 for changeset f6921c876db1 ! .hgtags Changeset: 530fe88b3b2c Author: amurillo Date: 2013-08-02 02:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/530fe88b3b2c Merge Changeset: c4697c1c4484 Author: amurillo Date: 2013-08-02 02:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c4697c1c4484 Added tag hs25-b44 for changeset 530fe88b3b2c ! .hgtags Changeset: 79ce055063e9 Author: amurillo Date: 2013-08-02 03:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/79ce055063e9 8022124: new hotspot build - hs25-b45 Reviewed-by: jcoomes ! make/hotspot_version From serguei.spitsyn at oracle.com Fri Aug 2 18:12:31 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 02 Aug 2013 18:12:31 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51F8114B.2040302@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> Message-ID: <51FC58FF.6040600@oracle.com> Hi Bill, A couple of more questions. webrev.01/jvmti.html An agent L whose image has been combined with the VM *is defined* as /statically linked/ if and only if the agent exports a function called Agent_OnLoad_L. A question to the above. Are we going to allow to link a library dynamically if it exports both the Agent_OnLoad and Agent_OnLoad_L functions? It can be convenient if a library exports both Agent_OnLoad and Agent_OnLoad_L as it can be linked statically or dynamically depending on the need without changes. You already added the following statement to the JVMTI spec: If a /statically linked/ agent L exports a function called Agent_OnLoad_L and a function called Agent_OnLoad, the Agent_OnLoad function will be ignored. Could we say it in a shorter form?: If a /statically linked/ agent L exports a function called Agent_OnLoad, the Agent_OnLoad function will be ignored. In this context would it be reasonable to add another statement: If a /dynamically linked/ agent L exports a function called Agent_OnLoad_L, the Agent_OnLoad_L function will be ignored. The same questions apply to the Agent_OnAttach and Agent_OnAttach_L entry points. Thanks, Serguei On 7/30/13 12:17 PM, bill.pittore at oracle.com wrote: > Thanks Serguei for the comments. Some comments inline. I updated the > webrevs at > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ > > http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html > > > On 7/26/2013 5:00 AM, serguei.spitsyn at oracle.com wrote: >> Hi Bill, >> >> Sorry for the big delay. >> >> >> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >> >> >> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >> >> >> I'm suggesting to use the reference >> *Agent_OnAttach[_L]**||* even more consistently. >> (If, in some cases, you prefer the longer form to underline the >> difference between >> dynamically and statically linked libraries then feel free to leave >> it as it is.) >> >> It would simplify the following fragments: >> >> 304 * It then causes the target VM to invoke the Agent_OnAttach function >> 305 * or, for a statically linked agent named 'L', the Agent_OnAttach_L function >> ==> >> >> 304 * It then causes the target VM to invoke the Agent_OnAttach[_L] function >> >> 409 * It then causes the target VM to invoke the Agent_OnAttach >> 410 * function or, for a statically linked agent named 'L', the >> 411 * Agent_OnAttach_L function as specified in the >> ==> >> 409 * It then causes the target VM to invoke the Agent_OnAttach[_L] >> 410 * function as specified in the >> > I left the above as is since it's part of the method description. The > following fragments below I simplified as you suggested. > >> >> the following 4 identical fragments: >> >> 341 * If the Agent_OnAttach function returns an error >> 342 * or, for a statically linked agent named 'L', if the >> 343 * Agent_OnAttach_L function returns >> 344 * an error. >> 375 * If the Agent_OnAttach function returns an error >> 376 * or, for a statically linked agent named 'L', if the >> 377 * Agent_OnAttach_L function returns >> 378 * an error. >> 442 * If the Agent_OnAttach function returns an error >> 443 * or, for a statically linked agent named 'L', if the >> 444 * Agent_OnAttach_L function returns an error >> 475 * If the Agent_OnAttach function returns an error >> 476 * or, for a statically linked agent named 'L', if the >> 477 * Agent_OnAttach_L function returns >> 478 * an error. >> ==> >> >> 336 * If the Agent_OnAttach[_L] function >> returns an error. >> > >> >> >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >> >> >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >> src/share/vm/prims/jvmti.xml >> >> Lines 442-462: many extra

's. The fragment does not look well. >> I'd suggest to remove most of them. >> Also, these lines are too long. Could you make them shorter, please? >> The same is applied to other long new lines in this file. > Cleaned this up a bit. >> >> Lines 490-491, 502-503, 505-506: >> The same sentence is repeated 3 times: "the agent library may be >> statically linked ..." >> >> 490 Note that the agent library may be statically linked into >> the executable >> 491 in which case no actual loading takes place. > Fixed. >> >> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is >> specified, the VM will attempt to >> 502 load the shared library c:\myLibs\foo.dll. >> As mentioned above, the agent library may be statically linked into >> the executable >> 503 in which case no actual loading takes place >> >> 505 Note that the agent library may be statically linked into >> the executable >> 506 in which case no actual loading takes place. >> > Tweaked the above a bit to make it less wordy. > >> Lines 677-678: The dot is missed at the end of line 677: >> >> 677 and enabled the event >> > Fixed. >> >> src/os/posix/vm/os_posix.cpp >> >> - no comments >> >> src/os/windows/vm/os_windows.cpp >> >> - no comments >> >> src/share/vm/prims/jvmtiExport.cpp >> >> - no comments >> >> src/share/vm/runtime/arguments.hpp >> >> - no comments >> >> src/share/vm/runtime/os.cpp >> >> Space is missed after the 'if': >> 471 if(entryName != NULL) { >> > Fixed. >> Extra space after the '*': >> 483 void * saveHandle; >> > Fixed. >> src/share/vm/runtime/os.hpp >> >> - no comments >> >> src/share/vm/runtime/thread.cpp >> >> The line has been removed: >> 3866 break; >> > Correct, the inner for loop was removed so no need for the break; >> >> I'm still in process of reading the code. >> Another pass is needed to make sure that nothing is missed. >> But in general, the code quality is pretty good. >> >> Thanks, >> Serguei >> >> >> >> On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: >>> Still need an official reviewer for the hotspot changes for >>> statically linked agents. >>> >>> thanks, >>> bill >>> >>>> These changes address bug 8014135 which adds support for statically >>>> linked agents in the VM. This is a followup to the recent JNI spec >>>> changes that addressed statically linked JNI libraries( 8005716). >>>> The JEP for this change is the same JEP as the JNI changes: >>>> http://openjdk.java.net/jeps/178 >>>> >>>> Webrevs are here: >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>> >>>> The changes to jvmti.xml can also be seen in the output file that I >>>> placed here: >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>> >>>> >>>> Thanks, >>>> bill >>>> >>> >> > > From bill.pittore at oracle.com Fri Aug 2 20:11:17 2013 From: bill.pittore at oracle.com (Bill Pittore) Date: Fri, 02 Aug 2013 23:11:17 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51FC58FF.6040600@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> Message-ID: <51FC74D5.70704@oracle.com> On 8/2/2013 9:12 PM, serguei.spitsyn at oracle.com wrote: > Hi Bill, > > A couple of more questions. > > webrev.01/jvmti.html > > An agent L whose image has been combined with the VM *is defined* as > /statically linked/ > if and only if the agent exports a function called Agent_OnLoad_L. > > A question to the above. > Are we going to allow to link a library dynamically if it exports both > the Agent_OnLoad and Agent_OnLoad_L functions? > It can be convenient if a library exports both Agent_OnLoad and > Agent_OnLoad_L > as it can be linked statically or dynamically depending on the need > without changes. > It would be nice but the problem is that you could only link one agent into the VM if it exported Agent_OnLoad. Otherwise there would be a symbol collision with the second agent you linked in that also had Agent_OnLoad. As an agent developer you will have to select one or the other at build time, either statically linked in or dynamic. > You already added the following statement to the JVMTI spec: > If a /statically linked/ agent L exports a function called > Agent_OnLoad_L and > a function called Agent_OnLoad, the Agent_OnLoad function will be > ignored. > > Could we say it in a shorter form?: > If a /statically linked/ agent L exports a function called Agent_OnLoad, > the Agent_OnLoad function will be ignored. I believe I copied this from JNI static linking JEP. If so, I'll probably leave it as is just for consistency with JNI static spec. JVM TI static linking spec is closely related to JNI static linking spec. > > In this context would it be reasonable to add another statement: > If a /dynamically linked/ agent L exports a function called > Agent_OnLoad_L, > the Agent_OnLoad_L function will be ignored. > > The same questions apply to the Agent_OnAttach and Agent_OnAttach_L > entry points. > I'm out on vacation for a couple of weeks so I'll leave it up to Bob V. and yourself if you guys want to hash out better/different wording. bill > > Thanks, > Serguei > > > On 7/30/13 12:17 PM, bill.pittore at oracle.com wrote: >> Thanks Serguei for the comments. Some comments inline. I updated the >> webrevs at >> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >> >> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >> >> >> On 7/26/2013 5:00 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Bill, >>> >>> Sorry for the big delay. >>> >>> >>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>> >>> >>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>> >>> >>> I'm suggesting to use the reference >>> *Agent_OnAttach[_L]**||* even more consistently. >>> (If, in some cases, you prefer the longer form to underline the >>> difference between >>> dynamically and statically linked libraries then feel free to leave >>> it as it is.) >>> >>> It would simplify the following fragments: >>> >>> 304 * It then causes the target VM to invoke the Agent_OnAttach function >>> 305 * or, for a statically linked agent named 'L', the Agent_OnAttach_L function >>> ==> >>> >>> 304 * It then causes the target VM to invoke the Agent_OnAttach[_L] function >>> >>> 409 * It then causes the target VM to invoke the Agent_OnAttach >>> 410 * function or, for a statically linked agent named 'L', the >>> 411 * Agent_OnAttach_L function as specified in the >>> ==> >>> 409 * It then causes the target VM to invoke the Agent_OnAttach[_L] >>> 410 * function as specified in the >>> >> I left the above as is since it's part of the method description. The >> following fragments below I simplified as you suggested. >> >>> >>> the following 4 identical fragments: >>> >>> 341 * If the Agent_OnAttach function returns an error >>> 342 * or, for a statically linked agent named 'L', if the >>> 343 * Agent_OnAttach_L function returns >>> 344 * an error. >>> 375 * If the Agent_OnAttach function returns an error >>> 376 * or, for a statically linked agent named 'L', if the >>> 377 * Agent_OnAttach_L function returns >>> 378 * an error. >>> 442 * If the Agent_OnAttach function returns an error >>> 443 * or, for a statically linked agent named 'L', if the >>> 444 * Agent_OnAttach_L function returns an error >>> 475 * If the Agent_OnAttach function returns an error >>> 476 * or, for a statically linked agent named 'L', if the >>> 477 * Agent_OnAttach_L function returns >>> 478 * an error. >>> ==> >>> >>> 336 * If the Agent_OnAttach[_L] function >>> returns an error. >>> >> >>> >>> >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>> >>> >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>> src/share/vm/prims/jvmti.xml >>> >>> Lines 442-462: many extra

's. The fragment does not look well. >>> I'd suggest to remove most of them. >>> Also, these lines are too long. Could you make them shorter, please? >>> The same is applied to other long new lines in this file. >> Cleaned this up a bit. >>> >>> Lines 490-491, 502-503, 505-506: >>> The same sentence is repeated 3 times: "the agent library may >>> be statically linked ..." >>> >>> 490 Note that the agent library may be statically linked into >>> the executable >>> 491 in which case no actual loading takes place. >> Fixed. >>> >>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is >>> specified, the VM will attempt to >>> 502 load the shared library c:\myLibs\foo.dll. >>> As mentioned above, the agent library may be statically linked into >>> the executable >>> 503 in which case no actual loading takes place >>> >>> 505 Note that the agent library may be statically linked into >>> the executable >>> 506 in which case no actual loading takes place. >>> >> Tweaked the above a bit to make it less wordy. >> >>> Lines 677-678: The dot is missed at the end of line 677: >>> >>> 677 and enabled the event >>> >> Fixed. >>> >>> src/os/posix/vm/os_posix.cpp >>> >>> - no comments >>> >>> src/os/windows/vm/os_windows.cpp >>> >>> - no comments >>> >>> src/share/vm/prims/jvmtiExport.cpp >>> >>> - no comments >>> >>> src/share/vm/runtime/arguments.hpp >>> >>> - no comments >>> >>> src/share/vm/runtime/os.cpp >>> >>> Space is missed after the 'if': >>> 471 if(entryName != NULL) { >>> >> Fixed. >>> Extra space after the '*': >>> 483 void * saveHandle; >>> >> Fixed. >>> src/share/vm/runtime/os.hpp >>> >>> - no comments >>> >>> src/share/vm/runtime/thread.cpp >>> >>> The line has been removed: >>> 3866 break; >>> >> Correct, the inner for loop was removed so no need for the break; >>> >>> I'm still in process of reading the code. >>> Another pass is needed to make sure that nothing is missed. >>> But in general, the code quality is pretty good. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: >>>> Still need an official reviewer for the hotspot changes for >>>> statically linked agents. >>>> >>>> thanks, >>>> bill >>>> >>>>> These changes address bug 8014135 which adds support for >>>>> statically linked agents in the VM. This is a followup to the >>>>> recent JNI spec changes that addressed statically linked JNI >>>>> libraries( 8005716). >>>>> The JEP for this change is the same JEP as the JNI changes: >>>>> http://openjdk.java.net/jeps/178 >>>>> >>>>> Webrevs are here: >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>> >>>>> The changes to jvmti.xml can also be seen in the output file that >>>>> I placed here: >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>> >>>>> >>>>> Thanks, >>>>> bill >>>>> >>>> >>> >> >> > From serguei.spitsyn at oracle.com Fri Aug 2 21:34:20 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 02 Aug 2013 21:34:20 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51FC74D5.70704@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> Message-ID: <51FC884C.20407@oracle.com> On 8/2/13 8:11 PM, Bill Pittore wrote: > On 8/2/2013 9:12 PM, serguei.spitsyn at oracle.com wrote: >> Hi Bill, >> >> A couple of more questions. >> >> webrev.01/jvmti.html >> >> An agent L whose image has been combined with the VM *is defined* as >> /statically linked/ >> if and only if the agent exports a function called Agent_OnLoad_L. >> >> A question to the above. >> Are we going to allow to link a library dynamically if it exports both >> the Agent_OnLoad and Agent_OnLoad_L functions? >> It can be convenient if a library exports both Agent_OnLoad and >> Agent_OnLoad_L >> as it can be linked statically or dynamically depending on the need >> without changes. >> > It would be nice but the problem is that you could only link one agent > into the VM if it exported Agent_OnLoad. Otherwise there would be a > symbol collision with the second agent you linked in that also had > Agent_OnLoad. As an agent developer you will have to select one or the > other at build time, either statically linked in or dynamic. I did not want to use the Agent_OnLoad for statically linked agent. Just wanted to say that the presence of the Agent_OnLoad_L must be ignored if the agent is linked dynamically. Maybe this rule needs to be clearly stated in the JVMTI spec. >> You already added the following statement to the JVMTI spec: >> If a /statically linked/ agent L exports a function called >> Agent_OnLoad_L and >> a function called Agent_OnLoad, the Agent_OnLoad function will be >> ignored. >> >> Could we say it in a shorter form?: >> If a /statically linked/ agent L exports a function called Agent_OnLoad, >> the Agent_OnLoad function will be ignored. > I believe I copied this from JNI static linking JEP. If so, I'll > probably leave it as is just for consistency with JNI static spec. JVM > TI static linking spec is closely related to JNI static linking spec. I see. Then it is Ok with me. >> >> In this context would it be reasonable to add another statement: >> If a /dynamically linked/ agent L exports a function called >> Agent_OnLoad_L, >> the Agent_OnLoad_L function will be ignored. >> >> The same questions apply to the Agent_OnAttach and Agent_OnAttach_L >> entry points. >> > I'm out on vacation for a couple of weeks so I'll leave it up to Bob > V. and yourself if you guys want to hash out better/different wording. Thank you for the quick reply, and have a nice vacation! Thanks, Serguei > > bill >> >> Thanks, >> Serguei >> >> >> On 7/30/13 12:17 PM, bill.pittore at oracle.com wrote: >>> Thanks Serguei for the comments. Some comments inline. I updated the >>> webrevs at >>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>> >>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>> >>> >>> On 7/26/2013 5:00 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi Bill, >>>> >>>> Sorry for the big delay. >>>> >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>> >>>> >>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>> >>>> >>>> I'm suggesting to use the reference >>>> *Agent_OnAttach[_L]**||* even more consistently. >>>> (If, in some cases, you prefer the longer form to underline the >>>> difference between >>>> dynamically and statically linked libraries then feel free to >>>> leave it as it is.) >>>> >>>> It would simplify the following fragments: >>>> >>>> 304 * It then causes the target VM to invoke the Agent_OnAttach function >>>> 305 * or, for a statically linked agent named 'L', the Agent_OnAttach_L function >>>> ==> >>>> >>>> 304 * It then causes the target VM to invoke the Agent_OnAttach[_L] function >>>> >>>> 409 * It then causes the target VM to invoke the Agent_OnAttach >>>> 410 * function or, for a statically linked agent named 'L', the >>>> 411 * Agent_OnAttach_L function as specified in the >>>> ==> >>>> 409 * It then causes the target VM to invoke the Agent_OnAttach[_L] >>>> 410 * function as specified in the >>>> >>> I left the above as is since it's part of the method description. >>> The following fragments below I simplified as you suggested. >>> >>>> >>>> the following 4 identical fragments: >>>> >>>> 341 * If the Agent_OnAttach function returns an error >>>> 342 * or, for a statically linked agent named 'L', if the >>>> 343 * Agent_OnAttach_L function returns >>>> 344 * an error. >>>> 375 * If the Agent_OnAttach function returns an error >>>> 376 * or, for a statically linked agent named 'L', if the >>>> 377 * Agent_OnAttach_L function returns >>>> 378 * an error. >>>> 442 * If the Agent_OnAttach function returns an error >>>> 443 * or, for a statically linked agent named 'L', if the >>>> 444 * Agent_OnAttach_L function returns an error >>>> 475 * If the Agent_OnAttach function returns an error >>>> 476 * or, for a statically linked agent named 'L', if the >>>> 477 * Agent_OnAttach_L function returns >>>> 478 * an error. >>>> ==> >>>> >>>> 336 * If the Agent_OnAttach[_L] >>>> function returns an error. >>>> >>> >>>> >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>> >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>> src/share/vm/prims/jvmti.xml >>>> >>>> Lines 442-462: many extra

's. The fragment does not look well. >>>> I'd suggest to remove most of them. >>>> Also, these lines are too long. Could you make them shorter, please? >>>> The same is applied to other long new lines in this file. >>> Cleaned this up a bit. >>>> >>>> Lines 490-491, 502-503, 505-506: >>>> The same sentence is repeated 3 times: "the agent library may >>>> be statically linked ..." >>>> >>>> 490 Note that the agent library may be statically linked into >>>> the executable >>>> 491 in which case no actual loading takes place. >>> Fixed. >>>> >>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is >>>> specified, the VM will attempt to >>>> 502 load the shared library >>>> c:\myLibs\foo.dll. As mentioned above, the agent >>>> library may be statically linked into the executable >>>> 503 in which case no actual loading takes place >>>> >>>> 505 Note that the agent library may be statically linked into >>>> the executable >>>> 506 in which case no actual loading takes place. >>>> >>> Tweaked the above a bit to make it less wordy. >>> >>>> Lines 677-678: The dot is missed at the end of line 677: >>>> >>>> 677 and enabled the event >>>> >>> Fixed. >>>> >>>> src/os/posix/vm/os_posix.cpp >>>> >>>> - no comments >>>> >>>> src/os/windows/vm/os_windows.cpp >>>> >>>> - no comments >>>> >>>> src/share/vm/prims/jvmtiExport.cpp >>>> >>>> - no comments >>>> >>>> src/share/vm/runtime/arguments.hpp >>>> >>>> - no comments >>>> >>>> src/share/vm/runtime/os.cpp >>>> >>>> Space is missed after the 'if': >>>> 471 if(entryName != NULL) { >>>> >>> Fixed. >>>> Extra space after the '*': >>>> 483 void * saveHandle; >>>> >>> Fixed. >>>> src/share/vm/runtime/os.hpp >>>> >>>> - no comments >>>> >>>> src/share/vm/runtime/thread.cpp >>>> >>>> The line has been removed: >>>> 3866 break; >>>> >>> Correct, the inner for loop was removed so no need for the break; >>>> >>>> I'm still in process of reading the code. >>>> Another pass is needed to make sure that nothing is missed. >>>> But in general, the code quality is pretty good. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: >>>>> Still need an official reviewer for the hotspot changes for >>>>> statically linked agents. >>>>> >>>>> thanks, >>>>> bill >>>>> >>>>>> These changes address bug 8014135 which adds support for >>>>>> statically linked agents in the VM. This is a followup to the >>>>>> recent JNI spec changes that addressed statically linked JNI >>>>>> libraries( 8005716). >>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>> http://openjdk.java.net/jeps/178 >>>>>> >>>>>> Webrevs are here: >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>> >>>>>> The changes to jvmti.xml can also be seen in the output file that >>>>>> I placed here: >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>> >>>>>> >>>>>> Thanks, >>>>>> bill >>>>>> >>>>> >>>> >>> >>> >> > From david.holmes at oracle.com Sat Aug 3 03:53:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Sat, 03 Aug 2013 20:53:48 +1000 Subject: RFR: 8006971: More missing barriers in taskqueues for RMO architectures In-Reply-To: References: Message-ID: <51FCE13C.30304@oracle.com> Vlad, On 2/08/2013 11:57 PM, Vladimir Danushevsky wrote: > The issue of missing memory barriers in the GC taskqueue code was first flagged here: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html > > JDK7u40 fix for the same issue is located here: > http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ > > > Initially we planned to port same solution to JDK8 however after reviewing the algorithm more we've started questioning a need for a full fence in between 'age' and 'bottom' elements. Since the intent is to keep 'bottom' memory reference from being executed before 'age' would a LoadLoad barrier (which in many cases is a cheaper solution) be sufficient? If so, the webrev below could possible be an adequate solution. > > http://cr.openjdk.java.net/~vladidan/8006971/webrev.00/ > > We have tested both cases (fence and LL) on a hexa-core Power5 box running several test suites that currently expose the problem. The results are positive. The loadload() should not be in any ifdef. The loadload() is part of the algorithmic correctness. The loadload() will become a no-op on any platform that does not need to do anything special to preserve the ordering. Thanks, David > As a side note - > perhaps it is possible to eliminate age/bottom potential reordering by loading both simultaneously through an Atomic class method. That would require though some structural changes to the layout of TaskQueueSuper class to align both fields together and ensure proper integer alignment (depending on 32/64-bit port), therefore this solution is less practical for the short term. > > Thanks, > Vlad > From omajid at redhat.com Sun Aug 4 12:26:52 2013 From: omajid at redhat.com (Omair Majid) Date: Sun, 04 Aug 2013 15:26:52 -0400 Subject: Make zero compile after 8016131 and 8016697 Message-ID: <51FEAAFC.109@redhat.com> Hi, The following webrev makes zero compile again: http://cr.openjdk.java.net/~omajid/webrevs/zero-build-broken/00/ The changes in the werbrev mirror the changes made in the following changesets: changeset: 4983:e619a2766bcc user: rbackman date: Wed Jun 12 11:17:39 2013 +0200 summary: 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' changeset: 4961:980532a806a5 user: goetz date: Thu Jun 20 15:02:05 2013 +0200 summary: 8016697: Use stubs to implement safefetch I am not sure what the best tree to use is. I made the webrev against hsx/hotspot-rt, but it applies to hsx/hotspot-main without any changes too. Any concerns with the patch? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From david.holmes at oracle.com Sun Aug 4 16:57:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 05 Aug 2013 09:57:42 +1000 Subject: Make zero compile after 8016131 and 8016697 In-Reply-To: <51FEAAFC.109@redhat.com> References: <51FEAAFC.109@redhat.com> Message-ID: <51FEEA76.5050201@oracle.com> Hi Omair, On 5/08/2013 5:26 AM, Omair Majid wrote: > Hi, > > The following webrev makes zero compile again: > http://cr.openjdk.java.net/~omajid/webrevs/zero-build-broken/00/ > > The changes in the werbrev mirror the changes made in the following > changesets: > > changeset: 4983:e619a2766bcc > user: rbackman > date: Wed Jun 12 11:17:39 2013 +0200 > summary: 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in > 'entry_frame_is_first()' > > changeset: 4961:980532a806a5 > user: goetz > date: Thu Jun 20 15:02:05 2013 +0200 > summary: 8016697: Use stubs to implement safefetch > > I am not sure what the best tree to use is. I made the webrev against > hsx/hotspot-rt, but it applies to hsx/hotspot-main without any changes too. hotspot-rt is fine. It must be one of the group repos so hotspot-main is out. I've filed 8022188 for this and will sponsor it for you. > Any concerns with the patch? Nope. Reviewed. We need a second Reviewer before the push. Cheers, David ----- > > Thanks, > Omair > From dmitry.samersoff at oracle.com Mon Aug 5 06:26:26 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 05 Aug 2013 17:26:26 +0400 Subject: Avoid using deprecated stat64 on Mac OS X In-Reply-To: <51F5FCA7.4090102@oracle.com> References: <51F5FCA7.4090102@oracle.com> Message-ID: <51FFA802.4030704@oracle.com> David, > So is this purely an OSX issue or also a BSD one? I'm assuming OSX. > > Does anybody out there actually use the BSD port seperately from OSX? I use Java on FreeBSD more or less regularly. FreeBSD doesn't have stat64 at al. -Dmitry On 2013-07-29 09:24, David Holmes wrote: > Hi Kris, > > On 28/07/2013 5:59 PM, Krystal Mok wrote: >> Hi all, >> >> I'm building a freshly cloned repo from the tip of hotspot-comp on Mac >> OS X >> 10.7.5, and got and error: >> >> llvm-g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DASSERT -I. >> -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/share/vm/prims >> -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/share/vm >> -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/share/vm/precompiled >> -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/cpu/x86/vm >> -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/os_cpu/bsd_x86/vm >> -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm >> -I/Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/posix/vm >> -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b44-internal\"" >> -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" >> -DHOTSPOT_BUILD_USER="\"rednaxelafx\"" -DHOTSPOT_LIB_ARCH=\"amd64\" >> -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd >> -DTARGET_ARCH_x86 >> -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 >> -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 >> -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m64 >> -pipe -fno-strict-aliasing -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 >> -mmacosx-version-min=10.7.0 -Os -DVM_LITTLE_ENDIAN -D_LP64=1 >> -fno-omit-frame-pointer -Werror -Wunused-function -DDTRACE_ENABLED >> -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -DALLOW_OPERATOR_NEW_USAGE -c >> -MMD -MP >> -MF ../generated/dependencies/attachListener_bsd.o.d -fpch-deps -o >> attachListener_bsd.o >> /Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm/attachListener_bsd.cpp >> >> cc1plus: warnings being treated as errors >> /Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm/attachListener_bsd.cpp: >> >> In static member function ?static void AttachListener::vm_start()?: >> /Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: >> >> warning: ?stat64? is deprecated (declared at /usr/include/sys/stat.h:466) >> /Users/rednaxelafx/build/hotspot-comp/hotspot/src/os/bsd/vm/attachListener_bsd.cpp:455: >> >> warning: ?stat64? is deprecated (declared at /usr/include/sys/stat.h:466) >> make[6]: *** [attachListener_bsd.o] Error 1 >> >> The problem came from a recent commit [1]: >> 7162400: Intermittent java.io.IOException: Bad file number during >> HotSpotVirtualMachine.executeCommand >> >> According to [2], the *-64 variants of the stat*() functions have been >> deprecated on Mac OS X and should be avoided. > > So is this purely an OSX issue or also a BSD one? I'm assuming OSX. > > Does anybody out there actually use the BSD port seperately from OSX? > > David > ----- > >> >> The fix is simple: >> diff -r d90d1b96b65b src/os/bsd/vm/attachListener_bsd.cpp >> --- a/src/os/bsd/vm/attachListener_bsd.cpp Fri Jul 26 12:37:39 2013 -0700 >> +++ b/src/os/bsd/vm/attachListener_bsd.cpp Sun Jul 28 15:55:54 2013 +0800 >> @@ -445,14 +445,14 @@ >> >> void AttachListener::vm_start() { >> char fn[UNIX_PATH_MAX]; >> - struct stat64 st; >> + struct stat st; >> int ret; >> >> int n = snprintf(fn, UNIX_PATH_MAX, "%s/.java_pid%d", >> os::get_temp_directory(), os::current_process_id()); >> assert(n < (int)UNIX_PATH_MAX, "java_pid file name buffer overflow"); >> >> - RESTARTABLE(::stat64(fn, &st), ret); >> + RESTARTABLE(::stat(fn, &st), ret); >> if (ret == 0) { >> ret = ::unlink(fn); >> if (ret == -1) { >> >> I'm not sure if this should be done for all BSD platforms. Could anybody >> help confirm this? >> >> Thanks, >> Kris >> >> (P.S. recovering from bad health...) >> >> [1]: http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/2e8f19c2feef >> [2]: >> https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/stat64.2.html >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From bob.vandette at oracle.com Mon Aug 5 07:41:50 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 5 Aug 2013 10:41:50 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51FC74D5.70704@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> Message-ID: On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: > On 8/2/2013 9:12 PM, serguei.spitsyn at oracle.com wrote: >> Hi Bill, >> >> A couple of more questions. >> >> webrev.01/jvmti.html >> >> An agent L whose image has been combined with the VM *is defined* as /statically linked/ >> if and only if the agent exports a function called Agent_OnLoad_L. >> >> A question to the above. >> Are we going to allow to link a library dynamically if it exports both >> the Agent_OnLoad and Agent_OnLoad_L functions? >> It can be convenient if a library exports both Agent_OnLoad and Agent_OnLoad_L >> as it can be linked statically or dynamically depending on the need without changes. >> > It would be nice but the problem is that you could only link one agent into the VM if it exported Agent_OnLoad. Otherwise there would be a symbol collision with the second agent you linked in that also had Agent_OnLoad. As an agent developer you will have to select one or the other at build time, either statically linked in or dynamic. >> You already added the following statement to the JVMTI spec: >> If a /statically linked/ agent L exports a function called Agent_OnLoad_L and >> a function called Agent_OnLoad, the Agent_OnLoad function will be ignored. >> >> Could we say it in a shorter form?: >> If a /statically linked/ agent L exports a function called Agent_OnLoad, >> the Agent_OnLoad function will be ignored. > I believe I copied this from JNI static linking JEP. If so, I'll probably leave it as is just for consistency with JNI static spec. JVM TI static linking spec is closely related to JNI static linking spec. >> >> In this context would it be reasonable to add another statement: >> If a /dynamically linked/ agent L exports a function called Agent_OnLoad_L, >> the Agent_OnLoad_L function will be ignored. >> I'd rather leave this undefined since the behavior is very platform specific. The way we determine if a library is statically linked is by the presence of the Agent_OnLoad_L function. If this function exists in a dynamically linked library, it will be treated as a static library if by some chance it's attempted to be loaded twice, since the symbol will may be visible in the running process. Bob. >> The same questions apply to the Agent_OnAttach and Agent_OnAttach_L entry points. >> > I'm out on vacation for a couple of weeks so I'll leave it up to Bob V. and yourself if you guys want to hash out better/different wording. > > bill >> >> Thanks, >> Serguei >> >> >> On 7/30/13 12:17 PM, bill.pittore at oracle.com wrote: >>> Thanks Serguei for the comments. Some comments inline. I updated the webrevs at >>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>> >>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>> >>> >>> On 7/26/2013 5:00 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi Bill, >>>> >>>> Sorry for the big delay. >>>> >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>> >>>> >>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>> >>>> >>>> I'm suggesting to use the reference *Agent_OnAttach[_L]**||* even more consistently. >>>> (If, in some cases, you prefer the longer form to underline the difference between >>>> dynamically and statically linked libraries then feel free to leave it as it is.) >>>> >>>> It would simplify the following fragments: >>>> >>>> 304 * It then causes the target VM to invoke the Agent_OnAttach function >>>> 305 * or, for a statically linked agent named 'L', the Agent_OnAttach_L function >>>> ==> >>>> >>>> 304 * It then causes the target VM to invoke the Agent_OnAttach[_L] function >>>> >>>> 409 * It then causes the target VM to invoke the Agent_OnAttach >>>> 410 * function or, for a statically linked agent named 'L', the >>>> 411 * Agent_OnAttach_L function as specified in the >>>> ==> >>>> 409 * It then causes the target VM to invoke the Agent_OnAttach[_L] >>>> 410 * function as specified in the >>>> >>> I left the above as is since it's part of the method description. The following fragments below I simplified as you suggested. >>> >>>> >>>> the following 4 identical fragments: >>>> >>>> 341 * If the Agent_OnAttach function returns an error >>>> 342 * or, for a statically linked agent named 'L', if the >>>> 343 * Agent_OnAttach_L function returns >>>> 344 * an error. >>>> 375 * If the Agent_OnAttach function returns an error >>>> 376 * or, for a statically linked agent named 'L', if the >>>> 377 * Agent_OnAttach_L function returns >>>> 378 * an error. >>>> 442 * If the Agent_OnAttach function returns an error >>>> 443 * or, for a statically linked agent named 'L', if the >>>> 444 * Agent_OnAttach_L function returns an error >>>> 475 * If the Agent_OnAttach function returns an error >>>> 476 * or, for a statically linked agent named 'L', if the >>>> 477 * Agent_OnAttach_L function returns >>>> 478 * an error. >>>> ==> >>>> >>>> 336 * If the Agent_OnAttach[_L] function returns an error. >>>> >>> >>>> >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>> >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>> src/share/vm/prims/jvmti.xml >>>> >>>> Lines 442-462: many extra

's. The fragment does not look well. >>>> I'd suggest to remove most of them. >>>> Also, these lines are too long. Could you make them shorter, please? >>>> The same is applied to other long new lines in this file. >>> Cleaned this up a bit. >>>> >>>> Lines 490-491, 502-503, 505-506: >>>> The same sentence is repeated 3 times: "the agent library may be statically linked ..." >>>> >>>> 490 Note that the agent library may be statically linked into the executable >>>> 491 in which case no actual loading takes place. >>> Fixed. >>>> >>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is specified, the VM will attempt to >>>> 502 load the shared library c:\myLibs\foo.dll. As mentioned above, the agent library may be statically linked into the executable >>>> 503 in which case no actual loading takes place >>>> >>>> 505 Note that the agent library may be statically linked into the executable >>>> 506 in which case no actual loading takes place. >>>> >>> Tweaked the above a bit to make it less wordy. >>> >>>> Lines 677-678: The dot is missed at the end of line 677: >>>> >>>> 677 and enabled the event >>>> >>> Fixed. >>>> >>>> src/os/posix/vm/os_posix.cpp >>>> >>>> - no comments >>>> >>>> src/os/windows/vm/os_windows.cpp >>>> >>>> - no comments >>>> >>>> src/share/vm/prims/jvmtiExport.cpp >>>> >>>> - no comments >>>> >>>> src/share/vm/runtime/arguments.hpp >>>> >>>> - no comments >>>> >>>> src/share/vm/runtime/os.cpp >>>> >>>> Space is missed after the 'if': >>>> 471 if(entryName != NULL) { >>>> >>> Fixed. >>>> Extra space after the '*': >>>> 483 void * saveHandle; >>>> >>> Fixed. >>>> src/share/vm/runtime/os.hpp >>>> >>>> - no comments >>>> >>>> src/share/vm/runtime/thread.cpp >>>> >>>> The line has been removed: >>>> 3866 break; >>>> >>> Correct, the inner for loop was removed so no need for the break; >>>> >>>> I'm still in process of reading the code. >>>> Another pass is needed to make sure that nothing is missed. >>>> But in general, the code quality is pretty good. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: >>>>> Still need an official reviewer for the hotspot changes for statically linked agents. >>>>> >>>>> thanks, >>>>> bill >>>>> >>>>>> These changes address bug 8014135 which adds support for statically linked agents in the VM. This is a followup to the recent JNI spec changes that addressed statically linked JNI libraries( 8005716). >>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>> http://openjdk.java.net/jeps/178 >>>>>> >>>>>> Webrevs are here: >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>> >>>>>> The changes to jvmti.xml can also be seen in the output file that I placed here: >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>> >>>>>> Thanks, >>>>>> bill >>>>>> >>>>> >>>> >>> >>> >> > From vladimir.danushevsky at oracle.com Mon Aug 5 07:43:57 2013 From: vladimir.danushevsky at oracle.com (Vladimir Danushevsky) Date: Mon, 5 Aug 2013 10:43:57 -0400 Subject: RFR: 8006971: More missing barriers in taskqueues for RMO architectures In-Reply-To: <51FCE13C.30304@oracle.com> References: <51FCE13C.30304@oracle.com> Message-ID: <1F6A1982-00D8-4291-B639-9EB4C07CD24E@oracle.com> Hi David, On Aug 3, 2013, at 6:53 AM, David Holmes wrote: > Vlad, > > On 2/08/2013 11:57 PM, Vladimir Danushevsky wrote: >> The issue of missing memory barriers in the GC taskqueue code was first flagged here: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >> >> JDK7u40 fix for the same issue is located here: >> http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ >> >> >> Initially we planned to port same solution to JDK8 however after reviewing the algorithm more we've started questioning a need for a full fence in between 'age' and 'bottom' elements. Since the intent is to keep 'bottom' memory reference from being executed before 'age' would a LoadLoad barrier (which in many cases is a cheaper solution) be sufficient? If so, the webrev below could possible be an adequate solution. >> >> http://cr.openjdk.java.net/~vladidan/8006971/webrev.00/ >> >> We have tested both cases (fence and LL) on a hexa-core Power5 box running several test suites that currently expose the problem. The results are positive. > > The loadload() should not be in any ifdef. The loadload() is part of the algorithmic correctness. The loadload() will become a no-op on any platform that does not need to do anything special to preserve the ordering. As I understand LL is not an issue on platforms that are excluded from emitting the barrier in the provided patch. However I went to read further discussion at http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html and seems the concern is the Store is not guaranteed to propagate to all observers if read before the Writer's side 'sync'. I speculate that might not be an issue on PowerPC implementations with L1 cache snooping though, but even if this a case there is no robust way to detect that in runtime. But that is likely not an issue on ARM (not sure about IA64, as it was listed in the very first webrev from Goetz) therefore we might inject OrderAccess::fence() for PPC (both 32- and 64-bit) and OrderAccess::loadload() for ARM (again, need info on IA64). That being said , for simplicity we can go with fence() for ARM case too since current ARMv7 implementations do not imply a separate barrier instruction for Loads. So in other words use same patch as in JDK7u40: http://cr.openjdk.java.net/~vladidan/8006971/webrev.01 Thanks, Vlad > > Thanks, > David > >> As a side note - >> perhaps it is possible to eliminate age/bottom potential reordering by loading both simultaneously through an Atomic class method. That would require though some structural changes to the layout of TaskQueueSuper class to align both fields together and ensure proper integer alignment (depending on 32/64-bit port), therefore this solution is less practical for the short term. >> >> Thanks, >> Vlad >> From omajid at redhat.com Mon Aug 5 08:22:17 2013 From: omajid at redhat.com (Omair Majid) Date: Mon, 05 Aug 2013 11:22:17 -0400 Subject: Make zero compile after 8016131 and 8016697 In-Reply-To: <51FEEA76.5050201@oracle.com> References: <51FEAAFC.109@redhat.com> <51FEEA76.5050201@oracle.com> Message-ID: <51FFC329.5060001@redhat.com> Hi David, On 08/04/2013 07:57 PM, David Holmes wrote: > On 5/08/2013 5:26 AM, Omair Majid wrote: > I've filed 8022188 for this and will sponsor it for you. > >> Any concerns with the patch? > > Nope. Reviewed. Thank you! Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From bob.vandette at oracle.com Mon Aug 5 10:59:48 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 5 Aug 2013 13:59:48 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51FC884C.20407@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <51FC884C.20407@oracle.com> Message-ID: <690FEAD4-3147-4C8D-96EC-7B5C91AC27E4@oracle.com> Serguei, Are you ok with the webrev at this point or are you waiting for any changes from Bill? I've asked Coleen to review the code since she's an official Reviewer but she'd like to make sure the serviceability team is ok with the changes. Bob. On Aug 3, 2013, at 12:34 AM, serguei.spitsyn at oracle.com wrote: > On 8/2/13 8:11 PM, Bill Pittore wrote: >> On 8/2/2013 9:12 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Bill, >>> >>> A couple of more questions. >>> >>> webrev.01/jvmti.html >>> >>> An agent L whose image has been combined with the VM *is defined* as /statically linked/ >>> if and only if the agent exports a function called Agent_OnLoad_L. >>> >>> A question to the above. >>> Are we going to allow to link a library dynamically if it exports both >>> the Agent_OnLoad and Agent_OnLoad_L functions? >>> It can be convenient if a library exports both Agent_OnLoad and Agent_OnLoad_L >>> as it can be linked statically or dynamically depending on the need without changes. >>> >> It would be nice but the problem is that you could only link one agent into the VM if it exported Agent_OnLoad. Otherwise there would be a symbol collision with the second agent you linked in that also had Agent_OnLoad. As an agent developer you will have to select one or the other at build time, either statically linked in or dynamic. > > I did not want to use the Agent_OnLoad for statically linked agent. > Just wanted to say that the presence of the Agent_OnLoad_L must be ignored > if the agent is linked dynamically. > Maybe this rule needs to be clearly stated in the JVMTI spec. > >>> You already added the following statement to the JVMTI spec: >>> If a /statically linked/ agent L exports a function called Agent_OnLoad_L and >>> a function called Agent_OnLoad, the Agent_OnLoad function will be ignored. >>> >>> Could we say it in a shorter form?: >>> If a /statically linked/ agent L exports a function called Agent_OnLoad, >>> the Agent_OnLoad function will be ignored. >> I believe I copied this from JNI static linking JEP. If so, I'll probably leave it as is just for consistency with JNI static spec. JVM TI static linking spec is closely related to JNI static linking spec. > > I see. Then it is Ok with me. > >>> >>> In this context would it be reasonable to add another statement: >>> If a /dynamically linked/ agent L exports a function called Agent_OnLoad_L, >>> the Agent_OnLoad_L function will be ignored. >>> >>> The same questions apply to the Agent_OnAttach and Agent_OnAttach_L entry points. >>> >> I'm out on vacation for a couple of weeks so I'll leave it up to Bob V. and yourself if you guys want to hash out better/different wording. > > Thank you for the quick reply, and have a nice vacation! > > Thanks, > Serguei > >> >> bill >>> >>> Thanks, >>> Serguei >>> >>> >>> On 7/30/13 12:17 PM, bill.pittore at oracle.com wrote: >>>> Thanks Serguei for the comments. Some comments inline. I updated the webrevs at >>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>> >>>> >>>> On 7/26/2013 5:00 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Bill, >>>>> >>>>> Sorry for the big delay. >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>> >>>>> >>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>> >>>>> >>>>> I'm suggesting to use the reference *Agent_OnAttach[_L]**||* even more consistently. >>>>> (If, in some cases, you prefer the longer form to underline the difference between >>>>> dynamically and statically linked libraries then feel free to leave it as it is.) >>>>> >>>>> It would simplify the following fragments: >>>>> >>>>> 304 * It then causes the target VM to invoke the Agent_OnAttach function >>>>> 305 * or, for a statically linked agent named 'L', the Agent_OnAttach_L function >>>>> ==> >>>>> >>>>> 304 * It then causes the target VM to invoke the Agent_OnAttach[_L] function >>>>> >>>>> 409 * It then causes the target VM to invoke the Agent_OnAttach >>>>> 410 * function or, for a statically linked agent named 'L', the >>>>> 411 * Agent_OnAttach_L function as specified in the >>>>> ==> >>>>> 409 * It then causes the target VM to invoke the Agent_OnAttach[_L] >>>>> 410 * function as specified in the >>>>> >>>> I left the above as is since it's part of the method description. The following fragments below I simplified as you suggested. >>>> >>>>> >>>>> the following 4 identical fragments: >>>>> >>>>> 341 * If the Agent_OnAttach function returns an error >>>>> 342 * or, for a statically linked agent named 'L', if the >>>>> 343 * Agent_OnAttach_L function returns >>>>> 344 * an error. >>>>> 375 * If the Agent_OnAttach function returns an error >>>>> 376 * or, for a statically linked agent named 'L', if the >>>>> 377 * Agent_OnAttach_L function returns >>>>> 378 * an error. >>>>> 442 * If the Agent_OnAttach function returns an error >>>>> 443 * or, for a statically linked agent named 'L', if the >>>>> 444 * Agent_OnAttach_L function returns an error >>>>> 475 * If the Agent_OnAttach function returns an error >>>>> 476 * or, for a statically linked agent named 'L', if the >>>>> 477 * Agent_OnAttach_L function returns >>>>> 478 * an error. >>>>> ==> >>>>> >>>>> 336 * If the Agent_OnAttach[_L] function returns an error. >>>>> >>>> >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>> src/share/vm/prims/jvmti.xml >>>>> >>>>> Lines 442-462: many extra

's. The fragment does not look well. >>>>> I'd suggest to remove most of them. >>>>> Also, these lines are too long. Could you make them shorter, please? >>>>> The same is applied to other long new lines in this file. >>>> Cleaned this up a bit. >>>>> >>>>> Lines 490-491, 502-503, 505-506: >>>>> The same sentence is repeated 3 times: "the agent library may be statically linked ..." >>>>> >>>>> 490 Note that the agent library may be statically linked into the executable >>>>> 491 in which case no actual loading takes place. >>>> Fixed. >>>>> >>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is specified, the VM will attempt to >>>>> 502 load the shared library c:\myLibs\foo.dll. As mentioned above, the agent library may be statically linked into the executable >>>>> 503 in which case no actual loading takes place >>>>> >>>>> 505 Note that the agent library may be statically linked into the executable >>>>> 506 in which case no actual loading takes place. >>>>> >>>> Tweaked the above a bit to make it less wordy. >>>> >>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>> >>>>> 677 and enabled the event >>>>> >>>> Fixed. >>>>> >>>>> src/os/posix/vm/os_posix.cpp >>>>> >>>>> - no comments >>>>> >>>>> src/os/windows/vm/os_windows.cpp >>>>> >>>>> - no comments >>>>> >>>>> src/share/vm/prims/jvmtiExport.cpp >>>>> >>>>> - no comments >>>>> >>>>> src/share/vm/runtime/arguments.hpp >>>>> >>>>> - no comments >>>>> >>>>> src/share/vm/runtime/os.cpp >>>>> >>>>> Space is missed after the 'if': >>>>> 471 if(entryName != NULL) { >>>>> >>>> Fixed. >>>>> Extra space after the '*': >>>>> 483 void * saveHandle; >>>>> >>>> Fixed. >>>>> src/share/vm/runtime/os.hpp >>>>> >>>>> - no comments >>>>> >>>>> src/share/vm/runtime/thread.cpp >>>>> >>>>> The line has been removed: >>>>> 3866 break; >>>>> >>>> Correct, the inner for loop was removed so no need for the break; >>>>> >>>>> I'm still in process of reading the code. >>>>> Another pass is needed to make sure that nothing is missed. >>>>> But in general, the code quality is pretty good. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: >>>>>> Still need an official reviewer for the hotspot changes for statically linked agents. >>>>>> >>>>>> thanks, >>>>>> bill >>>>>> >>>>>>> These changes address bug 8014135 which adds support for statically linked agents in the VM. This is a followup to the recent JNI spec changes that addressed statically linked JNI libraries( 8005716). >>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>> http://openjdk.java.net/jeps/178 >>>>>>> >>>>>>> Webrevs are here: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>> >>>>>>> The changes to jvmti.xml can also be seen in the output file that I placed here: >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>> >>>>>>> Thanks, >>>>>>> bill >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Mon Aug 5 11:59:42 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 05 Aug 2013 11:59:42 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <690FEAD4-3147-4C8D-96EC-7B5C91AC27E4@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <51FC884C.20407@oracle.com> <690FEAD4-3147-4C8D-96EC-7B5C91AC27E4@oracle.com> Message-ID: <51FFF61E.1020509@oracle.com> Bob, I'm not waiting for any changes from Bill at the moment but still reading the code. Sorry for the latency but it takes time as not everything is clear to me yet. Thanks, Serguei On 8/5/13 10:59 AM, Bob Vandette wrote: > Serguei, > > Are you ok with the webrev at this point or are you waiting for any changes from Bill? > > I've asked Coleen to review the code since she's an official Reviewer but she'd like to make > sure the serviceability team is ok with the changes. > > Bob. > > > On Aug 3, 2013, at 12:34 AM, serguei.spitsyn at oracle.com wrote: > >> On 8/2/13 8:11 PM, Bill Pittore wrote: >>> On 8/2/2013 9:12 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Bill, >>>> >>>> A couple of more questions. >>>> >>>> webrev.01/jvmti.html >>>> >>>> An agent L whose image has been combined with the VM *is defined* as /statically linked/ >>>> if and only if the agent exports a function called Agent_OnLoad_L. >>>> >>>> A question to the above. >>>> Are we going to allow to link a library dynamically if it exports both >>>> the Agent_OnLoad and Agent_OnLoad_L functions? >>>> It can be convenient if a library exports both Agent_OnLoad and Agent_OnLoad_L >>>> as it can be linked statically or dynamically depending on the need without changes. >>>> >>> It would be nice but the problem is that you could only link one agent into the VM if it exported Agent_OnLoad. Otherwise there would be a symbol collision with the second agent you linked in that also had Agent_OnLoad. As an agent developer you will have to select one or the other at build time, either statically linked in or dynamic. >> I did not want to use the Agent_OnLoad for statically linked agent. >> Just wanted to say that the presence of the Agent_OnLoad_L must be ignored >> if the agent is linked dynamically. >> Maybe this rule needs to be clearly stated in the JVMTI spec. >> >>>> You already added the following statement to the JVMTI spec: >>>> If a /statically linked/ agent L exports a function called Agent_OnLoad_L and >>>> a function called Agent_OnLoad, the Agent_OnLoad function will be ignored. >>>> >>>> Could we say it in a shorter form?: >>>> If a /statically linked/ agent L exports a function called Agent_OnLoad, >>>> the Agent_OnLoad function will be ignored. >>> I believe I copied this from JNI static linking JEP. If so, I'll probably leave it as is just for consistency with JNI static spec. JVM TI static linking spec is closely related to JNI static linking spec. >> I see. Then it is Ok with me. >> >>>> In this context would it be reasonable to add another statement: >>>> If a /dynamically linked/ agent L exports a function called Agent_OnLoad_L, >>>> the Agent_OnLoad_L function will be ignored. >>>> >>>> The same questions apply to the Agent_OnAttach and Agent_OnAttach_L entry points. >>>> >>> I'm out on vacation for a couple of weeks so I'll leave it up to Bob V. and yourself if you guys want to hash out better/different wording. >> Thank you for the quick reply, and have a nice vacation! >> >> Thanks, >> Serguei >> >>> bill >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 7/30/13 12:17 PM, bill.pittore at oracle.com wrote: >>>>> Thanks Serguei for the comments. Some comments inline. I updated the webrevs at >>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>>> >>>>> >>>>> On 7/26/2013 5:00 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Bill, >>>>>> >>>>>> Sorry for the big delay. >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>>> >>>>>> >>>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>>> >>>>>> >>>>>> I'm suggesting to use the reference *Agent_OnAttach[_L]**||* even more consistently. >>>>>> (If, in some cases, you prefer the longer form to underline the difference between >>>>>> dynamically and statically linked libraries then feel free to leave it as it is.) >>>>>> >>>>>> It would simplify the following fragments: >>>>>> >>>>>> 304 * It then causes the target VM to invoke the Agent_OnAttach function >>>>>> 305 * or, for a statically linked agent named 'L', the Agent_OnAttach_L function >>>>>> ==> >>>>>> >>>>>> 304 * It then causes the target VM to invoke the Agent_OnAttach[_L] function >>>>>> >>>>>> 409 * It then causes the target VM to invoke the Agent_OnAttach >>>>>> 410 * function or, for a statically linked agent named 'L', the >>>>>> 411 * Agent_OnAttach_L function as specified in the >>>>>> ==> >>>>>> 409 * It then causes the target VM to invoke the Agent_OnAttach[_L] >>>>>> 410 * function as specified in the >>>>>> >>>>> I left the above as is since it's part of the method description. The following fragments below I simplified as you suggested. >>>>> >>>>>> the following 4 identical fragments: >>>>>> >>>>>> 341 * If the Agent_OnAttach function returns an error >>>>>> 342 * or, for a statically linked agent named 'L', if the >>>>>> 343 * Agent_OnAttach_L function returns >>>>>> 344 * an error. >>>>>> 375 * If the Agent_OnAttach function returns an error >>>>>> 376 * or, for a statically linked agent named 'L', if the >>>>>> 377 * Agent_OnAttach_L function returns >>>>>> 378 * an error. >>>>>> 442 * If the Agent_OnAttach function returns an error >>>>>> 443 * or, for a statically linked agent named 'L', if the >>>>>> 444 * Agent_OnAttach_L function returns an error >>>>>> 475 * If the Agent_OnAttach function returns an error >>>>>> 476 * or, for a statically linked agent named 'L', if the >>>>>> 477 * Agent_OnAttach_L function returns >>>>>> 478 * an error. >>>>>> ==> >>>>>> >>>>>> 336 * If the Agent_OnAttach[_L] function returns an error. >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>> src/share/vm/prims/jvmti.xml >>>>>> >>>>>> Lines 442-462: many extra

's. The fragment does not look well. >>>>>> I'd suggest to remove most of them. >>>>>> Also, these lines are too long. Could you make them shorter, please? >>>>>> The same is applied to other long new lines in this file. >>>>> Cleaned this up a bit. >>>>>> Lines 490-491, 502-503, 505-506: >>>>>> The same sentence is repeated 3 times: "the agent library may be statically linked ..." >>>>>> >>>>>> 490 Note that the agent library may be statically linked into the executable >>>>>> 491 in which case no actual loading takes place. >>>>> Fixed. >>>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is specified, the VM will attempt to >>>>>> 502 load the shared library c:\myLibs\foo.dll. As mentioned above, the agent library may be statically linked into the executable >>>>>> 503 in which case no actual loading takes place >>>>>> >>>>>> 505 Note that the agent library may be statically linked into the executable >>>>>> 506 in which case no actual loading takes place. >>>>>> >>>>> Tweaked the above a bit to make it less wordy. >>>>> >>>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>>> >>>>>> 677 and enabled the event >>>>>> >>>>> Fixed. >>>>>> src/os/posix/vm/os_posix.cpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/os/windows/vm/os_windows.cpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/share/vm/prims/jvmtiExport.cpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/share/vm/runtime/arguments.hpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/share/vm/runtime/os.cpp >>>>>> >>>>>> Space is missed after the 'if': >>>>>> 471 if(entryName != NULL) { >>>>>> >>>>> Fixed. >>>>>> Extra space after the '*': >>>>>> 483 void * saveHandle; >>>>>> >>>>> Fixed. >>>>>> src/share/vm/runtime/os.hpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/share/vm/runtime/thread.cpp >>>>>> >>>>>> The line has been removed: >>>>>> 3866 break; >>>>>> >>>>> Correct, the inner for loop was removed so no need for the break; >>>>>> I'm still in process of reading the code. >>>>>> Another pass is needed to make sure that nothing is missed. >>>>>> But in general, the code quality is pretty good. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: >>>>>>> Still need an official reviewer for the hotspot changes for statically linked agents. >>>>>>> >>>>>>> thanks, >>>>>>> bill >>>>>>> >>>>>>>> These changes address bug 8014135 which adds support for statically linked agents in the VM. This is a followup to the recent JNI spec changes that addressed statically linked JNI libraries( 8005716). >>>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>>> http://openjdk.java.net/jeps/178 >>>>>>>> >>>>>>>> Webrevs are here: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>> >>>>>>>> The changes to jvmti.xml can also be seen in the output file that I placed here: >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>> >>>>>>>> Thanks, >>>>>>>> bill >>>>>>>> >>>>> From coleen.phillimore at oracle.com Mon Aug 5 15:13:06 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 05 Aug 2013 18:13:06 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> Message-ID: <52002372.2030302@oracle.com> Hi Bill, I have some high level comments and other comments. This wasn't as easy to review as Bob promised me! http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/src/share/classes/com/sun/tools/attach/VirtualMachine.java.udiff.html paramter (typo - two instances) * @throws AgentInitializationException - * If the Agent_OnAttach function returns an error + * If the Agent_OnAttach[_L] function returns an error. + * an error. * http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/os/posix/vm/os_posix.cpp.frames.html nameLen, prefixLen, suffixLen - the JVM coding convention (unlike Java) is to have variable names lower case and separated by a _ (not camelcase). Same for all the new code here buildAgentFunctionName. Can you put a function above this function to say what it does? So once it's code reviewed, we can quickly know what it does without having to study this again - ie. Is name something like libxxx.so and you're trying to extract lib and .so from it? There's no verification of this at lines 286 and 287 but the code is handling the case of other sorts of unexpected input (ie line 283). Why don't you strip the lib and the .so if !is_absolute_path? 291 agentEntryName = NEW_C_HEAP_ARRAY(char, len, mtThread); 292 if (agentEntryName == NULL) { 293 return NULL; 294 } If NEW_C_HEAP_ARRAY fails it terminates the JVM. I think you might want this function instead NEW_C_HEAP_ARRAY_RETURN_NULL if there's a reasonable recovery possible. os_windows.cpp Same comments as above. Also: 5432 strncat(agentEntryName, name, nameLen); 5433 strcat(agentEntryName, p); 5434 //agentEntryName == _Agent_OnLoad_libName at 12 5435 } else { You could say why 12 but shouldn't it be the length of the resulting symbol instead and not 12? http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/os.cpp.frames.html findAgentFunction - same comment about the coding conventions. functions and variables are lower case with underscores. Class names are CamelCase. It would be convenient if the jvm code used the java coding convention but the rest of it doesn't so this new code is inconsistent. This is hard to follow as it is! http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/thread.cpp.frames.html 3826 size_t num_symbol_entries = sizeof(on_unload_symbols) / sizeof(char*); Why not use ARRAY_SIZE macro? http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/prims/jvmtiExport.cpp.frames.html 2208 // Check for builtin agent. If not then if the path is absolute we attempt 2209 // to load the library. Otherwise we try to load it from the standard 2210 // dll directory. I think you are missing the word "found" in this sentence. You are using builtin agent to mean agent defined in a statically linked library, I believe. Can you say that instead? Builtin means that the jvm knows about it and implements it but in this case it doesn't. Maybe find_statically_linked_agent() would be a better name for this function? Is the is_valid() function really mean has_been_loaded()? 2236 if (agentLib->valid()) { Did you run the Internal NSK vm.quick.testlist tests on this to verify that nothing breaks? There are a lot of tests with different agents and combinations in that suite and it frequently holds some surprises in this area so best to run it first. Let me know if you need help. Coleen On 08/05/2013 10:41 AM, Bob Vandette wrote: > On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: > >> On 8/2/2013 9:12 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Bill, >>> >>> A couple of more questions. >>> >>> webrev.01/jvmti.html >>> >>> An agent L whose image has been combined with the VM *is defined* as /statically linked/ >>> if and only if the agent exports a function called Agent_OnLoad_L. >>> >>> A question to the above. >>> Are we going to allow to link a library dynamically if it exports both >>> the Agent_OnLoad and Agent_OnLoad_L functions? >>> It can be convenient if a library exports both Agent_OnLoad and Agent_OnLoad_L >>> as it can be linked statically or dynamically depending on the need without changes. >>> >> It would be nice but the problem is that you could only link one agent into the VM if it exported Agent_OnLoad. Otherwise there would be a symbol collision with the second agent you linked in that also had Agent_OnLoad. As an agent developer you will have to select one or the other at build time, either statically linked in or dynamic. >>> You already added the following statement to the JVMTI spec: >>> If a /statically linked/ agent L exports a function called Agent_OnLoad_L and >>> a function called Agent_OnLoad, the Agent_OnLoad function will be ignored. >>> >>> Could we say it in a shorter form?: >>> If a /statically linked/ agent L exports a function called Agent_OnLoad, >>> the Agent_OnLoad function will be ignored. >> I believe I copied this from JNI static linking JEP. If so, I'll probably leave it as is just for consistency with JNI static spec. JVM TI static linking spec is closely related to JNI static linking spec. >>> In this context would it be reasonable to add another statement: >>> If a /dynamically linked/ agent L exports a function called Agent_OnLoad_L, >>> the Agent_OnLoad_L function will be ignored. >>> > I'd rather leave this undefined since the behavior is very platform specific. > The way we determine if a library is statically linked is by the presence of the Agent_OnLoad_L function. > If this function exists in a dynamically linked library, it will be treated as a static library if by some chance > it's attempted to be loaded twice, since the symbol will may be visible in the running process. > > Bob. > > >>> The same questions apply to the Agent_OnAttach and Agent_OnAttach_L entry points. >>> >> I'm out on vacation for a couple of weeks so I'll leave it up to Bob V. and yourself if you guys want to hash out better/different wording. >> >> bill >>> Thanks, >>> Serguei >>> >>> >>> On 7/30/13 12:17 PM, bill.pittore at oracle.com wrote: >>>> Thanks Serguei for the comments. Some comments inline. I updated the webrevs at >>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>> >>>> >>>> On 7/26/2013 5:00 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Bill, >>>>> >>>>> Sorry for the big delay. >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>> >>>>> >>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>> >>>>> >>>>> I'm suggesting to use the reference *Agent_OnAttach[_L]**||* even more consistently. >>>>> (If, in some cases, you prefer the longer form to underline the difference between >>>>> dynamically and statically linked libraries then feel free to leave it as it is.) >>>>> >>>>> It would simplify the following fragments: >>>>> >>>>> 304 * It then causes the target VM to invoke the Agent_OnAttach function >>>>> 305 * or, for a statically linked agent named 'L', the Agent_OnAttach_L function >>>>> ==> >>>>> >>>>> 304 * It then causes the target VM to invoke the Agent_OnAttach[_L] function >>>>> >>>>> 409 * It then causes the target VM to invoke the Agent_OnAttach >>>>> 410 * function or, for a statically linked agent named 'L', the >>>>> 411 * Agent_OnAttach_L function as specified in the >>>>> ==> >>>>> 409 * It then causes the target VM to invoke the Agent_OnAttach[_L] >>>>> 410 * function as specified in the >>>>> >>>> I left the above as is since it's part of the method description. The following fragments below I simplified as you suggested. >>>> >>>>> the following 4 identical fragments: >>>>> >>>>> 341 * If the Agent_OnAttach function returns an error >>>>> 342 * or, for a statically linked agent named 'L', if the >>>>> 343 * Agent_OnAttach_L function returns >>>>> 344 * an error. >>>>> 375 * If the Agent_OnAttach function returns an error >>>>> 376 * or, for a statically linked agent named 'L', if the >>>>> 377 * Agent_OnAttach_L function returns >>>>> 378 * an error. >>>>> 442 * If the Agent_OnAttach function returns an error >>>>> 443 * or, for a statically linked agent named 'L', if the >>>>> 444 * Agent_OnAttach_L function returns an error >>>>> 475 * If the Agent_OnAttach function returns an error >>>>> 476 * or, for a statically linked agent named 'L', if the >>>>> 477 * Agent_OnAttach_L function returns >>>>> 478 * an error. >>>>> ==> >>>>> >>>>> 336 * If the Agent_OnAttach[_L] function returns an error. >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>> src/share/vm/prims/jvmti.xml >>>>> >>>>> Lines 442-462: many extra

's. The fragment does not look well. >>>>> I'd suggest to remove most of them. >>>>> Also, these lines are too long. Could you make them shorter, please? >>>>> The same is applied to other long new lines in this file. >>>> Cleaned this up a bit. >>>>> Lines 490-491, 502-503, 505-506: >>>>> The same sentence is repeated 3 times: "the agent library may be statically linked ..." >>>>> >>>>> 490 Note that the agent library may be statically linked into the executable >>>>> 491 in which case no actual loading takes place. >>>> Fixed. >>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is specified, the VM will attempt to >>>>> 502 load the shared library c:\myLibs\foo.dll. As mentioned above, the agent library may be statically linked into the executable >>>>> 503 in which case no actual loading takes place >>>>> >>>>> 505 Note that the agent library may be statically linked into the executable >>>>> 506 in which case no actual loading takes place. >>>>> >>>> Tweaked the above a bit to make it less wordy. >>>> >>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>> >>>>> 677 and enabled the event >>>>> >>>> Fixed. >>>>> src/os/posix/vm/os_posix.cpp >>>>> >>>>> - no comments >>>>> >>>>> src/os/windows/vm/os_windows.cpp >>>>> >>>>> - no comments >>>>> >>>>> src/share/vm/prims/jvmtiExport.cpp >>>>> >>>>> - no comments >>>>> >>>>> src/share/vm/runtime/arguments.hpp >>>>> >>>>> - no comments >>>>> >>>>> src/share/vm/runtime/os.cpp >>>>> >>>>> Space is missed after the 'if': >>>>> 471 if(entryName != NULL) { >>>>> >>>> Fixed. >>>>> Extra space after the '*': >>>>> 483 void * saveHandle; >>>>> >>>> Fixed. >>>>> src/share/vm/runtime/os.hpp >>>>> >>>>> - no comments >>>>> >>>>> src/share/vm/runtime/thread.cpp >>>>> >>>>> The line has been removed: >>>>> 3866 break; >>>>> >>>> Correct, the inner for loop was removed so no need for the break; >>>>> I'm still in process of reading the code. >>>>> Another pass is needed to make sure that nothing is missed. >>>>> But in general, the code quality is pretty good. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: >>>>>> Still need an official reviewer for the hotspot changes for statically linked agents. >>>>>> >>>>>> thanks, >>>>>> bill >>>>>> >>>>>>> These changes address bug 8014135 which adds support for statically linked agents in the VM. This is a followup to the recent JNI spec changes that addressed statically linked JNI libraries( 8005716). >>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>> http://openjdk.java.net/jeps/178 >>>>>>> >>>>>>> Webrevs are here: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>> >>>>>>> The changes to jvmti.xml can also be seen in the output file that I placed here: >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>> >>>>>>> Thanks, >>>>>>> bill >>>>>>> >>>> From coleen.phillimore at oracle.com Mon Aug 5 15:27:38 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 05 Aug 2013 18:27:38 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <52002372.2030302@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <52002372.2030302@oracle.com> Message-ID: <520026DA.8000206@oracle.com> On 08/05/2013 06:13 PM, Coleen Phillimore wrote: > an you put a function above this function to say what it does? So once > it's code reviewed, we can quickly know what it does without having to I mean comment, not function! Coleen From david.holmes at oracle.com Mon Aug 5 18:01:59 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 06 Aug 2013 11:01:59 +1000 Subject: RFR: 8006971: More missing barriers in taskqueues for RMO architectures In-Reply-To: <1F6A1982-00D8-4291-B639-9EB4C07CD24E@oracle.com> References: <51FCE13C.30304@oracle.com> <1F6A1982-00D8-4291-B639-9EB4C07CD24E@oracle.com> Message-ID: <52004B07.3050103@oracle.com> Hi Vlad On 6/08/2013 12:43 AM, Vladimir Danushevsky wrote: > On Aug 3, 2013, at 6:53 AM, David Holmes wrote: >> On 2/08/2013 11:57 PM, Vladimir Danushevsky wrote: >>> The issue of missing memory barriers in the GC taskqueue code was first flagged here: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >>> >>> JDK7u40 fix for the same issue is located here: >>> http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ >>> >>> >>> Initially we planned to port same solution to JDK8 however after reviewing the algorithm more we've started questioning a need for a full fence in between 'age' and 'bottom' elements. Since the intent is to keep 'bottom' memory reference from being executed before 'age' would a LoadLoad barrier (which in many cases is a cheaper solution) be sufficient? If so, the webrev below could possible be an adequate solution. >>> >>> http://cr.openjdk.java.net/~vladidan/8006971/webrev.00/ >>> >>> We have tested both cases (fence and LL) on a hexa-core Power5 box running several test suites that currently expose the problem. The results are positive. >> >> The loadload() should not be in any ifdef. The loadload() is part of the algorithmic correctness. The loadload() will become a no-op on any platform that does not need to do anything special to preserve the ordering. > > As I understand LL is not an issue on platforms that are excluded from emitting the barrier in the provided patch. > > However I went to read further discussion at > http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html > and seems the concern is the Store is not guaranteed to propagate to all observers if read before the Writer's side 'sync'. I speculate that might not be an issue on PowerPC implementations with L1 cache snooping though, but even if this a case there is no robust way to detect that in runtime. That sounds like the fence() is missing on the writer side. > But that is likely not an issue on ARM (not sure about IA64, as it was listed in the very first webrev from Goetz) therefore we might inject OrderAccess::fence() for PPC (both 32- and 64-bit) and OrderAccess::loadload() for ARM (again, need info on IA64). > That being said , for simplicity we can go with fence() for ARM case too since current ARMv7 implementations do not imply a separate barrier instruction for Loads. > > So in other words use same patch as in JDK7u40: > http://cr.openjdk.java.net/~vladidan/8006971/webrev.01 I think this is masking the real problem with the algorithm but unless we get some true expertise involved here I don't see how we will resolve this. And time is now critical. So I will accept the 7u version of the fix under the same rationale as for 7u. We do need this to be fixed. Reviewed. I hope this is not the end of it though as this data structure needs to be revisited in my opinion. We need a second reviewer. Thanks, David > Thanks, > Vlad > >> >> Thanks, >> David >> >>> As a side note - >>> perhaps it is possible to eliminate age/bottom potential reordering by loading both simultaneously through an Atomic class method. That would require though some structural changes to the layout of TaskQueueSuper class to align both fields together and ensure proper integer alignment (depending on 32/64-bit port), therefore this solution is less practical for the short term. >>> >>> Thanks, >>> Vlad >>> > From serguei.spitsyn at oracle.com Mon Aug 5 18:55:17 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 05 Aug 2013 18:55:17 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <52002372.2030302@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <52002372.2030302@oracle.com> Message-ID: <52005785.6010803@oracle.com> On 8/5/13 3:13 PM, Coleen Phillimore wrote: > > Hi Bill, I have some high level comments and other comments. This > wasn't as easy to review as Bob promised me! > > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/src/share/classes/com/sun/tools/attach/VirtualMachine.java.udiff.html > > > paramter (typo - two instances) > > > * @throws AgentInitializationException > - * If the Agent_OnAttach function returns > an error > + * If the Agent_OnAttach[_L] function > returns an error. > + * an error. > * > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/os/posix/vm/os_posix.cpp.frames.html > > > nameLen, prefixLen, suffixLen - the JVM coding convention (unlike > Java) is to have variable names lower case and separated by a _ (not > camelcase). Same for all the new code here buildAgentFunctionName. > > Can you put a function above this function to say what it does? So > once it's code reviewed, we can quickly know what it does without > having to study this again - ie. Is name something like libxxx.so and > you're trying to extract lib and .so from it? There's no verification > of this at lines 286 and 287 but the code is handling the case of > other sorts of unexpected input (ie line 283). Why don't you strip > the lib and the .so if !is_absolute_path? The !is_absolute_path case is to cover the agentlib start-up option that requires the agent library name in a platform-independent form which does not have to be stripped: http://docs.oracle.com/javase/7/docs/platform/jvmti/jvmti.html#starting Thanks, Serguei > > 291 agentEntryName = NEW_C_HEAP_ARRAY(char, len, mtThread); > 292 if (agentEntryName == NULL) { > 293 return NULL; > 294 } > > If NEW_C_HEAP_ARRAY fails it terminates the JVM. I think you might > want this function instead NEW_C_HEAP_ARRAY_RETURN_NULL if there's a > reasonable recovery possible. > > os_windows.cpp > > Same comments as above. Also: > > 5432 strncat(agentEntryName, name, nameLen); > 5433 strcat(agentEntryName, p); > 5434 //agentEntryName == _Agent_OnLoad_libName at 12 > 5435 } else { > > You could say why 12 but shouldn't it be the length of the resulting > symbol instead and not 12? > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/os.cpp.frames.html > > > findAgentFunction - same comment about the coding conventions. > functions and variables are lower case with underscores. Class names > are CamelCase. It would be convenient if the jvm code used the java > coding convention but the rest of it doesn't so this new code is > inconsistent. This is hard to follow as it is! > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/thread.cpp.frames.html > > > 3826 size_t num_symbol_entries = sizeof(on_unload_symbols) / > sizeof(char*); > > Why not use ARRAY_SIZE macro? > > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/prims/jvmtiExport.cpp.frames.html > > > 2208 // Check for builtin agent. If not then if the path is absolute > we attempt > 2209 // to load the library. Otherwise we try to load it from the > standard > 2210 // dll directory. > > I think you are missing the word "found" in this sentence. You are > using builtin agent to mean agent defined in a statically linked > library, I believe. Can you say that instead? Builtin means that the > jvm knows about it and implements it but in this case it doesn't. > > Maybe find_statically_linked_agent() would be a better name for this > function? > > Is the is_valid() function really mean has_been_loaded()? > > 2236 if (agentLib->valid()) { > > Did you run the Internal NSK vm.quick.testlist tests on this to verify > that nothing breaks? There are a lot of tests with different agents > and combinations in that suite and it frequently holds some surprises > in this area so best to run it first. Let me know if you need help. > > Coleen From david.r.chase at oracle.com Mon Aug 5 19:14:04 2013 From: david.r.chase at oracle.com (David Chase) Date: Mon, 5 Aug 2013 22:14:04 -0400 Subject: RFR: 8006971: More missing barriers in taskqueues for RMO architectures In-Reply-To: <52004B07.3050103@oracle.com> References: <51FCE13C.30304@oracle.com> <1F6A1982-00D8-4291-B639-9EB4C07CD24E@oracle.com> <52004B07.3050103@oracle.com> Message-ID: I'm not a reviewer, but if that's ABP queues (a comment pointing to the relevant literature would sure be nice, no matter what it is; this stuff is toxically hard) I am in theory qualified to eyeball it, and I can perhaps nab some people from SSRG upstairs. (It's late and I am still jetlagged, so I am not looking hard tonight, but it sure looks like ABP). If it's not based on ABP queues, say so, and I will look more cautiously and with less authority. David On 2013-08-05, at 9:01 PM, David Holmes wrote: > Hi Vlad > > On 6/08/2013 12:43 AM, Vladimir Danushevsky wrote: >> On Aug 3, 2013, at 6:53 AM, David Holmes wrote: >>> On 2/08/2013 11:57 PM, Vladimir Danushevsky wrote: >>>> The issue of missing memory barriers in the GC taskqueue code was first flagged here: >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >>>> >>>> JDK7u40 fix for the same issue is located here: >>>> http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ >>>> >>>> >>>> Initially we planned to port same solution to JDK8 however after reviewing the algorithm more we've started questioning a need for a full fence in between 'age' and 'bottom' elements. Since the intent is to keep 'bottom' memory reference from being executed before 'age' would a LoadLoad barrier (which in many cases is a cheaper solution) be sufficient? If so, the webrev below could possible be an adequate solution. >>>> >>>> http://cr.openjdk.java.net/~vladidan/8006971/webrev.00/ >>>> >>>> We have tested both cases (fence and LL) on a hexa-core Power5 box running several test suites that currently expose the problem. The results are positive. >>> >>> The loadload() should not be in any ifdef. The loadload() is part of the algorithmic correctness. The loadload() will become a no-op on any platform that does not need to do anything special to preserve the ordering. >> >> As I understand LL is not an issue on platforms that are excluded from emitting the barrier in the provided patch. >> >> However I went to read further discussion at >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >> and seems the concern is the Store is not guaranteed to propagate to all observers if read before the Writer's side 'sync'. I speculate that might not be an issue on PowerPC implementations with L1 cache snooping though, but even if this a case there is no robust way to detect that in runtime. > > That sounds like the fence() is missing on the writer side. > >> But that is likely not an issue on ARM (not sure about IA64, as it was listed in the very first webrev from Goetz) therefore we might inject OrderAccess::fence() for PPC (both 32- and 64-bit) and OrderAccess::loadload() for ARM (again, need info on IA64). >> That being said , for simplicity we can go with fence() for ARM case too since current ARMv7 implementations do not imply a separate barrier instruction for Loads. >> >> So in other words use same patch as in JDK7u40: >> http://cr.openjdk.java.net/~vladidan/8006971/webrev.01 > > I think this is masking the real problem with the algorithm but unless we get some true expertise involved here I don't see how we will resolve this. And time is now critical. > > So I will accept the 7u version of the fix under the same rationale as for 7u. We do need this to be fixed. Reviewed. > > I hope this is not the end of it though as this data structure needs to be revisited in my opinion. > > We need a second reviewer. > > Thanks, > David > >> Thanks, >> Vlad >> >>> >>> Thanks, >>> David >>> >>>> As a side note - >>>> perhaps it is possible to eliminate age/bottom potential reordering by loading both simultaneously through an Atomic class method. That would require though some structural changes to the layout of TaskQueueSuper class to align both fields together and ensure proper integer alignment (depending on 32/64-bit port), therefore this solution is less practical for the short term. >>>> >>>> Thanks, >>>> Vlad >>>> >> From christian.thalinger at oracle.com Mon Aug 5 20:00:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 5 Aug 2013 20:00:02 -0700 Subject: Make zero compile after 8016131 and 8016697 In-Reply-To: <51FEEA76.5050201@oracle.com> References: <51FEAAFC.109@redhat.com> <51FEEA76.5050201@oracle.com> Message-ID: On Aug 4, 2013, at 4:57 PM, David Holmes wrote: > Hi Omair, > > On 5/08/2013 5:26 AM, Omair Majid wrote: >> Hi, >> >> The following webrev makes zero compile again: >> http://cr.openjdk.java.net/~omajid/webrevs/zero-build-broken/00/ >> >> The changes in the werbrev mirror the changes made in the following >> changesets: >> >> changeset: 4983:e619a2766bcc >> user: rbackman >> date: Wed Jun 12 11:17:39 2013 +0200 >> summary: 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in >> 'entry_frame_is_first()' >> >> changeset: 4961:980532a806a5 >> user: goetz >> date: Thu Jun 20 15:02:05 2013 +0200 >> summary: 8016697: Use stubs to implement safefetch >> >> I am not sure what the best tree to use is. I made the webrev against >> hsx/hotspot-rt, but it applies to hsx/hotspot-main without any changes too. > > hotspot-rt is fine. It must be one of the group repos so hotspot-main is out. > > I've filed 8022188 for this and will sponsor it for you. > >> Any concerns with the patch? > > Nope. Reviewed. > > We need a second Reviewer before the push. Looks good. -- Chris > > Cheers, > David > ----- > >> >> Thanks, >> Omair >> From david.holmes at oracle.com Mon Aug 5 21:04:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 06 Aug 2013 14:04:42 +1000 Subject: RFR: 8006971: More missing barriers in taskqueues for RMO architectures In-Reply-To: References: <51FCE13C.30304@oracle.com> <1F6A1982-00D8-4291-B639-9EB4C07CD24E@oracle.com> <52004B07.3050103@oracle.com> Message-ID: <520075DA.5040308@oracle.com> Hi David, On 6/08/2013 12:14 PM, David Chase wrote: > I'm not a reviewer, but if that's ABP queues (a comment pointing to the relevant literature would sure be nice, no matter what it is; this stuff is toxically hard) I am in theory qualified to eyeball it, and I can perhaps nab some people from SSRG upstairs. (It's late and I am still jetlagged, so I am not looking hard tonight, but it sure looks like ABP). > > If it's not based on ABP queues, say so, and I will look more cautiously and with less authority. I believe, based on other correspondence, it is based on Chase-Lev work-stealing queue - but I'm not familiar with the ABP queues. I don't know who actually wrote this code but I suspect they are no longer working on the JDK. There is quite a bit of history with this one. The TaskQueue has been around for a while and works beautifully (as far as we know :) ) on TSO systems. The SAP folk doing the PPC64 port encountered some issues and proposed some fixes. Long story short we settled on this particular patch (a full fence() on the non-TSO systems) for 7u40 as it appeared to fix the known problems (even if potentially a heavier barrier than needed - hence the conditional compilation to not affect TSO systems). I considered this the "wrong fix" as to me the need for the fence() indicated a missing barrier elsewhere - plus the algorithm should be written without ifdefs - and I hoped we would resolve that before fixing it in JDK 8. But we haven't been able to resolve that and we need this fix in place ASAP - hence the fallback to using the same form as was accepted for 7u40. So basically this is a forward port of an existing fix and we just need to rubber-stamp it. But one of our original stampers is no longer with us so ... Thanks, David H. > David > > On 2013-08-05, at 9:01 PM, David Holmes wrote: > >> Hi Vlad >> >> On 6/08/2013 12:43 AM, Vladimir Danushevsky wrote: >>> On Aug 3, 2013, at 6:53 AM, David Holmes wrote: >>>> On 2/08/2013 11:57 PM, Vladimir Danushevsky wrote: >>>>> The issue of missing memory barriers in the GC taskqueue code was first flagged here: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >>>>> >>>>> JDK7u40 fix for the same issue is located here: >>>>> http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ >>>>> >>>>> >>>>> Initially we planned to port same solution to JDK8 however after reviewing the algorithm more we've started questioning a need for a full fence in between 'age' and 'bottom' elements. Since the intent is to keep 'bottom' memory reference from being executed before 'age' would a LoadLoad barrier (which in many cases is a cheaper solution) be sufficient? If so, the webrev below could possible be an adequate solution. >>>>> >>>>> http://cr.openjdk.java.net/~vladidan/8006971/webrev.00/ >>>>> >>>>> We have tested both cases (fence and LL) on a hexa-core Power5 box running several test suites that currently expose the problem. The results are positive. >>>> >>>> The loadload() should not be in any ifdef. The loadload() is part of the algorithmic correctness. The loadload() will become a no-op on any platform that does not need to do anything special to preserve the ordering. >>> >>> As I understand LL is not an issue on platforms that are excluded from emitting the barrier in the provided patch. >>> >>> However I went to read further discussion at >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >>> and seems the concern is the Store is not guaranteed to propagate to all observers if read before the Writer's side 'sync'. I speculate that might not be an issue on PowerPC implementations with L1 cache snooping though, but even if this a case there is no robust way to detect that in runtime. >> >> That sounds like the fence() is missing on the writer side. >> >>> But that is likely not an issue on ARM (not sure about IA64, as it was listed in the very first webrev from Goetz) therefore we might inject OrderAccess::fence() for PPC (both 32- and 64-bit) and OrderAccess::loadload() for ARM (again, need info on IA64). >>> That being said , for simplicity we can go with fence() for ARM case too since current ARMv7 implementations do not imply a separate barrier instruction for Loads. >>> >>> So in other words use same patch as in JDK7u40: >>> http://cr.openjdk.java.net/~vladidan/8006971/webrev.01 >> >> I think this is masking the real problem with the algorithm but unless we get some true expertise involved here I don't see how we will resolve this. And time is now critical. >> >> So I will accept the 7u version of the fix under the same rationale as for 7u. We do need this to be fixed. Reviewed. >> >> I hope this is not the end of it though as this data structure needs to be revisited in my opinion. >> >> We need a second reviewer. >> >> Thanks, >> David >> >>> Thanks, >>> Vlad >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> As a side note - >>>>> perhaps it is possible to eliminate age/bottom potential reordering by loading both simultaneously through an Atomic class method. That would require though some structural changes to the layout of TaskQueueSuper class to align both fields together and ensure proper integer alignment (depending on 32/64-bit port), therefore this solution is less practical for the short term. >>>>> >>>>> Thanks, >>>>> Vlad >>>>> >>> > From david.r.chase at oracle.com Mon Aug 5 22:11:35 2013 From: david.r.chase at oracle.com (David Chase) Date: Tue, 6 Aug 2013 01:11:35 -0400 Subject: RFR: 8006971: More missing barriers in taskqueues for RMO architectures In-Reply-To: <520075DA.5040308@oracle.com> References: <51FCE13C.30304@oracle.com> <1F6A1982-00D8-4291-B639-9EB4C07CD24E@oracle.com> <52004B07.3050103@oracle.com> <520075DA.5040308@oracle.com> Message-ID: It doesn't quite look like Chase-Lev, because I don't see the queue being reallocated. It looks like ABP (Arora Blumofe Plaxton) which is the ancestor of all of these, but with an additional little tag frob plus an overflow check. (Self-memory-managed Chase-Lev is scary, also relies on 64 bits being a large number.) My inclination, if we are interested in getting this fixed this week, is to go with the tested solution that works on PPC, especially since the authors read the paper that purports to add the necessary barriers, especially since the barriers in that paper look like the ones that we added when we first wrote the algorithm, before it was "ported" to SPAA's mythical SC architecture. Every barrier in that paper -- our draft, or the subsequent paper with proofs and one more barrier -- corresponds to a these-two-things-must-be-ordered point; the only thing that lets you back off from that at all is if the actual memory order is not complete unordered jelly. But I just now looked at what Wikipedia claims we are up against on Armv7 and Power, and I think we need most of them, if not all of them. I'll keep looking at it. David On 2013-08-06, at 12:04 AM, David Holmes wrote: > Hi David, > > On 6/08/2013 12:14 PM, David Chase wrote: >> I'm not a reviewer, but if that's ABP queues (a comment pointing to the relevant literature would sure be nice, no matter what it is; this stuff is toxically hard) I am in theory qualified to eyeball it, and I can perhaps nab some people from SSRG upstairs. (It's late and I am still jetlagged, so I am not looking hard tonight, but it sure looks like ABP). >> >> If it's not based on ABP queues, say so, and I will look more cautiously and with less authority. > > I believe, based on other correspondence, it is based on Chase-Lev work-stealing queue - but I'm not familiar with the ABP queues. I don't know who actually wrote this code but I suspect they are no longer working on the JDK. > > There is quite a bit of history with this one. The TaskQueue has been around for a while and works beautifully (as far as we know :) ) on TSO systems. The SAP folk doing the PPC64 port encountered some issues and proposed some fixes. Long story short we settled on this particular patch (a full fence() on the non-TSO systems) for 7u40 as it appeared to fix the known problems (even if potentially a heavier barrier than needed - hence the conditional compilation to not affect TSO systems). > > I considered this the "wrong fix" as to me the need for the fence() indicated a missing barrier elsewhere - plus the algorithm should be written without ifdefs - and I hoped we would resolve that before fixing it in JDK 8. But we haven't been able to resolve that and we need this fix in place ASAP - hence the fallback to using the same form as was accepted for 7u40. > > So basically this is a forward port of an existing fix and we just need to rubber-stamp it. But one of our original stampers is no longer with us so ... > > Thanks, > David H. > >> David >> >> On 2013-08-05, at 9:01 PM, David Holmes wrote: >> >>> Hi Vlad >>> >>> On 6/08/2013 12:43 AM, Vladimir Danushevsky wrote: >>>> On Aug 3, 2013, at 6:53 AM, David Holmes wrote: >>>>> On 2/08/2013 11:57 PM, Vladimir Danushevsky wrote: >>>>>> The issue of missing memory barriers in the GC taskqueue code was first flagged here: >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >>>>>> >>>>>> JDK7u40 fix for the same issue is located here: >>>>>> http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ >>>>>> >>>>>> >>>>>> Initially we planned to port same solution to JDK8 however after reviewing the algorithm more we've started questioning a need for a full fence in between 'age' and 'bottom' elements. Since the intent is to keep 'bottom' memory reference from being executed before 'age' would a LoadLoad barrier (which in many cases is a cheaper solution) be sufficient? If so, the webrev below could possible be an adequate solution. >>>>>> >>>>>> http://cr.openjdk.java.net/~vladidan/8006971/webrev.00/ >>>>>> >>>>>> We have tested both cases (fence and LL) on a hexa-core Power5 box running several test suites that currently expose the problem. The results are positive. >>>>> >>>>> The loadload() should not be in any ifdef. The loadload() is part of the algorithmic correctness. The loadload() will become a no-op on any platform that does not need to do anything special to preserve the ordering. >>>> >>>> As I understand LL is not an issue on platforms that are excluded from emitting the barrier in the provided patch. >>>> >>>> However I went to read further discussion at >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >>>> and seems the concern is the Store is not guaranteed to propagate to all observers if read before the Writer's side 'sync'. I speculate that might not be an issue on PowerPC implementations with L1 cache snooping though, but even if this a case there is no robust way to detect that in runtime. >>> >>> That sounds like the fence() is missing on the writer side. >>> >>>> But that is likely not an issue on ARM (not sure about IA64, as it was listed in the very first webrev from Goetz) therefore we might inject OrderAccess::fence() for PPC (both 32- and 64-bit) and OrderAccess::loadload() for ARM (again, need info on IA64). >>>> That being said , for simplicity we can go with fence() for ARM case too since current ARMv7 implementations do not imply a separate barrier instruction for Loads. >>>> >>>> So in other words use same patch as in JDK7u40: >>>> http://cr.openjdk.java.net/~vladidan/8006971/webrev.01 >>> >>> I think this is masking the real problem with the algorithm but unless we get some true expertise involved here I don't see how we will resolve this. And time is now critical. >>> >>> So I will accept the 7u version of the fix under the same rationale as for 7u. We do need this to be fixed. Reviewed. >>> >>> I hope this is not the end of it though as this data structure needs to be revisited in my opinion. >>> >>> We need a second reviewer. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Vlad >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> As a side note - >>>>>> perhaps it is possible to eliminate age/bottom potential reordering by loading both simultaneously through an Atomic class method. That would require though some structural changes to the layout of TaskQueueSuper class to align both fields together and ensure proper integer alignment (depending on 32/64-bit port), therefore this solution is less practical for the short term. >>>>>> >>>>>> Thanks, >>>>>> Vlad >>>>>> >>>> >> From vladimir.kozlov at oracle.com Mon Aug 5 23:02:38 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 05 Aug 2013 23:02:38 -0700 Subject: RFR: 8006971: More missing barriers in taskqueues for RMO architectures In-Reply-To: <520075DA.5040308@oracle.com> References: <51FCE13C.30304@oracle.com> <1F6A1982-00D8-4291-B639-9EB4C07CD24E@oracle.com> <52004B07.3050103@oracle.com> <520075DA.5040308@oracle.com> Message-ID: <5200917E.9080403@oracle.com> I rubber-stamp it :) Reviewed. But you should use original changeset header (bug id 8012144, Summary: , Contributed-by: ) from hsx24 to track the same changes in both releases. You could use hg export/import since changes are the same. We can keep 8006971 open for more general solution later with added comment that we used 8012144 changes in 7u40 and jdk8. Thanks, Vladimir On 8/5/13 9:04 PM, David Holmes wrote: > Hi David, > > On 6/08/2013 12:14 PM, David Chase wrote: >> I'm not a reviewer, but if that's ABP queues (a comment pointing to the relevant literature would sure be nice, no >> matter what it is; this stuff is toxically hard) I am in theory qualified to eyeball it, and I can perhaps nab some >> people from SSRG upstairs. (It's late and I am still jetlagged, so I am not looking hard tonight, but it sure looks >> like ABP). >> >> If it's not based on ABP queues, say so, and I will look more cautiously and with less authority. > > I believe, based on other correspondence, it is based on Chase-Lev work-stealing queue - but I'm not familiar with the > ABP queues. I don't know who actually wrote this code but I suspect they are no longer working on the JDK. > > There is quite a bit of history with this one. The TaskQueue has been around for a while and works beautifully (as far > as we know :) ) on TSO systems. The SAP folk doing the PPC64 port encountered some issues and proposed some fixes. Long > story short we settled on this particular patch (a full fence() on the non-TSO systems) for 7u40 as it appeared to fix > the known problems (even if potentially a heavier barrier than needed - hence the conditional compilation to not affect > TSO systems). > > I considered this the "wrong fix" as to me the need for the fence() indicated a missing barrier elsewhere - plus the > algorithm should be written without ifdefs - and I hoped we would resolve that before fixing it in JDK 8. But we haven't > been able to resolve that and we need this fix in place ASAP - hence the fallback to using the same form as was accepted > for 7u40. > > So basically this is a forward port of an existing fix and we just need to rubber-stamp it. But one of our original > stampers is no longer with us so ... > > Thanks, > David H. > >> David >> >> On 2013-08-05, at 9:01 PM, David Holmes wrote: >> >>> Hi Vlad >>> >>> On 6/08/2013 12:43 AM, Vladimir Danushevsky wrote: >>>> On Aug 3, 2013, at 6:53 AM, David Holmes wrote: >>>>> On 2/08/2013 11:57 PM, Vladimir Danushevsky wrote: >>>>>> The issue of missing memory barriers in the GC taskqueue code was first flagged here: >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >>>>>> >>>>>> JDK7u40 fix for the same issue is located here: >>>>>> http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ >>>>>> >>>>>> >>>>>> Initially we planned to port same solution to JDK8 however after reviewing the algorithm more we've started >>>>>> questioning a need for a full fence in between 'age' and 'bottom' elements. Since the intent is to keep 'bottom' >>>>>> memory reference from being executed before 'age' would a LoadLoad barrier (which in many cases is a cheaper >>>>>> solution) be sufficient? If so, the webrev below could possible be an adequate solution. >>>>>> >>>>>> http://cr.openjdk.java.net/~vladidan/8006971/webrev.00/ >>>>>> >>>>>> We have tested both cases (fence and LL) on a hexa-core Power5 box running several test suites that currently >>>>>> expose the problem. The results are positive. >>>>> >>>>> The loadload() should not be in any ifdef. The loadload() is part of the algorithmic correctness. The loadload() >>>>> will become a no-op on any platform that does not need to do anything special to preserve the ordering. >>>> >>>> As I understand LL is not an issue on platforms that are excluded from emitting the barrier in the provided patch. >>>> >>>> However I went to read further discussion at >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >>>> and seems the concern is the Store is not guaranteed to propagate to all observers if read before the Writer's side >>>> 'sync'. I speculate that might not be an issue on PowerPC implementations with L1 cache snooping though, but even if >>>> this a case there is no robust way to detect that in runtime. >>> >>> That sounds like the fence() is missing on the writer side. >>> >>>> But that is likely not an issue on ARM (not sure about IA64, as it was listed in the very first webrev from Goetz) >>>> therefore we might inject OrderAccess::fence() for PPC (both 32- and 64-bit) and OrderAccess::loadload() for ARM >>>> (again, need info on IA64). >>>> That being said , for simplicity we can go with fence() for ARM case too since current ARMv7 implementations do not >>>> imply a separate barrier instruction for Loads. >>>> >>>> So in other words use same patch as in JDK7u40: >>>> http://cr.openjdk.java.net/~vladidan/8006971/webrev.01 >>> >>> I think this is masking the real problem with the algorithm but unless we get some true expertise involved here I >>> don't see how we will resolve this. And time is now critical. >>> >>> So I will accept the 7u version of the fix under the same rationale as for 7u. We do need this to be fixed. Reviewed. >>> >>> I hope this is not the end of it though as this data structure needs to be revisited in my opinion. >>> >>> We need a second reviewer. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Vlad >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> As a side note - >>>>>> perhaps it is possible to eliminate age/bottom potential reordering by loading both simultaneously through an >>>>>> Atomic class method. That would require though some structural changes to the layout of TaskQueueSuper class to >>>>>> align both fields together and ensure proper integer alignment (depending on 32/64-bit port), therefore this >>>>>> solution is less practical for the short term. >>>>>> >>>>>> Thanks, >>>>>> Vlad >>>>>> >>>> >> From ysr1729 at gmail.com Mon Aug 5 23:17:23 2013 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Mon, 5 Aug 2013 23:17:23 -0700 Subject: RFR: 8006971: More missing barriers in taskqueues for RMO architectures In-Reply-To: <5200917E.9080403@oracle.com> References: <51FCE13C.30304@oracle.com> <1F6A1982-00D8-4291-B639-9EB4C07CD24E@oracle.com> <52004B07.3050103@oracle.com> <520075DA.5040308@oracle.com> <5200917E.9080403@oracle.com> Message-ID: <768A71BC-215D-49BC-8FBD-74848B314D4D@gmail.com> The task queue stuff, from what I vaguely recall, was based on ABP as David C noted. ysr1729 On Aug 5, 2013, at 23:02, Vladimir Kozlov wrote: > I rubber-stamp it :) > Reviewed. > > But you should use original changeset header (bug id 8012144, Summary: , Contributed-by: ) from hsx24 to track the same changes in both releases. You could use hg export/import since changes are the same. > > We can keep 8006971 open for more general solution later with added comment that we used 8012144 changes in 7u40 and jdk8. > > Thanks, > Vladimir > > On 8/5/13 9:04 PM, David Holmes wrote: >> Hi David, >> >> On 6/08/2013 12:14 PM, David Chase wrote: >>> I'm not a reviewer, but if that's ABP queues (a comment pointing to the relevant literature would sure be nice, no >>> matter what it is; this stuff is toxically hard) I am in theory qualified to eyeball it, and I can perhaps nab some >>> people from SSRG upstairs. (It's late and I am still jetlagged, so I am not looking hard tonight, but it sure looks >>> like ABP). >>> >>> If it's not based on ABP queues, say so, and I will look more cautiously and with less authority. >> >> I believe, based on other correspondence, it is based on Chase-Lev work-stealing queue - but I'm not familiar with the >> ABP queues. I don't know who actually wrote this code but I suspect they are no longer working on the JDK. >> >> There is quite a bit of history with this one. The TaskQueue has been around for a while and works beautifully (as far >> as we know :) ) on TSO systems. The SAP folk doing the PPC64 port encountered some issues and proposed some fixes. Long >> story short we settled on this particular patch (a full fence() on the non-TSO systems) for 7u40 as it appeared to fix >> the known problems (even if potentially a heavier barrier than needed - hence the conditional compilation to not affect >> TSO systems). >> >> I considered this the "wrong fix" as to me the need for the fence() indicated a missing barrier elsewhere - plus the >> algorithm should be written without ifdefs - and I hoped we would resolve that before fixing it in JDK 8. But we haven't >> been able to resolve that and we need this fix in place ASAP - hence the fallback to using the same form as was accepted >> for 7u40. >> >> So basically this is a forward port of an existing fix and we just need to rubber-stamp it. But one of our original >> stampers is no longer with us so ... >> >> Thanks, >> David H. >> >>> David >>> >>> On 2013-08-05, at 9:01 PM, David Holmes wrote: >>> >>>> Hi Vlad >>>> >>>> On 6/08/2013 12:43 AM, Vladimir Danushevsky wrote: >>>>> On Aug 3, 2013, at 6:53 AM, David Holmes wrote: >>>>>> On 2/08/2013 11:57 PM, Vladimir Danushevsky wrote: >>>>>>> The issue of missing memory barriers in the GC taskqueue code was first flagged here: >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >>>>>>> >>>>>>> JDK7u40 fix for the same issue is located here: >>>>>>> http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ >>>>>>> >>>>>>> >>>>>>> Initially we planned to port same solution to JDK8 however after reviewing the algorithm more we've started >>>>>>> questioning a need for a full fence in between 'age' and 'bottom' elements. Since the intent is to keep 'bottom' >>>>>>> memory reference from being executed before 'age' would a LoadLoad barrier (which in many cases is a cheaper >>>>>>> solution) be sufficient? If so, the webrev below could possible be an adequate solution. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~vladidan/8006971/webrev.00/ >>>>>>> >>>>>>> We have tested both cases (fence and LL) on a hexa-core Power5 box running several test suites that currently >>>>>>> expose the problem. The results are positive. >>>>>> >>>>>> The loadload() should not be in any ifdef. The loadload() is part of the algorithmic correctness. The loadload() >>>>>> will become a no-op on any platform that does not need to do anything special to preserve the ordering. >>>>> >>>>> As I understand LL is not an issue on platforms that are excluded from emitting the barrier in the provided patch. >>>>> >>>>> However I went to read further discussion at >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >>>>> and seems the concern is the Store is not guaranteed to propagate to all observers if read before the Writer's side >>>>> 'sync'. I speculate that might not be an issue on PowerPC implementations with L1 cache snooping though, but even if >>>>> this a case there is no robust way to detect that in runtime. >>>> >>>> That sounds like the fence() is missing on the writer side. >>>> >>>>> But that is likely not an issue on ARM (not sure about IA64, as it was listed in the very first webrev from Goetz) >>>>> therefore we might inject OrderAccess::fence() for PPC (both 32- and 64-bit) and OrderAccess::loadload() for ARM >>>>> (again, need info on IA64). >>>>> That being said , for simplicity we can go with fence() for ARM case too since current ARMv7 implementations do not >>>>> imply a separate barrier instruction for Loads. >>>>> >>>>> So in other words use same patch as in JDK7u40: >>>>> http://cr.openjdk.java.net/~vladidan/8006971/webrev.01 >>>> >>>> I think this is masking the real problem with the algorithm but unless we get some true expertise involved here I >>>> don't see how we will resolve this. And time is now critical. >>>> >>>> So I will accept the 7u version of the fix under the same rationale as for 7u. We do need this to be fixed. Reviewed. >>>> >>>> I hope this is not the end of it though as this data structure needs to be revisited in my opinion. >>>> >>>> We need a second reviewer. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Vlad >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> As a side note - >>>>>>> perhaps it is possible to eliminate age/bottom potential reordering by loading both simultaneously through an >>>>>>> Atomic class method. That would require though some structural changes to the layout of TaskQueueSuper class to >>>>>>> align both fields together and ensure proper integer alignment (depending on 32/64-bit port), therefore this >>>>>>> solution is less practical for the short term. >>>>>>> >>>>>>> Thanks, >>>>>>> Vlad >>> From david.holmes at oracle.com Mon Aug 5 23:40:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 06 Aug 2013 16:40:21 +1000 Subject: RFR: 8006971: More missing barriers in taskqueues for RMO architectures In-Reply-To: <5200917E.9080403@oracle.com> References: <51FCE13C.30304@oracle.com> <1F6A1982-00D8-4291-B639-9EB4C07CD24E@oracle.com> <52004B07.3050103@oracle.com> <520075DA.5040308@oracle.com> <5200917E.9080403@oracle.com> Message-ID: <52009A55.8080203@oracle.com> On 6/08/2013 4:02 PM, Vladimir Kozlov wrote: > I rubber-stamp it :) > Reviewed. > > But you should use original changeset header (bug id 8012144, Summary: , > Contributed-by: ) from hsx24 to track the same changes in both releases. > You could use hg export/import since changes are the same. > > We can keep 8006971 open for more general solution later with added > comment that we used 8012144 changes in 7u40 and jdk8. Thanks Vladimir - yes that is an excellent point. I would have overlooked that and used 8006971 instead of 8012144. Though that does leave me a bit puzzled about what 8006971 actually refers to now. Thanks, David > Thanks, > Vladimir > > On 8/5/13 9:04 PM, David Holmes wrote: >> Hi David, >> >> On 6/08/2013 12:14 PM, David Chase wrote: >>> I'm not a reviewer, but if that's ABP queues (a comment pointing to >>> the relevant literature would sure be nice, no >>> matter what it is; this stuff is toxically hard) I am in theory >>> qualified to eyeball it, and I can perhaps nab some >>> people from SSRG upstairs. (It's late and I am still jetlagged, so I >>> am not looking hard tonight, but it sure looks >>> like ABP). >>> >>> If it's not based on ABP queues, say so, and I will look more >>> cautiously and with less authority. >> >> I believe, based on other correspondence, it is based on Chase-Lev >> work-stealing queue - but I'm not familiar with the >> ABP queues. I don't know who actually wrote this code but I suspect >> they are no longer working on the JDK. >> >> There is quite a bit of history with this one. The TaskQueue has been >> around for a while and works beautifully (as far >> as we know :) ) on TSO systems. The SAP folk doing the PPC64 port >> encountered some issues and proposed some fixes. Long >> story short we settled on this particular patch (a full fence() on the >> non-TSO systems) for 7u40 as it appeared to fix >> the known problems (even if potentially a heavier barrier than needed >> - hence the conditional compilation to not affect >> TSO systems). >> >> I considered this the "wrong fix" as to me the need for the fence() >> indicated a missing barrier elsewhere - plus the >> algorithm should be written without ifdefs - and I hoped we would >> resolve that before fixing it in JDK 8. But we haven't >> been able to resolve that and we need this fix in place ASAP - hence >> the fallback to using the same form as was accepted >> for 7u40. >> >> So basically this is a forward port of an existing fix and we just >> need to rubber-stamp it. But one of our original >> stampers is no longer with us so ... >> >> Thanks, >> David H. >> >>> David >>> >>> On 2013-08-05, at 9:01 PM, David Holmes wrote: >>> >>>> Hi Vlad >>>> >>>> On 6/08/2013 12:43 AM, Vladimir Danushevsky wrote: >>>>> On Aug 3, 2013, at 6:53 AM, David Holmes wrote: >>>>>> On 2/08/2013 11:57 PM, Vladimir Danushevsky wrote: >>>>>>> The issue of missing memory barriers in the GC taskqueue code was >>>>>>> first flagged here: >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >>>>>>> >>>>>>> >>>>>>> JDK7u40 fix for the same issue is located here: >>>>>>> http://cr.openjdk.java.net/~dholmes/8012144/webrev.hs24/ >>>>>>> >>>>>>> >>>>>>> Initially we planned to port same solution to JDK8 however after >>>>>>> reviewing the algorithm more we've started >>>>>>> questioning a need for a full fence in between 'age' and 'bottom' >>>>>>> elements. Since the intent is to keep 'bottom' >>>>>>> memory reference from being executed before 'age' would a >>>>>>> LoadLoad barrier (which in many cases is a cheaper >>>>>>> solution) be sufficient? If so, the webrev below could possible >>>>>>> be an adequate solution. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~vladidan/8006971/webrev.00/ >>>>>>> >>>>>>> We have tested both cases (fence and LL) on a hexa-core Power5 >>>>>>> box running several test suites that currently >>>>>>> expose the problem. The results are positive. >>>>>> >>>>>> The loadload() should not be in any ifdef. The loadload() is part >>>>>> of the algorithmic correctness. The loadload() >>>>>> will become a no-op on any platform that does not need to do >>>>>> anything special to preserve the ordering. >>>>> >>>>> As I understand LL is not an issue on platforms that are excluded >>>>> from emitting the barrier in the provided patch. >>>>> >>>>> However I went to read further discussion at >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-March/008848.html >>>>> >>>>> and seems the concern is the Store is not guaranteed to propagate >>>>> to all observers if read before the Writer's side >>>>> 'sync'. I speculate that might not be an issue on PowerPC >>>>> implementations with L1 cache snooping though, but even if >>>>> this a case there is no robust way to detect that in runtime. >>>> >>>> That sounds like the fence() is missing on the writer side. >>>> >>>>> But that is likely not an issue on ARM (not sure about IA64, as it >>>>> was listed in the very first webrev from Goetz) >>>>> therefore we might inject OrderAccess::fence() for PPC (both 32- >>>>> and 64-bit) and OrderAccess::loadload() for ARM >>>>> (again, need info on IA64). >>>>> That being said , for simplicity we can go with fence() for ARM >>>>> case too since current ARMv7 implementations do not >>>>> imply a separate barrier instruction for Loads. >>>>> >>>>> So in other words use same patch as in JDK7u40: >>>>> http://cr.openjdk.java.net/~vladidan/8006971/webrev.01 >>>> >>>> I think this is masking the real problem with the algorithm but >>>> unless we get some true expertise involved here I >>>> don't see how we will resolve this. And time is now critical. >>>> >>>> So I will accept the 7u version of the fix under the same rationale >>>> as for 7u. We do need this to be fixed. Reviewed. >>>> >>>> I hope this is not the end of it though as this data structure needs >>>> to be revisited in my opinion. >>>> >>>> We need a second reviewer. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Vlad >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> As a side note - >>>>>>> perhaps it is possible to eliminate age/bottom potential >>>>>>> reordering by loading both simultaneously through an >>>>>>> Atomic class method. That would require though some structural >>>>>>> changes to the layout of TaskQueueSuper class to >>>>>>> align both fields together and ensure proper integer alignment >>>>>>> (depending on 32/64-bit port), therefore this >>>>>>> solution is less practical for the short term. >>>>>>> >>>>>>> Thanks, >>>>>>> Vlad >>>>>>> >>>>> >>> From serguei.spitsyn at oracle.com Tue Aug 6 02:47:47 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 06 Aug 2013 02:47:47 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <51FFF61E.1020509@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <51FC884C.20407@oracle.com> <690FEAD4-3147-4C8D-96EC-7B5C91AC27E4@oracle.com> <51FFF61E.1020509@oracle.com> Message-ID: <5200C643.9060902@oracle.com> Bob, I've done another look and got a few more comments below. http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ src/share/vm/runtime/os.cpp The comment before the function findAgentFunction() is inconsistent with the implementation. There is a mismatch in "lib name": lib_name and libName .vs. name There is a mismatch in "check lib": check_lib .vs. checkLib The following part is not accurate as it does not tell anything about the condition is_static_lib(): + * If check_lib == true then we are looking for an + * Agent_OnLoad_libname or Agent_OnAttach_libname function to determine if + * this library is statically linked into the image. src/os/posix/vm/os_posix.cpp src/os/windows/vm/os_windows.cpp The function buildAgentFunctionName(): Minor: I'd suggest to change the argument name from "name" to "libname" or "lib_name". Otherwise, it takes time to figure out what the "name" argument really means. src/share/vm/runtime/thread.cpp Minor: It is better to initialize the below with NULL: 3699 void *library; I also agree with Coleen on the following: - about using the hotspot coding convention for variables/functions names - a comment is needed before the function buildAgentFunctionName - built-in agent => statically linked agent One more thing to say is that I really like the implementation. Thank you for adding this feature in such a non-intrusive fashion! Thanks, Serguei On 8/5/13 11:59 AM, serguei.spitsyn at oracle.com wrote: > Bob, > > I'm not waiting for any changes from Bill at the moment but still > reading the code. > Sorry for the latency but it takes time as not everything is clear to > me yet. > > Thanks, > Serguei > > On 8/5/13 10:59 AM, Bob Vandette wrote: >> Serguei, >> >> Are you ok with the webrev at this point or are you waiting for any >> changes from Bill? >> >> I've asked Coleen to review the code since she's an official Reviewer >> but she'd like to make >> sure the serviceability team is ok with the changes. >> >> Bob. >> >> >> On Aug 3, 2013, at 12:34 AM, serguei.spitsyn at oracle.com wrote: >> >>> On 8/2/13 8:11 PM, Bill Pittore wrote: >>>> On 8/2/2013 9:12 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Bill, >>>>> >>>>> A couple of more questions. >>>>> >>>>> webrev.01/jvmti.html >>>>> >>>>> An agent L whose image has been combined with the VM *is defined* >>>>> as /statically linked/ >>>>> if and only if the agent exports a function called Agent_OnLoad_L. >>>>> >>>>> A question to the above. >>>>> Are we going to allow to link a library dynamically if it exports >>>>> both >>>>> the Agent_OnLoad and Agent_OnLoad_L functions? >>>>> It can be convenient if a library exports both Agent_OnLoad and >>>>> Agent_OnLoad_L >>>>> as it can be linked statically or dynamically depending on the >>>>> need without changes. >>>>> >>>> It would be nice but the problem is that you could only link one >>>> agent into the VM if it exported Agent_OnLoad. Otherwise there >>>> would be a symbol collision with the second agent you linked in >>>> that also had Agent_OnLoad. As an agent developer you will have to >>>> select one or the other at build time, either statically linked in >>>> or dynamic. >>> I did not want to use the Agent_OnLoad for statically linked agent. >>> Just wanted to say that the presence of the Agent_OnLoad_L must be >>> ignored >>> if the agent is linked dynamically. >>> Maybe this rule needs to be clearly stated in the JVMTI spec. >>> >>>>> You already added the following statement to the JVMTI spec: >>>>> If a /statically linked/ agent L exports a function called >>>>> Agent_OnLoad_L and >>>>> a function called Agent_OnLoad, the Agent_OnLoad function will >>>>> be ignored. >>>>> >>>>> Could we say it in a shorter form?: >>>>> If a /statically linked/ agent L exports a function called >>>>> Agent_OnLoad, >>>>> the Agent_OnLoad function will be ignored. >>>> I believe I copied this from JNI static linking JEP. If so, I'll >>>> probably leave it as is just for consistency with JNI static spec. >>>> JVM TI static linking spec is closely related to JNI static linking >>>> spec. >>> I see. Then it is Ok with me. >>> >>>>> In this context would it be reasonable to add another statement: >>>>> If a /dynamically linked/ agent L exports a function called >>>>> Agent_OnLoad_L, >>>>> the Agent_OnLoad_L function will be ignored. >>>>> >>>>> The same questions apply to the Agent_OnAttach and >>>>> Agent_OnAttach_L entry points. >>>>> >>>> I'm out on vacation for a couple of weeks so I'll leave it up to >>>> Bob V. and yourself if you guys want to hash out better/different >>>> wording. >>> Thank you for the quick reply, and have a nice vacation! >>> >>> Thanks, >>> Serguei >>> >>>> bill >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 7/30/13 12:17 PM, bill.pittore at oracle.com wrote: >>>>>> Thanks Serguei for the comments. Some comments inline. I updated >>>>>> the webrevs at >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>>>> >>>>>> >>>>>> >>>>>> On 7/26/2013 5:00 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Bill, >>>>>>> >>>>>>> Sorry for the big delay. >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>>>> >>>>>>> >>>>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>>>> >>>>>>> >>>>>>> I'm suggesting to use the reference >>>>>>> *Agent_OnAttach[_L]**||* even more consistently. >>>>>>> (If, in some cases, you prefer the longer form to underline the >>>>>>> difference between >>>>>>> dynamically and statically linked libraries then feel free to >>>>>>> leave it as it is.) >>>>>>> >>>>>>> It would simplify the following fragments: >>>>>>> >>>>>>> 304 * It then causes the target VM to invoke the >>>>>>> Agent_OnAttach function >>>>>>> 305 * or, for a statically linked agent named 'L', the >>>>>>> Agent_OnAttach_L function >>>>>>> ==> >>>>>>> >>>>>>> 304 * It then causes the target VM to invoke the >>>>>>> Agent_OnAttach[_L] function >>>>>>> >>>>>>> 409 * It then causes the target VM to invoke the >>>>>>> Agent_OnAttach >>>>>>> 410 * function or, for a statically linked agent named 'L', >>>>>>> the >>>>>>> 411 * Agent_OnAttach_L function as specified >>>>>>> in the >>>>>>> ==> >>>>>>> 409 * It then causes the target VM to invoke the >>>>>>> Agent_OnAttach[_L] >>>>>>> 410 * function as specified in the >>>>>>> >>>>>> I left the above as is since it's part of the method description. >>>>>> The following fragments below I simplified as you suggested. >>>>>> >>>>>>> the following 4 identical fragments: >>>>>>> >>>>>>> 341 * If the Agent_OnAttach >>>>>>> function returns an error >>>>>>> 342 * or, for a statically linked agent named >>>>>>> 'L', if the >>>>>>> 343 * Agent_OnAttach_L function returns >>>>>>> 344 * an error. >>>>>>> 375 * If the Agent_OnAttach >>>>>>> function returns an error >>>>>>> 376 * or, for a statically linked agent named >>>>>>> 'L', if the >>>>>>> 377 * Agent_OnAttach_L function returns >>>>>>> 378 * an error. >>>>>>> 442 * If the Agent_OnAttach >>>>>>> function returns an error >>>>>>> 443 * or, for a statically linked agent named >>>>>>> 'L', if the >>>>>>> 444 * Agent_OnAttach_L function returns an >>>>>>> error >>>>>>> 475 * If the Agent_OnAttach >>>>>>> function returns an error >>>>>>> 476 * or, for a statically linked agent named >>>>>>> 'L', if the >>>>>>> 477 * Agent_OnAttach_L function returns >>>>>>> 478 * an error. >>>>>>> ==> >>>>>>> >>>>>>> 336 * If the Agent_OnAttach[_L] >>>>>>> function returns an error. >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>> >>>>>>> src/share/vm/prims/jvmti.xml >>>>>>> >>>>>>> Lines 442-462: many extra

's. The fragment does not look well. >>>>>>> I'd suggest to remove most of them. >>>>>>> Also, these lines are too long. Could you make them shorter, >>>>>>> please? >>>>>>> The same is applied to other long new lines in this file. >>>>>> Cleaned this up a bit. >>>>>>> Lines 490-491, 502-503, 505-506: >>>>>>> The same sentence is repeated 3 times: "the agent library >>>>>>> may be statically linked ..." >>>>>>> >>>>>>> 490 Note that the agent library may be statically linked >>>>>>> into the executable >>>>>>> 491 in which case no actual loading takes place. >>>>>> Fixed. >>>>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is >>>>>>> specified, the VM will attempt to >>>>>>> 502 load the shared library >>>>>>> c:\myLibs\foo.dll. As mentioned above, the agent >>>>>>> library may be statically linked into the executable >>>>>>> 503 in which case no actual loading takes place >>>>>>> >>>>>>> 505 Note that the agent library may be statically linked >>>>>>> into the executable >>>>>>> 506 in which case no actual loading takes place. >>>>>>> >>>>>> Tweaked the above a bit to make it less wordy. >>>>>> >>>>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>>>> >>>>>>> 677 and enabled the event >>>>>>> >>>>>> Fixed. >>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/os/windows/vm/os_windows.cpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/share/vm/prims/jvmtiExport.cpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/share/vm/runtime/arguments.hpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/share/vm/runtime/os.cpp >>>>>>> >>>>>>> Space is missed after the 'if': >>>>>>> 471 if(entryName != NULL) { >>>>>>> >>>>>> Fixed. >>>>>>> Extra space after the '*': >>>>>>> 483 void * saveHandle; >>>>>>> >>>>>> Fixed. >>>>>>> src/share/vm/runtime/os.hpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/share/vm/runtime/thread.cpp >>>>>>> >>>>>>> The line has been removed: >>>>>>> 3866 break; >>>>>>> >>>>>> Correct, the inner for loop was removed so no need for the break; >>>>>>> I'm still in process of reading the code. >>>>>>> Another pass is needed to make sure that nothing is missed. >>>>>>> But in general, the code quality is pretty good. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: >>>>>>>> Still need an official reviewer for the hotspot changes for >>>>>>>> statically linked agents. >>>>>>>> >>>>>>>> thanks, >>>>>>>> bill >>>>>>>> >>>>>>>>> These changes address bug 8014135 which adds support for >>>>>>>>> statically linked agents in the VM. This is a followup to the >>>>>>>>> recent JNI spec changes that addressed statically linked JNI >>>>>>>>> libraries( 8005716). >>>>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>>>> http://openjdk.java.net/jeps/178 >>>>>>>>> >>>>>>>>> Webrevs are here: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>> >>>>>>>>> The changes to jvmti.xml can also be seen in the output file >>>>>>>>> that I placed here: >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> bill >>>>>>>>> >>>>>> > From serguei.spitsyn at oracle.com Tue Aug 6 11:57:36 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 06 Aug 2013 11:57:36 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> Message-ID: <52014720.3040500@oracle.com> On 8/5/13 7:41 AM, Bob Vandette wrote: > On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: > >> On 8/2/2013 9:12 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Bill, >>> >>> A couple of more questions. >>> >>> webrev.01/jvmti.html >>> >>> An agent L whose image has been combined with the VM *is defined* as /statically linked/ >>> if and only if the agent exports a function called Agent_OnLoad_L. >>> >>> A question to the above. >>> Are we going to allow to link a library dynamically if it exports both >>> the Agent_OnLoad and Agent_OnLoad_L functions? >>> It can be convenient if a library exports both Agent_OnLoad and Agent_OnLoad_L >>> as it can be linked statically or dynamically depending on the need without changes. >>> >> It would be nice but the problem is that you could only link one agent into the VM if it exported Agent_OnLoad. Otherwise there would be a symbol collision with the second agent you linked in that also had Agent_OnLoad. As an agent developer you will have to select one or the other at build time, either statically linked in or dynamic. >>> You already added the following statement to the JVMTI spec: >>> If a /statically linked/ agent L exports a function called Agent_OnLoad_L and >>> a function called Agent_OnLoad, the Agent_OnLoad function will be ignored. >>> >>> Could we say it in a shorter form?: >>> If a /statically linked/ agent L exports a function called Agent_OnLoad, >>> the Agent_OnLoad function will be ignored. >> I believe I copied this from JNI static linking JEP. If so, I'll probably leave it as is just for consistency with JNI static spec. JVM TI static linking spec is closely related to JNI static linking spec. >>> In this context would it be reasonable to add another statement: >>> If a /dynamically linked/ agent L exports a function called Agent_OnLoad_L, >>> the Agent_OnLoad_L function will be ignored. >>> > I'd rather leave this undefined since the behavior is very platform specific. > The way we determine if a library is statically linked is by the presence of the Agent_OnLoad_L function. > If this function exists in a dynamically linked library, it will be treated as a static library if by some chance > it's attempted to be loaded twice, since the symbol will may be visible in the running process. (I've added Alan and Coleen to the cc-list) It is still not clear to me how the second load might happen. The agent is determined as statically loaded if the Agent_OnLoad_L function is found in the main program, not in the dynamic library. At least, the dll_lookup is done for the main program (for DefaultProcessHandle). If the agent is loaded dynamically, the Agent_OnLoad_L function in the agent library can be ignored because the dll_lookup in the main program will not find it. In a case of the second load this function will be ignored again. So that there is no conflict with the dynamically loaded agent here. We can skip this issue for now. Alan is going to review the JEP from the dynamic Attach point of view and hopefully will pay attention to these details. Thanks, Serguei > > Bob. > > >>> The same questions apply to the Agent_OnAttach and Agent_OnAttach_L entry points. >>> >> I'm out on vacation for a couple of weeks so I'll leave it up to Bob V. and yourself if you guys want to hash out better/different wording. >> >> bill >>> Thanks, >>> Serguei >>> >>> >>> On 7/30/13 12:17 PM, bill.pittore at oracle.com wrote: >>>> Thanks Serguei for the comments. Some comments inline. I updated the webrevs at >>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>> >>>> >>>> On 7/26/2013 5:00 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Bill, >>>>> >>>>> Sorry for the big delay. >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>> >>>>> >>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>> >>>>> >>>>> I'm suggesting to use the reference *Agent_OnAttach[_L]**||* even more consistently. >>>>> (If, in some cases, you prefer the longer form to underline the difference between >>>>> dynamically and statically linked libraries then feel free to leave it as it is.) >>>>> >>>>> It would simplify the following fragments: >>>>> >>>>> 304 * It then causes the target VM to invoke the Agent_OnAttach function >>>>> 305 * or, for a statically linked agent named 'L', the Agent_OnAttach_L function >>>>> ==> >>>>> >>>>> 304 * It then causes the target VM to invoke the Agent_OnAttach[_L] function >>>>> >>>>> 409 * It then causes the target VM to invoke the Agent_OnAttach >>>>> 410 * function or, for a statically linked agent named 'L', the >>>>> 411 * Agent_OnAttach_L function as specified in the >>>>> ==> >>>>> 409 * It then causes the target VM to invoke the Agent_OnAttach[_L] >>>>> 410 * function as specified in the >>>>> >>>> I left the above as is since it's part of the method description. The following fragments below I simplified as you suggested. >>>> >>>>> the following 4 identical fragments: >>>>> >>>>> 341 * If the Agent_OnAttach function returns an error >>>>> 342 * or, for a statically linked agent named 'L', if the >>>>> 343 * Agent_OnAttach_L function returns >>>>> 344 * an error. >>>>> 375 * If the Agent_OnAttach function returns an error >>>>> 376 * or, for a statically linked agent named 'L', if the >>>>> 377 * Agent_OnAttach_L function returns >>>>> 378 * an error. >>>>> 442 * If the Agent_OnAttach function returns an error >>>>> 443 * or, for a statically linked agent named 'L', if the >>>>> 444 * Agent_OnAttach_L function returns an error >>>>> 475 * If the Agent_OnAttach function returns an error >>>>> 476 * or, for a statically linked agent named 'L', if the >>>>> 477 * Agent_OnAttach_L function returns >>>>> 478 * an error. >>>>> ==> >>>>> >>>>> 336 * If the Agent_OnAttach[_L] function returns an error. >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>> >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>> src/share/vm/prims/jvmti.xml >>>>> >>>>> Lines 442-462: many extra

's. The fragment does not look well. >>>>> I'd suggest to remove most of them. >>>>> Also, these lines are too long. Could you make them shorter, please? >>>>> The same is applied to other long new lines in this file. >>>> Cleaned this up a bit. >>>>> Lines 490-491, 502-503, 505-506: >>>>> The same sentence is repeated 3 times: "the agent library may be statically linked ..." >>>>> >>>>> 490 Note that the agent library may be statically linked into the executable >>>>> 491 in which case no actual loading takes place. >>>> Fixed. >>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is specified, the VM will attempt to >>>>> 502 load the shared library c:\myLibs\foo.dll. As mentioned above, the agent library may be statically linked into the executable >>>>> 503 in which case no actual loading takes place >>>>> >>>>> 505 Note that the agent library may be statically linked into the executable >>>>> 506 in which case no actual loading takes place. >>>>> >>>> Tweaked the above a bit to make it less wordy. >>>> >>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>> >>>>> 677 and enabled the event >>>>> >>>> Fixed. >>>>> src/os/posix/vm/os_posix.cpp >>>>> >>>>> - no comments >>>>> >>>>> src/os/windows/vm/os_windows.cpp >>>>> >>>>> - no comments >>>>> >>>>> src/share/vm/prims/jvmtiExport.cpp >>>>> >>>>> - no comments >>>>> >>>>> src/share/vm/runtime/arguments.hpp >>>>> >>>>> - no comments >>>>> >>>>> src/share/vm/runtime/os.cpp >>>>> >>>>> Space is missed after the 'if': >>>>> 471 if(entryName != NULL) { >>>>> >>>> Fixed. >>>>> Extra space after the '*': >>>>> 483 void * saveHandle; >>>>> >>>> Fixed. >>>>> src/share/vm/runtime/os.hpp >>>>> >>>>> - no comments >>>>> >>>>> src/share/vm/runtime/thread.cpp >>>>> >>>>> The line has been removed: >>>>> 3866 break; >>>>> >>>> Correct, the inner for loop was removed so no need for the break; >>>>> I'm still in process of reading the code. >>>>> Another pass is needed to make sure that nothing is missed. >>>>> But in general, the code quality is pretty good. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: >>>>>> Still need an official reviewer for the hotspot changes for statically linked agents. >>>>>> >>>>>> thanks, >>>>>> bill >>>>>> >>>>>>> These changes address bug 8014135 which adds support for statically linked agents in the VM. This is a followup to the recent JNI spec changes that addressed statically linked JNI libraries( 8005716). >>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>> http://openjdk.java.net/jeps/178 >>>>>>> >>>>>>> Webrevs are here: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>> >>>>>>> The changes to jvmti.xml can also be seen in the output file that I placed here: >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>> >>>>>>> Thanks, >>>>>>> bill >>>>>>> >>>> From serguei.spitsyn at oracle.com Tue Aug 6 12:10:31 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 06 Aug 2013 12:10:31 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <52014720.3040500@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <52014720.3040500@oracle.com> Message-ID: <52014A27.30404@oracle.com> On 8/6/13 11:57 AM, serguei.spitsyn at oracle.com wrote: > On 8/5/13 7:41 AM, Bob Vandette wrote: >> On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: >> >>> On 8/2/2013 9:12 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Bill, >>>> >>>> A couple of more questions. >>>> >>>> webrev.01/jvmti.html >>>> >>>> An agent L whose image has been combined with the VM *is defined* >>>> as /statically linked/ >>>> if and only if the agent exports a function called Agent_OnLoad_L. >>>> >>>> A question to the above. >>>> Are we going to allow to link a library dynamically if it exports both >>>> the Agent_OnLoad and Agent_OnLoad_L functions? >>>> It can be convenient if a library exports both Agent_OnLoad and >>>> Agent_OnLoad_L >>>> as it can be linked statically or dynamically depending on the need >>>> without changes. >>>> >>> It would be nice but the problem is that you could only link one >>> agent into the VM if it exported Agent_OnLoad. Otherwise there would >>> be a symbol collision with the second agent you linked in that also >>> had Agent_OnLoad. As an agent developer you will have to select one >>> or the other at build time, either statically linked in or dynamic. >>>> You already added the following statement to the JVMTI spec: >>>> If a /statically linked/ agent L exports a function called >>>> Agent_OnLoad_L and >>>> a function called Agent_OnLoad, the Agent_OnLoad function will be >>>> ignored. >>>> >>>> Could we say it in a shorter form?: >>>> If a /statically linked/ agent L exports a function called >>>> Agent_OnLoad, >>>> the Agent_OnLoad function will be ignored. >>> I believe I copied this from JNI static linking JEP. If so, I'll >>> probably leave it as is just for consistency with JNI static spec. >>> JVM TI static linking spec is closely related to JNI static linking >>> spec. >>>> In this context would it be reasonable to add another statement: >>>> If a /dynamically linked/ agent L exports a function called >>>> Agent_OnLoad_L, >>>> the Agent_OnLoad_L function will be ignored. >>>> >> I'd rather leave this undefined since the behavior is very platform >> specific. >> The way we determine if a library is statically linked is by the >> presence of the Agent_OnLoad_L function. >> If this function exists in a dynamically linked library, it will be >> treated as a static library if by some chance >> it's attempted to be loaded twice, since the symbol will may be >> visible in the running process. > (I've added Alan and Coleen to the cc-list) > > It is still not clear to me how the second load might happen. It is inaccurate statement above. I wanted to say "such a second load" that will determine the dynamically loaded agent as statically loaded. Thanks, Serguei > > The agent is determined as statically loaded if the Agent_OnLoad_L > function > is found in the main program, not in the dynamic library. > At least, the dll_lookup is done for the main program (for > DefaultProcessHandle). > If the agent is loaded dynamically, the Agent_OnLoad_L function in the > agent library > can be ignored because the dll_lookup in the main program will not > find it. > In a case of the second load this function will be ignored again. > So that there is no conflict with the dynamically loaded agent here. > > We can skip this issue for now. > Alan is going to review the JEP from the dynamic Attach point of view > and hopefully will pay attention to these details. > > Thanks, > Serguei > >> >> Bob. >> >> >>>> The same questions apply to the Agent_OnAttach and Agent_OnAttach_L >>>> entry points. >>>> >>> I'm out on vacation for a couple of weeks so I'll leave it up to Bob >>> V. and yourself if you guys want to hash out better/different wording. >>> >>> bill >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 7/30/13 12:17 PM, bill.pittore at oracle.com wrote: >>>>> Thanks Serguei for the comments. Some comments inline. I updated >>>>> the webrevs at >>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>>> >>>>> >>>>> >>>>> On 7/26/2013 5:00 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Bill, >>>>>> >>>>>> Sorry for the big delay. >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>>> >>>>>> >>>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>>> >>>>>> >>>>>> I'm suggesting to use the reference >>>>>> *Agent_OnAttach[_L]**||* even more consistently. >>>>>> (If, in some cases, you prefer the longer form to underline the >>>>>> difference between >>>>>> dynamically and statically linked libraries then feel free to >>>>>> leave it as it is.) >>>>>> >>>>>> It would simplify the following fragments: >>>>>> >>>>>> 304 * It then causes the target VM to invoke the >>>>>> Agent_OnAttach function >>>>>> 305 * or, for a statically linked agent named 'L', the >>>>>> Agent_OnAttach_L function >>>>>> ==> >>>>>> >>>>>> 304 * It then causes the target VM to invoke the >>>>>> Agent_OnAttach[_L] function >>>>>> >>>>>> 409 * It then causes the target VM to invoke the >>>>>> Agent_OnAttach >>>>>> 410 * function or, for a statically linked agent named 'L', the >>>>>> 411 * Agent_OnAttach_L function as specified in >>>>>> the >>>>>> ==> >>>>>> 409 * It then causes the target VM to invoke the >>>>>> Agent_OnAttach[_L] >>>>>> 410 * function as specified in the >>>>>> >>>>> I left the above as is since it's part of the method description. >>>>> The following fragments below I simplified as you suggested. >>>>> >>>>>> the following 4 identical fragments: >>>>>> >>>>>> 341 * If the Agent_OnAttach function >>>>>> returns an error >>>>>> 342 * or, for a statically linked agent named >>>>>> 'L', if the >>>>>> 343 * Agent_OnAttach_L function returns >>>>>> 344 * an error. >>>>>> 375 * If the Agent_OnAttach function >>>>>> returns an error >>>>>> 376 * or, for a statically linked agent named >>>>>> 'L', if the >>>>>> 377 * Agent_OnAttach_L function returns >>>>>> 378 * an error. >>>>>> 442 * If the Agent_OnAttach function >>>>>> returns an error >>>>>> 443 * or, for a statically linked agent named >>>>>> 'L', if the >>>>>> 444 * Agent_OnAttach_L function returns an error >>>>>> 475 * If the Agent_OnAttach function >>>>>> returns an error >>>>>> 476 * or, for a statically linked agent named >>>>>> 'L', if the >>>>>> 477 * Agent_OnAttach_L function returns >>>>>> 478 * an error. >>>>>> ==> >>>>>> >>>>>> 336 * If the Agent_OnAttach[_L] >>>>>> function returns an error. >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>> >>>>>> src/share/vm/prims/jvmti.xml >>>>>> >>>>>> Lines 442-462: many extra

's. The fragment does not look well. >>>>>> I'd suggest to remove most of them. >>>>>> Also, these lines are too long. Could you make them shorter, please? >>>>>> The same is applied to other long new lines in this file. >>>>> Cleaned this up a bit. >>>>>> Lines 490-491, 502-503, 505-506: >>>>>> The same sentence is repeated 3 times: "the agent library >>>>>> may be statically linked ..." >>>>>> >>>>>> 490 Note that the agent library may be statically linked into >>>>>> the executable >>>>>> 491 in which case no actual loading takes place. >>>>> Fixed. >>>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is >>>>>> specified, the VM will attempt to >>>>>> 502 load the shared library >>>>>> c:\myLibs\foo.dll. As mentioned above, the agent >>>>>> library may be statically linked into the executable >>>>>> 503 in which case no actual loading takes place >>>>>> >>>>>> 505 Note that the agent library may be statically linked into >>>>>> the executable >>>>>> 506 in which case no actual loading takes place. >>>>>> >>>>> Tweaked the above a bit to make it less wordy. >>>>> >>>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>>> >>>>>> 677 and enabled the event >>>>>> >>>>> Fixed. >>>>>> src/os/posix/vm/os_posix.cpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/os/windows/vm/os_windows.cpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/share/vm/prims/jvmtiExport.cpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/share/vm/runtime/arguments.hpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/share/vm/runtime/os.cpp >>>>>> >>>>>> Space is missed after the 'if': >>>>>> 471 if(entryName != NULL) { >>>>>> >>>>> Fixed. >>>>>> Extra space after the '*': >>>>>> 483 void * saveHandle; >>>>>> >>>>> Fixed. >>>>>> src/share/vm/runtime/os.hpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/share/vm/runtime/thread.cpp >>>>>> >>>>>> The line has been removed: >>>>>> 3866 break; >>>>>> >>>>> Correct, the inner for loop was removed so no need for the break; >>>>>> I'm still in process of reading the code. >>>>>> Another pass is needed to make sure that nothing is missed. >>>>>> But in general, the code quality is pretty good. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: >>>>>>> Still need an official reviewer for the hotspot changes for >>>>>>> statically linked agents. >>>>>>> >>>>>>> thanks, >>>>>>> bill >>>>>>> >>>>>>>> These changes address bug 8014135 which adds support for >>>>>>>> statically linked agents in the VM. This is a followup to the >>>>>>>> recent JNI spec changes that addressed statically linked JNI >>>>>>>> libraries( 8005716). >>>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>>> http://openjdk.java.net/jeps/178 >>>>>>>> >>>>>>>> Webrevs are here: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>> >>>>>>>> The changes to jvmti.xml can also be seen in the output file >>>>>>>> that I placed here: >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> bill >>>>>>>> >>>>> > From coleen.phillimore at oracle.com Tue Aug 6 14:52:54 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 06 Aug 2013 17:52:54 -0400 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: <51F7F13E.8040104@oracle.com> References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com> <51F70A00.7010505@oracle.com> <51F7317C.5030400@oracle.com> <51F74985.6070905@oracle.com> <51F74AE9.3050603@oracle.com> <51F7F13E.8040104@oracle.com> Message-ID: <52017036.5030301@oracle.com> Serguei, This looks good. It's a lot cleaner than I thought it'd be. Do more of these nsk.mlvm tests pass with this change? Thanks! Coleen On 07/30/2013 01:00 PM, serguei.spitsyn at oracle.com wrote: > The updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.3/ > > > Thanks, > Serguei > > On 7/29/13 10:11 PM, David Holmes wrote: >> Hi Serguei, >> >> I'm fine with restoring to what was in the first webrev. >> >> Further trimming of the JVMTI code is something the embedded folk >> could look at. It may not be worthwhile. >> >> Thanks, >> David >> >> On 30/07/2013 3:05 PM, serguei.spitsyn at oracle.com wrote: >>> On 7/29/13 8:22 PM, David Holmes wrote: >>>> On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote: >>>>> Christian and David, >>>>> >>>>> Thank you for the quick review and comments! >>>>> >>>>> This is a new version of webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2 >>>>> >>>>> >>>> >>>> Sorry. You need that guard after all - at least you do if you continue >>>> to use it in interpreterRuntime - otherwise member_name_arg_or_null >>>> will not exist: >>>> >>>> __ call_VM(rax, CAST_FROM_FN_PTR(address, >>>> InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi); >>>> >>> You are right, nice catch again. >>> Probably, it was the reason, I did not remove the #if/#endif in the >>> first place. :) >>> >>>> I'm a little surprised that the assembly code does not have that whole >>>> section guarded with INCLUDE_JVMTI - perhaps it should? >>> It should. >>> But it can be non-trivial because of other dependencies like the above. >>> To make it right, both _remove_activation_preserving_args_entry and >>> generate_earlyret_entry_for >>> must be isolated with #if INCLUDE_JVMTI. >>> Then more files have to be involved in this chain of changes: >>> interpreter/templateInterpreter.hpp >>> interpreter/templateInterpreter.hpp >>> memory/universe.hpp >>> memory/universe.cpp >>> code/codeCache.hpp >>> code/codeCache.cpp >>> . . . etc .. >>> >>> Please, note, that the HOTSWAP macro is used in many places as well. >>> I'm not sure we still need it, so that another decision is needed >>> for it. >>> >>> So, it seems that this kind of clean up is going far beyond my fix. >>> My suggestion is to restore the "#if INCLUDE_JVMTI" in 3 >>> platform-dependent files as it was in the webrev v1. >>> I'm a little bit reluctant to open another clean-up bug for this issue >>> but maybe it is needed. >>> Please, let me know if you are comfortable with this solution. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Run this through a JPRT test build for productEmb to check that the >>>> minimal VM builds ok. >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 7/28/13 9:11 PM, David Holmes wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> >>>>>>> Please, review the fix for: >>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >>>>>>> >>>>>>> Open webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> In the templateInterpreter code why did you put this guard on >>>>>> your new >>>>>> code (from x86_32 version): >>>>>> >>>>>> 1923 #if INCLUDE_JVMTI >>>>>> >>>>>> when the whole chunk of code this is situated in is specifically for >>>>>> JVMTI support >>>>>> >>>>>> 1824 // >>>>>> 1825 // JVMTI PopFrame support >>>>>> 1826 // >>>>>> >>>>>> ??? >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> Restore the appendix argument of a polymorphic intrinsic call >>>>>>> needed for a invokestatic re-execution after JVMTI PopFrame(). >>>>>>> >>>>>>> Description >>>>>>> When JVMTI's PopFrame removes a frame that was called via a call >>>>>>> site >>>>>>> that >>>>>>> takes an appendix and that call site is reexecuted the >>>>>>> appendix is >>>>>>> not on >>>>>>> the stack anymore because it got removed by the adapter. >>>>>>> This fix is to detect such a case and push the appendix on the >>>>>>> stack >>>>>>> again before reexecution. >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, >>>>>>> nsk.jdi.testlist >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>> >>> > From serguei.spitsyn at oracle.com Tue Aug 6 15:28:00 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 06 Aug 2013 15:28:00 -0700 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: <52017036.5030301@oracle.com> References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com> <51F70A00.7010505@oracle.com> <51F7317C.5030400@oracle.com> <51F74985.6070905@oracle.com> <51F74AE9.3050603@oracle.com> <51F7F13E.8040104@oracle.com> <52017036.5030301@oracle.com> Message-ID: <52017870.4010503@oracle.com> Coleen, Thank you a lot for reviewing! At least, one mlvm test is reliably passing with this fix: vm/mlvm/indy/func/jvmti/stepBreakPopReturn It is possible that the fix positively impacts more tests but the picture is not clear yet as it is masked by a couple of more jsr-292 related jvmti and test bugs. Thanks, Serguei On 8/6/13 2:52 PM, Coleen Phillimore wrote: > > Serguei, > > This looks good. It's a lot cleaner than I thought it'd be. Do more > of these nsk.mlvm tests pass with this change? > > Thanks! > Coleen > > On 07/30/2013 01:00 PM, serguei.spitsyn at oracle.com wrote: >> The updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.3/ >> >> >> Thanks, >> Serguei >> >> On 7/29/13 10:11 PM, David Holmes wrote: >>> Hi Serguei, >>> >>> I'm fine with restoring to what was in the first webrev. >>> >>> Further trimming of the JVMTI code is something the embedded folk >>> could look at. It may not be worthwhile. >>> >>> Thanks, >>> David >>> >>> On 30/07/2013 3:05 PM, serguei.spitsyn at oracle.com wrote: >>>> On 7/29/13 8:22 PM, David Holmes wrote: >>>>> On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Christian and David, >>>>>> >>>>>> Thank you for the quick review and comments! >>>>>> >>>>>> This is a new version of webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2 >>>>>> >>>>>> >>>>> >>>>> Sorry. You need that guard after all - at least you do if you >>>>> continue >>>>> to use it in interpreterRuntime - otherwise member_name_arg_or_null >>>>> will not exist: >>>>> >>>>> __ call_VM(rax, CAST_FROM_FN_PTR(address, >>>>> InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi); >>>>> >>>> You are right, nice catch again. >>>> Probably, it was the reason, I did not remove the #if/#endif in the >>>> first place. :) >>>> >>>>> I'm a little surprised that the assembly code does not have that >>>>> whole >>>>> section guarded with INCLUDE_JVMTI - perhaps it should? >>>> It should. >>>> But it can be non-trivial because of other dependencies like the >>>> above. >>>> To make it right, both _remove_activation_preserving_args_entry and >>>> generate_earlyret_entry_for >>>> must be isolated with #if INCLUDE_JVMTI. >>>> Then more files have to be involved in this chain of changes: >>>> interpreter/templateInterpreter.hpp >>>> interpreter/templateInterpreter.hpp >>>> memory/universe.hpp >>>> memory/universe.cpp >>>> code/codeCache.hpp >>>> code/codeCache.cpp >>>> . . . etc .. >>>> >>>> Please, note, that the HOTSWAP macro is used in many places as well. >>>> I'm not sure we still need it, so that another decision is needed >>>> for it. >>>> >>>> So, it seems that this kind of clean up is going far beyond my fix. >>>> My suggestion is to restore the "#if INCLUDE_JVMTI" in 3 >>>> platform-dependent files as it was in the webrev v1. >>>> I'm a little bit reluctant to open another clean-up bug for this issue >>>> but maybe it is needed. >>>> Please, let me know if you are comfortable with this solution. >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Run this through a JPRT test build for productEmb to check that the >>>>> minimal VM builds ok. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 7/28/13 9:11 PM, David Holmes wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> >>>>>>>> Please, review the fix for: >>>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >>>>>>>> >>>>>>>> Open webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> In the templateInterpreter code why did you put this guard on >>>>>>> your new >>>>>>> code (from x86_32 version): >>>>>>> >>>>>>> 1923 #if INCLUDE_JVMTI >>>>>>> >>>>>>> when the whole chunk of code this is situated in is specifically >>>>>>> for >>>>>>> JVMTI support >>>>>>> >>>>>>> 1824 // >>>>>>> 1825 // JVMTI PopFrame support >>>>>>> 1826 // >>>>>>> >>>>>>> ??? >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> Restore the appendix argument of a polymorphic intrinsic call >>>>>>>> needed for a invokestatic re-execution after JVMTI PopFrame(). >>>>>>>> >>>>>>>> Description >>>>>>>> When JVMTI's PopFrame removes a frame that was called via a >>>>>>>> call >>>>>>>> site >>>>>>>> that >>>>>>>> takes an appendix and that call site is reexecuted the >>>>>>>> appendix is >>>>>>>> not on >>>>>>>> the stack anymore because it got removed by the adapter. >>>>>>>> This fix is to detect such a case and push the appendix on the >>>>>>>> stack >>>>>>>> again before reexecution. >>>>>>>> >>>>>>>> >>>>>>>> Testing: >>>>>>>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, >>>>>>>> nsk.jdi.testlist >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>> >>>> >> > From stefan.karlsson at oracle.com Wed Aug 7 02:30:46 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 07 Aug 2013 11:30:46 +0200 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: References: <51D3065C.6090401@oracle.com> Message-ID: <520213C6.1050407@oracle.com> Hi Volker, Thanks for taking a look at this! Inlined: On 2013-07-16 19:21, Volker Simonis wrote: > Hi Stefan, > > this is a very interesting change! Although I haven?t had a chance to > dig trough the whole change and test it, I want to make a few comments > beforehand: If you do find the time to test this, please share your findings. > > I think this change will help to make 'UseHugeTLBFS' work on > Linux/PPC64. The problem with the current strategy on PPC64 is that on > PPC64 we have different memory slices (256M slices below 4G, then 4G > slices below 1TB and finally 1TB slices above that) and each slice > supports only one page size (I got this information from Tiago St?rmer > Daitx from the IBM Linux Technology Center: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-April/000445.html). > So with the old strategy, the first mmap(MAP_NORESERVE) ends up in a > memory slice with small pages and the subsequent > mmap(MAP_FIXED,MAP_HUGETLB) will fail because the reserved memory is > already located in a slice with small pages only. So I think your > change where the large pages are committed upfront will solve this > problem (though I haven?t tired until now). OK. It sounds like the current code would only work if you only allocate from the same slice and if LargePageSizeInBytes is setup correctly for that slice. > > Currently, Linux/PPC64 doesn't support transparent huge pages, but > there seems to be a new implementation in the upcoming Linux Kernel > 3.11 (see: http://lkml.indiana.edu/hypermail/linux/kernel/1307.0/01916.html). > I'm wondering how this can work with the 'memory slicing' mentioned > before but that's another question which I'll try to find out from the > IBM colleagues. > > I've also collected all kinds of information regarding > LargePages/mmap/etc on Linux which I'd like to put in the HotSpot > Wiki. I'd also like to add the explanations from your mail. Would it > be OK for you if I'd create a new page (i.e. under > HotSpot->Runtime->LargePageSupport) where we could collect this > information? Sure. > > How did you test transparent huge page support and did you compare it > with the old UseHugeTLBFS? I've done performance testing on SPECjbb2005 comparing without large pages, with transparent huge pages and UseHugeTLBFS. In those runs transparent huge pages are marginally slower than UseHugeTLBFS, but still significantly faster than running without large pages. > I wonder how transparent huge page support > works in the real world, because madvise is after all only an advise. > The result depends on the kernel settings > (/sys/kernel/mm/transparent_hugepage/) as well as on the fact how well > the 'khugepaged' works. If I read the transparent huge page > documentation (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/vm/transhuge.txt) > it seems to me that there are still a lot of tuning paramters. I agree > that the general usage is easier compared to 'UseHugeTLBFS' but on the > other hand, once UseHugeTLBFS succeeds we have the huge pages forever. I agree. I've been told that transparent huge pages can have a huge overhead. Do you think it's wrong to default to transparent huge pages when the user has not specified any large pages flags? The other option would be to not turn on large pages at all, unless the user specifies large pages flags. I think it's OK to default to transparent huge pages, since the user have that option enabled in the OS and have the ability to turn them off if they are too intrusive. > > And finally, are these changes really intended for hs24 as denoted in > the subject? They were intended for hs24, but we couldn't get enough testing done in time to include this rather large behavioral change. Since this wasn't included in hs24, I'll try to bring this in through hs25 (JDK8) before, potentially, bringing this into a JDK7 update release. There are changes going into hs25 that conflicts with my patch, so i need to resolve those issues before publishing the hs25 review request. > Then I don't understand your comment that "Unfortunately, > it's not likely that we'll get this into the hs24 release." That comment was meant for Florian Weimer's question about: JDK-8012015 : Use PROT_NONE when reserving memory http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8012015 > > Thank you and best regards, > Volker > > PS: by the way, where did you get the information from that a failing > "mmap(addr, size, ... MAP_FIXED|MAP_HUGETLB ...)" will remove the > previous mapping? I couldn't find t hat anywhere. I found that this was the way the linux kernel behaved while debugging the original crash. I filed a bug against the Kernel: https://bugzilla.kernel.org/show_bug.cgi?id=57951 Unfortunately, this seems to be the intended behavior. > (I think this may > also be one of the reasons why we sometimes loose the guard page > protection for a thread. We thought we fixed that problem ("7107135 : > Stack guard pages are no more protected after loading a shared library > with executable stack", > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7107135) but maybe > we only fixed one reason? What if a thread places it's stack into the > area of the removed mapping and afterwards, when the memory is mmaped > with small pages, the guard pages of the thread will become read/write > permissions.) Sounds reasonable. Also, note that a failing mmap(... MAP_FIXED ...) with small pages will loose the reservation. The following change tries to detect that and gracefully shut down the JVM: http://hg.openjdk.java.net/jdk7u/jdk7u40/hotspot/rev/a1a295252814 thanks, StefanK > > > On Tue, Jul 2, 2013 at 6:57 PM, Stefan Karlsson > wrote: >> http://cr.openjdk.java.net/~stefank/8007074/webrev.00/ >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007074 >> >> The default way of using Large Pages in HotSpot on Linux (UseHugeTLBFS) is >> broken. This is causing a number of crashes in different subsystems of the >> JVM. >> >> >> Bug Description >> =============== >> >> The main reason for this bug is that mmap(addr, size, ... >> MAP_FIXED|MAP_HUGETLB ...) will remove the previous mapping at [addr, >> addr+size) when we run out of large pages on Linux. >> >> This affects different parts of the JVM, but the most obvious is the >> allocation of the Java heap: >> >> When the JVM starts it reserves a memory area for the entire Java heap. We >> use mmap(...MAP_NORESERVE...) to reserve a contiguous chunk of memory that >> no other >> subsystem of the JVM, or Java program, will be allowed to mmap into. >> >> The reservation of the memory only reflects the maximum possible heap size, >> but often a smaller heap size is used if the memory pressure is low. The >> part of >> the heap that is actually used is committed with mmap(...MAP_FIXED...). When >> the heap is growing we commit a consecutive chunk of memory after the >> previously committed memory. We rely on the fact that no other thread will >> mmap into the reserved memory area for the Java heap. >> >> The actual committing of the memory is done by first trying to allocate >> large pages with mmap(...MAP_FIXED|MAP_HUGETLB...), and if that fails we >> call mmap with the same parameters but without the large pages flag >> (MAP_HUGETLB). >> >> Just after we have failed to mmap large pages and before the small pages >> have been mmapped, there's an unmapped memory region in the middle of the >> Java heap, where other threads might mmap into. When that happens we get >> memory trashing and crashes. >> >> >> Large Pages in HotSpot - on Linux >> ================================= >> >> Currently, before the bug fix, HotSpot supports three ways of allocating >> large pages on Linux. >> 1) -XX:+UseSHM - Commits the large pages upfront when the memory is >> reserved. >> >> 2) -XX:+UseHugeTLBFS - This is the broken implementation. It's also the >> default way large pages are allocated. If the OS is correctly configured, we >> get these kind of large pages for three different reasons: >> 2.1) The user has not specified any large pages flags >> 2.2) The user has specified -XX:+UseLargePages >> 2.3) The user has specified -XX:+UseHugeTLBFS >> >> 3) Transparent Huge Pages - is supported on recent Linux Kernels. The user >> can choose to configure the OS to: >> 3.1) completely handle the allocation of large pages, or >> 3.2) let the JVM advise where it would be good to allocate large pages. >> There exist code for this today, that is guarded by the (2) >> -XX:+UseHugeTLBFS flag. >> >> >> The Proposed Patch >> ================== >> >> 4) Create a new flag -XX:+UseTransparentHugePages, and move the transparent >> huge pages advise in (3.2) out from the (2) -XX:+UseHugeTLBFS code. >> >> 5) Make -XX:+UseTransparentHugePages the default way to allocate large pages >> if the OS supports them. It will be the only kind of large pages we'll use >> if the user has not specified any large pages flags. >> >> 6) Change the order of how we choose the kind of large pages when >> -XX:+UseLargePages has been specified. It used to be UseHugeTLBFS then >> UseSHM, now it's UseTransparentHugePages, then UseHugeTLBFS, then UseSHM. >> >> 7) Implement a workaround fix for the (2) -XX:+UseHugeTLBFS implementation. >> With the fix the large pages are committed upfront when they are reserved. >> It's mostly the same way we do it for the older (1) -XX:+UseSHM large pages. >> This change will fix the bug, but has a couple of drawbacks: >> 7.1) We have to allocate the entire large pages memory area when it is >> reserved instead of when parts of it are committed. >> 7.2) We can't dynamically shrink or grow the used memory in the large pages >> areas. >> If these restrictions are not suitable for the user, then (3) >> -XX:+UseTransparentHugePages could be used instead. >> >> 8) Ignore -XX:LargePageSizeInBytes on Linux since the OS doesn't support >> multiple large page sizes and both the old code and new code is broken if >> the user is allowed to set it to some other value then the OS chosen value. >> Warn if the user specifies a value different than the OS default value. >> >> >> Testing >> ======= >> >> New unit tests have been added. These can be run in a non-product build >> with: >> java -XX:+ExecuteInternalVMTests -XX:+VerboseInternalVMTests > flags> -version >> >> unit tests: with and without large pages on Linux, Windows, Solaris, x86, >> x64, sparcv9. >> jprt: default >> jprt: -XX:+UseLargePages >> jprt: -XX:+UseLargePages -XX:-UseCompressedOops >> vm.quick.testlist, vm.pcl.testlist, vm.gc.testlist: multiple platforms, with >> large pages on all major GCs with and without compressed oops. >> SPECjbb2005 performance runs: on Linux x64 with -XX:+UseHugeTLBFS before and >> after the patch. >> Kitchensink: 3 days on Linux x64 >> >> >> thanks, >> StefanK From bob.vandette at oracle.com Wed Aug 7 06:53:46 2013 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 7 Aug 2013 09:53:46 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <52014A27.30404@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <52014720.3040500@oracle.com> <52014A27.30404@oracle.com> Message-ID: <97FE1714-F26A-4B84-A54C-9719CC54E92E@oracle.com> On Aug 6, 2013, at 3:10 PM, serguei.spitsyn at oracle.com wrote: > On 8/6/13 11:57 AM, serguei.spitsyn at oracle.com wrote: >> On 8/5/13 7:41 AM, Bob Vandette wrote: >>> On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: >>> >>>> On 8/2/2013 9:12 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Bill, >>>>> >>>>> A couple of more questions. >>>>> >>>>> webrev.01/jvmti.html >>>>> >>>>> An agent L whose image has been combined with the VM *is defined* as /statically linked/ >>>>> if and only if the agent exports a function called Agent_OnLoad_L. >>>>> >>>>> A question to the above. >>>>> Are we going to allow to link a library dynamically if it exports both >>>>> the Agent_OnLoad and Agent_OnLoad_L functions? >>>>> It can be convenient if a library exports both Agent_OnLoad and Agent_OnLoad_L >>>>> as it can be linked statically or dynamically depending on the need without changes. >>>>> >>>> It would be nice but the problem is that you could only link one agent into the VM if it exported Agent_OnLoad. Otherwise there would be a symbol collision with the second agent you linked in that also had Agent_OnLoad. As an agent developer you will have to select one or the other at build time, either statically linked in or dynamic. >>>>> You already added the following statement to the JVMTI spec: >>>>> If a /statically linked/ agent L exports a function called Agent_OnLoad_L and >>>>> a function called Agent_OnLoad, the Agent_OnLoad function will be ignored. >>>>> >>>>> Could we say it in a shorter form?: >>>>> If a /statically linked/ agent L exports a function called Agent_OnLoad, >>>>> the Agent_OnLoad function will be ignored. >>>> I believe I copied this from JNI static linking JEP. If so, I'll probably leave it as is just for consistency with JNI static spec. JVM TI static linking spec is closely related to JNI static linking spec. >>>>> In this context would it be reasonable to add another statement: >>>>> If a /dynamically linked/ agent L exports a function called Agent_OnLoad_L, >>>>> the Agent_OnLoad_L function will be ignored. >>>>> >>> I'd rather leave this undefined since the behavior is very platform specific. >>> The way we determine if a library is statically linked is by the presence of the Agent_OnLoad_L function. >>> If this function exists in a dynamically linked library, it will be treated as a static library if by some chance >>> it's attempted to be loaded twice, since the symbol will may be visible in the running process. >> (I've added Alan and Coleen to the cc-list) >> >> It is still not clear to me how the second load might happen. > > It is inaccurate statement above. > I wanted to say "such a second load" that will determine the dynamically loaded agent as statically loaded. Could you please restate the issue you'd like addressed. I don't think we can guarantee that an Agent_OnLoad_L symbol located in a shared library will not be visible to our running process on all operating system platforms. Bob. > > Thanks, > Serguei > >> >> The agent is determined as statically loaded if the Agent_OnLoad_L function >> is found in the main program, not in the dynamic library. >> At least, the dll_lookup is done for the main program (for DefaultProcessHandle). >> If the agent is loaded dynamically, the Agent_OnLoad_L function in the agent library >> can be ignored because the dll_lookup in the main program will not find it. >> In a case of the second load this function will be ignored again. >> So that there is no conflict with the dynamically loaded agent here. >> >> We can skip this issue for now. >> Alan is going to review the JEP from the dynamic Attach point of view and hopefully will pay attention to these details. >> >> Thanks, >> Serguei >> >>> >>> Bob. >>> >>> >>>>> The same questions apply to the Agent_OnAttach and Agent_OnAttach_L entry points. >>>>> >>>> I'm out on vacation for a couple of weeks so I'll leave it up to Bob V. and yourself if you guys want to hash out better/different wording. >>>> >>>> bill >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 7/30/13 12:17 PM, bill.pittore at oracle.com wrote: >>>>>> Thanks Serguei for the comments. Some comments inline. I updated the webrevs at >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>>>> >>>>>> >>>>>> On 7/26/2013 5:00 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Bill, >>>>>>> >>>>>>> Sorry for the big delay. >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>>>> >>>>>>> >>>>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>>>> >>>>>>> >>>>>>> I'm suggesting to use the reference *Agent_OnAttach[_L]**||* even more consistently. >>>>>>> (If, in some cases, you prefer the longer form to underline the difference between >>>>>>> dynamically and statically linked libraries then feel free to leave it as it is.) >>>>>>> >>>>>>> It would simplify the following fragments: >>>>>>> >>>>>>> 304 * It then causes the target VM to invoke the Agent_OnAttach function >>>>>>> 305 * or, for a statically linked agent named 'L', the Agent_OnAttach_L function >>>>>>> ==> >>>>>>> >>>>>>> 304 * It then causes the target VM to invoke the Agent_OnAttach[_L] function >>>>>>> >>>>>>> 409 * It then causes the target VM to invoke the Agent_OnAttach >>>>>>> 410 * function or, for a statically linked agent named 'L', the >>>>>>> 411 * Agent_OnAttach_L function as specified in the >>>>>>> ==> >>>>>>> 409 * It then causes the target VM to invoke the Agent_OnAttach[_L] >>>>>>> 410 * function as specified in the >>>>>>> >>>>>> I left the above as is since it's part of the method description. The following fragments below I simplified as you suggested. >>>>>> >>>>>>> the following 4 identical fragments: >>>>>>> >>>>>>> 341 * If the Agent_OnAttach function returns an error >>>>>>> 342 * or, for a statically linked agent named 'L', if the >>>>>>> 343 * Agent_OnAttach_L function returns >>>>>>> 344 * an error. >>>>>>> 375 * If the Agent_OnAttach function returns an error >>>>>>> 376 * or, for a statically linked agent named 'L', if the >>>>>>> 377 * Agent_OnAttach_L function returns >>>>>>> 378 * an error. >>>>>>> 442 * If the Agent_OnAttach function returns an error >>>>>>> 443 * or, for a statically linked agent named 'L', if the >>>>>>> 444 * Agent_OnAttach_L function returns an error >>>>>>> 475 * If the Agent_OnAttach function returns an error >>>>>>> 476 * or, for a statically linked agent named 'L', if the >>>>>>> 477 * Agent_OnAttach_L function returns >>>>>>> 478 * an error. >>>>>>> ==> >>>>>>> >>>>>>> 336 * If the Agent_OnAttach[_L] function returns an error. >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>> src/share/vm/prims/jvmti.xml >>>>>>> >>>>>>> Lines 442-462: many extra

's. The fragment does not look well. >>>>>>> I'd suggest to remove most of them. >>>>>>> Also, these lines are too long. Could you make them shorter, please? >>>>>>> The same is applied to other long new lines in this file. >>>>>> Cleaned this up a bit. >>>>>>> Lines 490-491, 502-503, 505-506: >>>>>>> The same sentence is repeated 3 times: "the agent library may be statically linked ..." >>>>>>> >>>>>>> 490 Note that the agent library may be statically linked into the executable >>>>>>> 491 in which case no actual loading takes place. >>>>>> Fixed. >>>>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is specified, the VM will attempt to >>>>>>> 502 load the shared library c:\myLibs\foo.dll. As mentioned above, the agent library may be statically linked into the executable >>>>>>> 503 in which case no actual loading takes place >>>>>>> >>>>>>> 505 Note that the agent library may be statically linked into the executable >>>>>>> 506 in which case no actual loading takes place. >>>>>>> >>>>>> Tweaked the above a bit to make it less wordy. >>>>>> >>>>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>>>> >>>>>>> 677 and enabled the event >>>>>>> >>>>>> Fixed. >>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/os/windows/vm/os_windows.cpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/share/vm/prims/jvmtiExport.cpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/share/vm/runtime/arguments.hpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/share/vm/runtime/os.cpp >>>>>>> >>>>>>> Space is missed after the 'if': >>>>>>> 471 if(entryName != NULL) { >>>>>>> >>>>>> Fixed. >>>>>>> Extra space after the '*': >>>>>>> 483 void * saveHandle; >>>>>>> >>>>>> Fixed. >>>>>>> src/share/vm/runtime/os.hpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/share/vm/runtime/thread.cpp >>>>>>> >>>>>>> The line has been removed: >>>>>>> 3866 break; >>>>>>> >>>>>> Correct, the inner for loop was removed so no need for the break; >>>>>>> I'm still in process of reading the code. >>>>>>> Another pass is needed to make sure that nothing is missed. >>>>>>> But in general, the code quality is pretty good. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: >>>>>>>> Still need an official reviewer for the hotspot changes for statically linked agents. >>>>>>>> >>>>>>>> thanks, >>>>>>>> bill >>>>>>>> >>>>>>>>> These changes address bug 8014135 which adds support for statically linked agents in the VM. This is a followup to the recent JNI spec changes that addressed statically linked JNI libraries( 8005716). >>>>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>>>> http://openjdk.java.net/jeps/178 >>>>>>>>> >>>>>>>>> Webrevs are here: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>> >>>>>>>>> The changes to jvmti.xml can also be seen in the output file that I placed here: >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> bill >>>>>>>>> >>>>>> >> > From daniel.daugherty at oracle.com Wed Aug 7 14:01:57 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 07 Aug 2013 21:01:57 +0000 Subject: hg: hsx/hotspot-main/hotspot: 12 new changesets Message-ID: <20130807210225.8D572486A2@hg.openjdk.java.net> Changeset: 9bd314787fad Author: mseledtsov Date: 2013-08-01 22:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9bd314787fad 8020614: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output Summary: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output Reviewed-by: kvn, ctornqvi, dholmes + test/testlibrary/OutputAnalyzerReportingTest.java ! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java ! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java Changeset: c01913206da5 Author: ctornqvi Date: 2013-08-01 22:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c01913206da5 8014294: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle Summary: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle Reviewed-by: coleenp, sspitsyn ! src/share/vm/services/management.cpp Changeset: 81e0f17ade64 Author: ctornqvi Date: 2013-08-01 22:25 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/81e0f17ade64 8009407: runtime/8000968/Test8000968.sh has incorrect check for proper config Summary: runtime/8000968/Test8000968.sh has incorrect check for proper config Reviewed-by: coleenp, mseledtsov, sspitsyn, hseigel - test/runtime/8000968/Test8000968.sh + test/runtime/CompressedOops/CompressedKlassPointerAndOops.java Changeset: 32e3bada0978 Author: kevinw Date: 2013-08-02 12:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/32e3bada0978 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() Reviewed-by: mgerdin, fparain, dcubed ! src/share/vm/services/gcNotifier.cpp Changeset: dee4c330acd4 Author: dcubed Date: 2013-08-02 08:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dee4c330acd4 Merge - test/runtime/8000968/Test8000968.sh Changeset: fa57c8104b76 Author: ctornqvi Date: 2013-08-02 18:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/fa57c8104b76 8009585: test/runtime/7196045 times out Summary: test/runtime/7196045 times out Reviewed-by: dholmes, mseledtsov - test/runtime/7196045/Test7196045.java + test/runtime/InternalApi/ThreadCpuTimesDeadlock.java Changeset: 0f209afdfcf8 Author: ctornqvi Date: 2013-08-02 18:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0f209afdfcf8 Merge Changeset: d02de8cac823 Author: ctornqvi Date: 2013-08-02 22:34 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d02de8cac823 Merge - test/runtime/7196045/Test7196045.java Changeset: e0379d5ba5d2 Author: kevinw Date: 2013-08-05 10:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e0379d5ba5d2 8021444: SA: ClassDump.run() should not ignore existing ClassFilter. Reviewed-by: minqi, poonam ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java Changeset: b67604b59546 Author: hseigel Date: 2013-08-04 16:30 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b67604b59546 7073961: [TESTBUG] closed/runtime/4845371/DBB.java failed on solaris 10 X65 Summary: Added a x86 64-bit Solaris shared library and rewrote test in Java Reviewed-by: dholmes, ctornqvi ! test/testlibrary/com/oracle/java/testlibrary/Platform.java Changeset: 9064e3a19525 Author: hseigel Date: 2013-08-05 08:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9064e3a19525 Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 22a5aff0df0b Author: dsamersoff Date: 2013-08-06 14:28 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/22a5aff0df0b 8019396: SA-JDI OSThread class initialization throws an exception Summary: Method sun.jvm.hotspot.runtime.OSThread.initialize throws a sun.jvm.hotspot.types.WrongTypeException Reviewed-by: dholmes, mgerdin ! agent/src/share/classes/sun/jvm/hotspot/jdi/JVMTIThreadState.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java From dmitry.samersoff at oracle.com Thu Aug 8 04:49:36 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 08 Aug 2013 15:49:36 +0400 Subject: Assembler error on FreeBSD 9.1, toolchain problem? In-Reply-To: <520303AF.3050207@oracle.com> References: <520303AF.3050207@oracle.com> Message-ID: <520385D0.2060102@oracle.com> Filed a bug: https://jbs.oracle.com/bugs/browse/JDK-8022617 -Dmitry On 2013-08-08 06:34, David Holmes wrote: > Moving to build-dev as build-infra-dev is effectively obsolete now. > > The official gcc toolset is version 4.3 as I recall but as FreeBSD is > not one of Oracle's supported platforms that might not mean much. > Hopefully a fellow FreeBSD'er can assist but I'd certainly suggest > updating your toolset (but not too much as you'll then run into a > different set of problems!). > > Cheers, > David > > On 8/08/2013 9:00 AM, Henry Jen wrote: >> Hi, >> >> I tried to build OpenJDK 8 on my FreeBSD box, and encounter assembler >> error like following. Complete build.log and config.log are attached. >> >> Looks to me it probably a toolchain/environment issue, but I have no >> idea on what went wrong. The version of tools on the machine are >> >> $ gcc --version >> gcc (GCC) 4.2.1 20070831 patched [FreeBSD] >> Copyright (C) 2007 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There >> is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> >> $ as --version >> GNU assembler 2.17.50 [FreeBSD] 2007-07-03 >> Copyright 2007 Free Software Foundation, Inc. >> This program is free software; you may redistribute it under the terms of >> the GNU General Public License. This program has absolutely no warranty. >> This assembler was configured for a target of `x86_64-unknown-freebsd'. >> >> Is there a minimum version requirement of toolchain? Any one saw this >> before? >> >> Cheers, >> Henry >> >> Assembling >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s: >> Assembler messages: >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:39: Error: >> junk at end of line, first unrecognized character is `(' >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:40: Error: >> junk at end of line, first unrecognized character is `(' >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:41: Error: >> junk at end of line, first unrecognized character is `(' >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:42: Error: >> junk at end of line, first unrecognized character is `(' >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:43: Error: >> junk at end of line, first unrecognized character is `(' >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:44: Error: >> junk at end of line, first unrecognized character is `(' >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:45: Error: >> junk at end of line, first unrecognized character is `(' >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:49: Error: >> junk at end of line, first unrecognized character is `(' >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:51: Error: >> invalid character '_' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:52: Error: >> invalid character '(' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:66: Error: >> invalid character '_' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:67: Error: >> invalid character '(' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:168: >> Error: invalid character '_' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:169: >> Error: invalid character '_' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:170: >> Error: invalid character '(' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:171: >> Error: invalid character '(' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:258: >> Error: invalid character '_' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:259: >> Error: invalid character '_' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:260: >> Error: invalid character '(' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:261: >> Error: invalid character '(' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:337: >> Error: invalid character '_' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:338: >> Error: invalid character '_' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:339: >> Error: invalid character '(' in mnemonic >> /home/henryjen/ws/lambda/hotspot/src/os_cpu/bsd_x86/vm/bsd_x86_64.s:340: >> Error: invalid character '(' in mnemonic >> gmake[6]: *** [bsd_x86_64.o] Error 1 >> gmake[5]: *** [the_vm] Error 2 >> gmake[4]: *** [product] Error 2 >> gmake[3]: *** [generic_build2] Error 2 >> gmake[2]: *** [product] Error 2 >> gmake[1]: *** >> [/home/henryjen/ws/lambda/build/bsd-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >> Error 2 >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Thu Aug 8 07:33:22 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 08 Aug 2013 14:33:22 +0000 Subject: hg: hsx/hotspot-main/hotspot: 2 new changesets Message-ID: <20130808143330.75278486DF@hg.openjdk.java.net> Changeset: cd25d3be91c5 Author: vladidan Date: 2013-08-06 20:01 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cd25d3be91c5 8012144: multiple SIGSEGVs fails on staxf Summary: Forward port of 7u change to add additional fence() on RMO platforms, with a load_acquire on all platforms Reviewed-by: dholmes, kvn ! src/share/vm/utilities/taskqueue.hpp Changeset: f5bed20f2492 Author: dholmes Date: 2013-08-08 08:29 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f5bed20f2492 Merge From john.coomes at oracle.com Thu Aug 8 10:32:29 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 08 Aug 2013 17:32:29 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b102 for changeset 5eb3c1dc348f Message-ID: <20130808173229.5F6EE486EE@hg.openjdk.java.net> Changeset: b7e64be81c8a Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/b7e64be81c8a Added tag jdk8-b102 for changeset 5eb3c1dc348f ! .hgtags From john.coomes at oracle.com Thu Aug 8 10:32:32 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 08 Aug 2013 17:32:32 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b102 for changeset 528c7e76eaee Message-ID: <20130808173236.B42FB486EF@hg.openjdk.java.net> Changeset: f8ed09af1df6 Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/f8ed09af1df6 Added tag jdk8-b102 for changeset 528c7e76eaee ! .hgtags From john.coomes at oracle.com Thu Aug 8 10:32:41 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 08 Aug 2013 17:32:41 +0000 Subject: hg: hsx/hotspot-main/jaxp: 4 new changesets Message-ID: <20130808173302.F2AA5486F0@hg.openjdk.java.net> Changeset: 251ca1e2ccd3 Author: joehw Date: 2013-07-25 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/251ca1e2ccd3 8021148: Regression in SAXParserImpl in 7u40 b34 (NPE) Reviewed-by: chegar, lancea, dfuchs ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java Changeset: 467e1948612d Author: lana Date: 2013-07-26 14:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/467e1948612d Merge Changeset: 7cffafa606e9 Author: lana Date: 2013-08-06 10:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/7cffafa606e9 Merge Changeset: b1ceab582fc6 Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/b1ceab582fc6 Added tag jdk8-b102 for changeset 7cffafa606e9 ! .hgtags From john.coomes at oracle.com Thu Aug 8 10:33:10 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 08 Aug 2013 17:33:10 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b102 for changeset 988a5f2ac559 Message-ID: <20130808173319.AB6B6486F1@hg.openjdk.java.net> Changeset: 6cdc6ed98780 Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/6cdc6ed98780 Added tag jdk8-b102 for changeset 988a5f2ac559 ! .hgtags From john.coomes at oracle.com Thu Aug 8 10:37:43 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 08 Aug 2013 17:37:43 +0000 Subject: hg: hsx/hotspot-main/jdk: 73 new changesets Message-ID: <20130808175504.6B5F1486F4@hg.openjdk.java.net> Changeset: 2978c0a543ed Author: prr Date: 2013-07-22 12:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2978c0a543ed 7196866: CTW fails on all Solaris platforms Reviewed-by: prr, jrose, twisti, kvn ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 784589c7bc55 Author: vadim Date: 2013-07-24 13:38 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/784589c7bc55 8008782: NPE in TrueTypeGlyphMapper Reviewed-by: bae, prr ! src/share/classes/sun/font/TrueTypeFont.java Changeset: db2e3a686cf3 Author: jchen Date: 2013-07-24 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/db2e3a686cf3 8011709: [parfait] False positive: memory leak in jdk/src/share/native/sun/font/layout/CanonShaping.cpp Reviewed-by: jgodinez, prr ! src/share/native/sun/font/layout/CanonShaping.cpp Changeset: c2e27e7a42ae Author: jchen Date: 2013-07-24 13:05 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c2e27e7a42ae 8005126: [parfait] #418 - #428 XRBackendNative.c Integer overflow Reviewed-by: prr, vadim ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 833f05116f7b Author: bae Date: 2013-07-25 17:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/833f05116f7b 8019201: Regression: java.awt.image.ConvolveOp throws java.awt.image.ImagingOpException Reviewed-by: prr ! src/share/native/sun/awt/medialib/awt_ImagingLib.c + test/sun/awt/image/ImagingLib/SamePackingTypeTest.java Changeset: a8b9df782017 Author: serb Date: 2013-07-26 21:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a8b9df782017 7190349: [macosx] Text (Label) is incorrectly drawn with a rotated g2d 8013569: [macosx] JLabel preferred size incorrect on retina displays with non-default font size Reviewed-by: prr ! src/macosx/classes/sun/font/CStrike.java ! src/macosx/native/sun/font/AWTStrike.h ! src/macosx/native/sun/font/AWTStrike.m ! src/macosx/native/sun/font/CGGlyphImages.m + test/java/awt/Graphics2D/DrawString/DrawRotatedString.java + test/java/awt/Graphics2D/IncorrectTextSize/IncorrectTextSize.java Changeset: 467a0c21790b Author: jgodinez Date: 2013-07-26 15:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/467a0c21790b 8020208: NullPointerException at sun.print.Win32PrintService.getMediaPrintables Reviewed-by: jchen, prr ! src/windows/classes/sun/print/Win32PrintService.java Changeset: 56c6f9a9653d Author: jgodinez Date: 2013-07-26 15:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/56c6f9a9653d 8016343: [macosx] Print job goes to default printer regardless of chosen printer Reviewed-by: jchen, prr ! src/share/classes/sun/print/PSPrinterJob.java ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintJob.java ! test/javax/print/DialogMargins.java Changeset: 1c48544c3da9 Author: lana Date: 2013-07-26 15:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1c48544c3da9 Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 921338e44ba7 Author: lana Date: 2013-07-26 17:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/921338e44ba7 Merge Changeset: 046025f78ea8 Author: jgodinez Date: 2013-07-30 13:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/046025f78ea8 8021835: Fix for 8016343 will not compile on Windows. Reviewed-by: jchen, prr ! src/share/classes/sun/print/PSPrinterJob.java Changeset: 7f0e569c5a66 Author: bae Date: 2013-07-31 13:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7f0e569c5a66 8020983: OutOfMemoryError caused by non garbage collected JPEGImageWriter Instances Reviewed-by: prr, flar ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c + test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java Changeset: 607ad960fe24 Author: malenkov Date: 2013-07-22 15:36 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/607ad960fe24 8019975: closed/javax/swing/JFileChooser/4966171/bug4966171.java throws java.io.NotSerializableException: javax.swing.plaf.basic.BasicFileChooserUI$AcceptAllFileFilter Reviewed-by: alexsch ! src/share/classes/javax/swing/JFileChooser.java Changeset: 3cbe376233a9 Author: malenkov Date: 2013-07-22 20:33 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3cbe376233a9 8015926: NPE when using SynthTreeUI's expandPath() Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java + test/javax/swing/plaf/synth/Test8015926.java Changeset: bdad697c03aa Author: pchelko Date: 2013-07-23 13:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bdad697c03aa 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java Changeset: 99ee6ddab113 Author: serb Date: 2013-07-24 17:14 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/99ee6ddab113 8017189: [macosx] AWT program menu disabled on Mac Reviewed-by: leonidr, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CMenuBar.m Changeset: 7bd6eda2d217 Author: leonidr Date: 2013-07-26 16:22 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7bd6eda2d217 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working Reviewed-by: anthony, serb ! src/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java ! src/macosx/classes/sun/lwawt/macosx/CMenuComponent.java ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CMenuItem.m Changeset: 65c90209edbb Author: lana Date: 2013-07-26 15:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/65c90209edbb Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 37016eaea5d2 Author: serb Date: 2013-07-29 16:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/37016eaea5d2 6230360: Spelling mistake in documentation for AWT: 1.4, 1.5, 1.6, 1.7 Reviewed-by: malenkov, art ! src/share/classes/java/awt/AWTException.java Changeset: bf80c2965a84 Author: malenkov Date: 2013-07-29 18:48 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bf80c2965a84 8010782: clean up source files containing carriage return characters Reviewed-by: alexsch, art ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth.properties Changeset: 1e482f58c747 Author: ant Date: 2013-07-30 16:15 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1e482f58c747 8020927: JLightweightFrame API should export layout properties change notifications Reviewed-by: anthony ! src/share/classes/sun/swing/JLightweightFrame.java ! src/share/classes/sun/swing/LightweightContent.java Changeset: 336a94dbecb5 Author: malenkov Date: 2013-07-30 17:46 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/336a94dbecb5 8015300: JComboBox text sometimes become selected, sometimes not (Windows LAF) Reviewed-by: alexsch, serb ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java + test/javax/swing/JComboBox/8015300/Test8015300.java Changeset: 726ac8f75b54 Author: lana Date: 2013-07-31 12:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/726ac8f75b54 Merge Changeset: 6e10d93273d0 Author: juh Date: 2013-07-18 10:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6e10d93273d0 8020426: Fix doclint accessibility issues in java.io Reviewed-by: mduigou, darcy, chegar ! src/share/classes/java/io/DataInput.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/ObjectStreamField.java ! src/share/classes/java/io/RandomAccessFile.java Changeset: b39797bb86c0 Author: sherman Date: 2013-07-18 11:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b39797bb86c0 8016025: JSR 310 DateTime API Updates IV 8020418: Cleanup of -Xlint warnings in java.time 8016623: test/java/time/format/TestDateTimeTextProvider.java failing Summary: Integration of JSR310 Date/Time API update IV Reviewed-by: sherman Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, masayoshi.okutsu at oracle.com, patrick.zhang at oracle.com, chand.basha at oracle.com ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/ZoneRegion.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/JapaneseEra.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/chrono/package-info.java ! src/share/classes/java/time/format/DateTimeFormatter.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/DateTimePrintContext.java ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/ChronoField.java ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/TemporalUnit.java ! src/share/classes/java/time/temporal/ValueRange.java ! src/share/classes/java/time/temporal/WeekFields.java ! src/share/lib/hijrah-config-umalqura.properties ! test/java/time/tck/java/time/MockSimplePeriod.java ! test/java/time/tck/java/time/TCKClock_Fixed.java ! test/java/time/tck/java/time/TCKDayOfWeek.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKMonth.java ! test/java/time/tck/java/time/TCKMonthDay.java ! test/java/time/tck/java/time/TCKOffsetDateTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKPeriod.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronology.java ! test/java/time/tck/java/time/chrono/TCKHijrahChronology.java ! test/java/time/tck/java/time/chrono/TCKHijrahEra.java ! test/java/time/tck/java/time/chrono/TCKIsoChronology.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKJapaneseEra.java ! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java + test/java/time/tck/java/time/format/TCKFormatStyle.java + test/java/time/tck/java/time/format/TCKResolverStyle.java + test/java/time/tck/java/time/format/TCKSignStyle.java ! test/java/time/tck/java/time/format/TCKTextStyle.java ! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java + test/java/time/tck/java/time/temporal/TCKChronoField.java + test/java/time/tck/java/time/temporal/TCKChronoUnit.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java ! test/java/time/tck/java/time/zone/TCKZoneRules.java ! test/java/time/test/java/time/MockSimplePeriod.java ! test/java/time/test/java/time/chrono/TestChronoLocalDate.java ! test/java/time/test/java/time/chrono/TestExampleCode.java ! test/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java ! test/java/time/test/java/time/chrono/TestJapaneseChronology.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java ! test/java/time/test/java/time/format/TestDateTimeTextProvider.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/java/time/test/java/time/format/TestNumberPrinter.java ! test/java/time/test/java/time/format/TestReducedPrinter.java ! test/java/time/test/java/time/temporal/MockFieldNoValue.java ! test/java/time/test/java/time/temporal/MockFieldValue.java Changeset: 2323b973adaa Author: darcy Date: 2013-07-18 23:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2323b973adaa 8020810: Typo in javadoc for Class.toGenericString() Reviewed-by: dholmes ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Parameter.java Changeset: e6aeeec33e53 Author: uta Date: 2013-07-19 12:53 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e6aeeec33e53 8016579: (process) IOException thrown by ProcessBuilder.start() method is incorrectly encoded Reviewed-by: martin, dxu ! src/share/native/java/io/io_util.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/lang/ProcessImpl_md.c Changeset: e013b32118af Author: darcy Date: 2013-07-19 09:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e013b32118af 8020948: Fix doclint issues in misc package-info.java files Reviewed-by: dholmes, chegar ! src/share/classes/java/nio/file/attribute/package-info.java ! src/share/classes/java/util/function/package-info.java Changeset: 4bd04969a228 Author: darcy Date: 2013-07-20 11:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4bd04969a228 8020971: Fix doclint issues in java.nio.* Reviewed-by: lancea ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/charset/MalformedInputException.java ! src/share/classes/java/nio/charset/UnmappableCharacterException.java ! src/share/classes/java/nio/file/package-info.java Changeset: dcd89e60051a Author: khazra Date: 2013-07-22 15:24 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dcd89e60051a 8020498: Crash when both libnet.so and libmawt.so are loaded Reviewed-by: chegar, dsamersoff ! src/share/native/java/net/net_util.c Changeset: a3a2889b1049 Author: dl Date: 2013-07-22 15:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a3a2889b1049 8020976: Ensure consistent insertion for ConcurrentHashMap Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java Changeset: a6cbb9808e4b Author: mduigou Date: 2013-07-22 12:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a6cbb9808e4b 6799426: Adds constructor PriorityQueue(Comparator) Reviewed-by: lancea ! src/share/classes/java/util/PriorityQueue.java Changeset: 7716beb127d4 Author: darcy Date: 2013-07-22 22:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7716beb127d4 8021109: Add serialVersionUID to LambdaConversionException.java Reviewed-by: jrose ! src/share/classes/java/lang/invoke/LambdaConversionException.java Changeset: 6f3b940fe9f8 Author: igerasim Date: 2013-07-23 18:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6f3b940fe9f8 8016838: improvement of RedefineBigClass and RetransformBigClass tests Reviewed-by: dcubed ! test/ProblemList.txt ! test/java/lang/instrument/RedefineBigClass.sh ! test/java/lang/instrument/RedefineBigClassApp.java ! test/java/lang/instrument/RetransformBigClass.sh ! test/java/lang/instrument/RetransformBigClassApp.java Changeset: 8156630c1ed3 Author: mduigou Date: 2013-07-23 13:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8156630c1ed3 8019840: Spec updates for java.util.function Reviewed-by: mduigou, chegar Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/util/function/BiConsumer.java ! src/share/classes/java/util/function/BiFunction.java ! src/share/classes/java/util/function/BiPredicate.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/BooleanSupplier.java ! src/share/classes/java/util/function/Consumer.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleConsumer.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoublePredicate.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleToIntFunction.java ! src/share/classes/java/util/function/DoubleToLongFunction.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntConsumer.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntPredicate.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntToDoubleFunction.java ! src/share/classes/java/util/function/IntToLongFunction.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongConsumer.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongPredicate.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongToDoubleFunction.java ! src/share/classes/java/util/function/LongToIntFunction.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/ObjDoubleConsumer.java ! src/share/classes/java/util/function/ObjIntConsumer.java ! src/share/classes/java/util/function/ObjLongConsumer.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/java/util/function/Supplier.java ! src/share/classes/java/util/function/ToDoubleBiFunction.java ! src/share/classes/java/util/function/ToDoubleFunction.java ! src/share/classes/java/util/function/ToIntBiFunction.java ! src/share/classes/java/util/function/ToIntFunction.java ! src/share/classes/java/util/function/ToLongBiFunction.java ! src/share/classes/java/util/function/ToLongFunction.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/function/package-info.java Changeset: 012996e9259f Author: mduigou Date: 2013-07-23 13:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/012996e9259f Merge Changeset: 187a1f2613c0 Author: sjiang Date: 2013-07-24 15:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/187a1f2613c0 8016221: A unit test should not use a fix port to run a jmx connector Reviewed-by: jbachorik, dfuchs ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanDoubleInvocationTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanInvocationTest.java ! test/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTest.java Changeset: f9224fb49890 Author: juh Date: 2013-07-24 12:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f9224fb49890 8016916: UnstructuredName should support DirectoryString Reviewed-by: mullan ! src/share/classes/sun/security/pkcs/PKCS9Attribute.java ! src/share/classes/sun/security/tools/keytool/Main.java + test/sun/security/pkcs/pkcs9/UnstructuredName.java Changeset: fd1b5adcfdf0 Author: chegar Date: 2013-07-24 22:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fd1b5adcfdf0 8021261: ProblemList.txt updates (7/2013) Reviewed-by: alanb, mcimadamore ! test/ProblemList.txt Changeset: a834ab2c1354 Author: mullan Date: 2013-07-25 10:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a834ab2c1354 8010748: Add PKIXRevocationChecker NO_FALLBACK option and improve SOFT_FAIL option Reviewed-by: vinnie ! src/share/classes/java/security/cert/PKIXRevocationChecker.java ! src/share/classes/sun/security/provider/certpath/OCSP.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/provider/certpath/ReverseState.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/share/classes/sun/security/provider/certpath/SunCertPathBuilder.java ! test/java/security/cert/PKIXRevocationChecker/UnitTest.java Changeset: 22a391706a0b Author: mullan Date: 2013-07-25 11:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/22a391706a0b Merge - make/sun/xawt/ToBin.java - makefiles/sun/awt/X11/ToBin.java - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java - src/share/classes/java/security/acl/package.html - src/share/classes/java/security/cert/package.html - src/share/classes/java/security/interfaces/package.html - src/share/classes/java/security/package.html - src/share/classes/java/security/spec/package.html - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - src/share/classes/sun/misc/Hashing.java - src/share/classes/sun/security/krb5/internal/rcache/CacheTable.java - src/share/classes/sun/security/krb5/internal/rcache/ReplayCache.java ! src/share/classes/sun/security/provider/certpath/RevocationChecker.java - src/solaris/classes/sun/awt/X11/XIconInfo.java - src/solaris/classes/sun/awt/X11/security-icon-bw16.png - src/solaris/classes/sun/awt/X11/security-icon-bw24.png - src/solaris/classes/sun/awt/X11/security-icon-bw32.png - src/solaris/classes/sun/awt/X11/security-icon-bw48.png - src/solaris/classes/sun/awt/X11/security-icon-interim16.png - src/solaris/classes/sun/awt/X11/security-icon-interim24.png - src/solaris/classes/sun/awt/X11/security-icon-interim32.png - src/solaris/classes/sun/awt/X11/security-icon-interim48.png - src/solaris/classes/sun/awt/X11/security-icon-yellow16.png - src/solaris/classes/sun/awt/X11/security-icon-yellow24.png - src/solaris/classes/sun/awt/X11/security-icon-yellow32.png - src/solaris/classes/sun/awt/X11/security-icon-yellow48.png - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.SuSE.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties - src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.properties - test/java/lang/invoke/7196190/MHProxyTest.java - test/java/util/Collections/EmptySortedSet.java - test/java/util/Comparators/BasicTest.java - test/sun/misc/Hashing.java - test/sun/security/krb5/auto/ReplayCache.java Changeset: 21120e3682ef Author: darcy Date: 2013-07-25 09:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/21120e3682ef 8021408: Fix misc doclint issues in java.util and java.io Reviewed-by: dholmes, chegar, psandoz ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/jar/JarEntry.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/stream/StreamSupport.java Changeset: 690dcbaa69b7 Author: chegar Date: 2013-07-25 19:37 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/690dcbaa69b7 8021417: Fix doclint issues in java.util.concurrent Reviewed-by: chegar, lancea Contributed-by: Doug Lea

! src/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/share/classes/java/util/concurrent/ExecutorService.java ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ScheduledExecutorService.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/TimeUnit.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java Changeset: 9cd5159fa870 Author: chegar Date: 2013-07-25 19:45 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9cd5159fa870 8021421: More doclint fixes in java.net Reviewed-by: lancea, darcy ! src/share/classes/java/net/URI.java Changeset: 662ec7782102 Author: joehw Date: 2013-07-25 13:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/662ec7782102 8021148: Regression in SAXParserImpl in 7u40 b34 (NPE) Reviewed-by: chegar, lancea, dfuchs + test/javax/xml/jaxp/parsers/8021148/JAXPSAXParserTest.java + test/javax/xml/jaxp/parsers/8021148/TestBase.java Changeset: 1744a32d3db3 Author: mullan Date: 2013-07-25 20:12 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1744a32d3db3 8012288: XML DSig API allows wrong tag names and extra elements in SignedInfo Reviewed-by: xuelei ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java Changeset: 4100ab44ba4f Author: mullan Date: 2013-07-25 20:30 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4100ab44ba4f Merge Changeset: 86a827321c39 Author: darcy Date: 2013-07-25 20:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/86a827321c39 8021429: Fix lint warnings in java.lang.ref Reviewed-by: lancea, mduigou, alanb ! src/share/classes/java/lang/ref/FinalReference.java ! src/share/classes/java/lang/ref/Finalizer.java ! src/share/classes/java/lang/ref/Reference.java ! src/share/classes/java/lang/ref/ReferenceQueue.java Changeset: 6cc15a808b93 Author: peytoia Date: 2013-07-26 17:22 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6cc15a808b93 8021108: Clean up doclint warnings and errors in java.text package Reviewed-by: darcy, okutsu ! src/share/classes/java/text/Annotation.java ! src/share/classes/java/text/AttributedCharacterIterator.java ! src/share/classes/java/text/Bidi.java ! src/share/classes/java/text/BreakIterator.java ! src/share/classes/java/text/ChoiceFormat.java ! src/share/classes/java/text/CollationElementIterator.java ! src/share/classes/java/text/CollationKey.java ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java ! src/share/classes/java/text/FieldPosition.java ! src/share/classes/java/text/Format.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/Normalizer.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/text/ParseException.java ! src/share/classes/java/text/ParsePosition.java ! src/share/classes/java/text/RuleBasedCollator.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/java/text/StringCharacterIterator.java Changeset: 952476b80fa7 Author: jbachorik Date: 2013-07-26 10:12 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/952476b80fa7 8020875: java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently Reviewed-by: dfuchs, chegar ! test/java/lang/management/ThreadMXBean/ResetPeakThreadCount.java Changeset: 7ae061cfd4be Author: juh Date: 2013-07-26 14:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7ae061cfd4be 8019544: Need to run ProviderTest.java in othervm mode. Reviewed-by: wetmore, xuelei, vinnie Contributed-by: rajan.halade at oracle.com ! test/sun/security/ssl/com/sun/net/ssl/SSLSecurity/ProviderTest.java Changeset: 25575c3c209d Author: lana Date: 2013-07-26 14:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/25575c3c209d Merge Changeset: 9f9ffe6be557 Author: lana Date: 2013-07-26 15:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9f9ffe6be557 Merge Changeset: f056728871f8 Author: mduigou Date: 2013-07-26 17:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f056728871f8 8021601: Add unit test for PriorityQueue(Comparator) constructor Reviewed-by: darcy, alanb ! src/share/classes/java/util/PriorityQueue.java ! test/java/util/PriorityQueue/RemoveContains.java Changeset: d4b2436892c8 Author: bpb Date: 2013-07-26 17:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d4b2436892c8 8014319: Faster division of large integers Summary: Implement Burnickel-Ziegler division algorithm in BigInteger Reviewed-by: bpb, martin Contributed-by: Tim Buktu ! src/share/classes/java/math/BigInteger.java ! src/share/classes/java/math/MutableBigInteger.java ! test/java/math/BigInteger/BigIntegerTest.java Changeset: a1c01457cf6c Author: bpb Date: 2013-07-26 17:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a1c01457cf6c 8020641: Clean up some code style in recent BigInteger contributions Summary: Some minor cleanup to adhere better to Java coding conventions. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/math/BigInteger.java ! src/share/classes/java/math/MutableBigInteger.java ! test/java/math/BigInteger/BigIntegerTest.java Changeset: eb1dc65162e8 Author: darcy Date: 2013-07-27 10:27 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/eb1dc65162e8 8021609: Fix doclint issues in java.nio.charset Reviewed-by: alanb ! src/share/classes/java/nio/charset/Charset-X-Coder.java.template Changeset: 5d4a35823071 Author: mduigou Date: 2013-07-27 12:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5d4a35823071 8021588: Remove explicit othervm execution from jdk/test/Makefile Reviewed-by: alanb ! test/Makefile Changeset: 24bda55fca48 Author: sundar Date: 2013-07-29 21:39 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/24bda55fca48 8021773: print function as defined by jrunscript's init.js script is incompatible with nashorn's definition Reviewed-by: hannesw, lagergren ! src/share/classes/com/sun/tools/script/shell/init.js Changeset: e83fc6d9cf03 Author: psandoz Date: 2013-07-29 19:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e83fc6d9cf03 8020156: TreeMap.values().spliterator() does not report ORDERED 8020009: TreeMap.entrySet().spliterator() reports SORTED + null comparator but the elements are not Comparable Reviewed-by: mduigou ! src/share/classes/java/util/TreeMap.java + test/java/util/Spliterator/SpliteratorCharacteristics.java Changeset: c042fd498f79 Author: ascarpino Date: 2013-07-19 11:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c042fd498f79 8012971: PKCS11Test hiding exception failures Reviewed-by: vinnie, valeriep ! test/ProblemList.txt ! test/sun/security/pkcs11/PKCS11Test.java ! test/sun/security/pkcs11/SecmodTest.java Changeset: e47569593fa0 Author: ascarpino Date: 2013-07-29 13:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e47569593fa0 8020424: The NSS version should be detected before running crypto tests Reviewed-by: valeriep ! test/ProblemList.txt ! test/sun/security/pkcs11/KeyStore/SecretKeysBasic.java ! test/sun/security/pkcs11/PKCS11Test.java + test/sun/security/pkcs11/README ! test/sun/security/pkcs11/ec/ReadCertificates.java ! test/sun/security/pkcs11/ec/TestCurves.java ! test/sun/security/pkcs11/ec/TestECDH.java ! test/sun/security/pkcs11/ec/TestECDH2.java ! test/sun/security/pkcs11/ec/TestECDSA.java ! test/sun/security/pkcs11/ec/TestECDSA2.java ! test/sun/security/pkcs11/ec/TestECGenSpec.java ! test/sun/security/pkcs11/ec/TestKeyFactory.java Changeset: 613cc7beba64 Author: xuelei Date: 2013-07-29 19:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/613cc7beba64 8021841: Remove SSLEngineDeadlock.java from problem list Reviewed-by: wetmore ! test/ProblemList.txt Changeset: c76f89695c90 Author: juh Date: 2013-07-30 11:04 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c76f89695c90 8021833: javadoc cleanup in java.net Summary: and converted to {@code }; package.html to package-info.java Reviewed-by: darcy, chegar ! src/share/classes/java/net/Authenticator.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/java/net/ContentHandlerFactory.java ! src/share/classes/java/net/CookieHandler.java ! src/share/classes/java/net/CookieManager.java ! src/share/classes/java/net/CookiePolicy.java ! src/share/classes/java/net/CookieStore.java ! src/share/classes/java/net/DatagramPacket.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/DatagramSocketImpl.java ! src/share/classes/java/net/DatagramSocketImplFactory.java ! src/share/classes/java/net/FileNameMap.java ! src/share/classes/java/net/HttpCookie.java ! src/share/classes/java/net/HttpRetryException.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/IDN.java ! src/share/classes/java/net/Inet4Address.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/InetSocketAddress.java ! src/share/classes/java/net/InterfaceAddress.java ! src/share/classes/java/net/JarURLConnection.java ! src/share/classes/java/net/MalformedURLException.java ! src/share/classes/java/net/MulticastSocket.java ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/PasswordAuthentication.java ! src/share/classes/java/net/PortUnreachableException.java ! src/share/classes/java/net/ProtocolException.java ! src/share/classes/java/net/Proxy.java ! src/share/classes/java/net/ProxySelector.java ! src/share/classes/java/net/ResponseCache.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/SocketException.java ! src/share/classes/java/net/SocketImpl.java ! src/share/classes/java/net/SocketImplFactory.java ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocketOptions.java ! src/share/classes/java/net/SocketOutputStream.java ! src/share/classes/java/net/SocketPermission.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/net/URISyntaxException.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/net/URLConnection.java ! src/share/classes/java/net/URLDecoder.java ! src/share/classes/java/net/URLEncoder.java ! src/share/classes/java/net/URLStreamHandler.java ! src/share/classes/java/net/URLStreamHandlerFactory.java ! src/share/classes/java/net/UnknownHostException.java ! src/share/classes/java/net/UnknownServiceException.java + src/share/classes/java/net/package-info.java - src/share/classes/java/net/package.html Changeset: 8bc1bbd5b659 Author: sherman Date: 2013-07-30 14:43 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8bc1bbd5b659 8021767: test/java/time/tck/java/time/format/TCKFormatStyle.java failing Summary: Correct to use fixed locale, not locale of test environment Reviewed-by: alanb, okutsu Contributed-by: roger.riggs at oracle.com ! test/java/time/tck/java/time/format/TCKFormatStyle.java Changeset: 09a77a1bdbc3 Author: henryjen Date: 2013-07-30 15:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/09a77a1bdbc3 8020977: StringJoiner merges with itself not as expected Reviewed-by: psandoz, chegar, mduigou, smarks ! src/share/classes/java/util/StringJoiner.java ! test/java/util/StringJoiner/MergeTest.java Changeset: 76d88a752a03 Author: psandoz Date: 2013-07-30 11:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/76d88a752a03 8021863: Stream.concat incorrectly calculates unsized state Reviewed-by: chegar ! src/share/classes/java/util/stream/Streams.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatOpTest.java Changeset: d30f357c6050 Author: psandoz Date: 2013-07-30 14:03 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d30f357c6050 8021883: j.u.Random/RandomStream.java test needs more robust timeout duration Reviewed-by: chegar ! test/java/util/Random/RandomStreamTest.java Changeset: 5561b34f6d4c Author: bpb Date: 2013-07-30 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5561b34f6d4c 8020539: Clean up doclint problems in java.util package, part 2 Summary: Clean up doclint errors and warnings in classes in java.util Reviewed-by: darcy, chegar Contributed-by: Brian Burkhalter ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Optional.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/StringJoiner.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/java/util/UUID.java ! src/share/classes/java/util/Vector.java Changeset: 4bd51f6268f4 Author: rbackman Date: 2013-07-24 10:57 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4bd51f6268f4 8006324: [TEST_BUG] sun/invoke/util/ValueConversionsTest.java should be modified Reviewed-by: kvn, twisti ! test/sun/invoke/util/ValueConversionsTest.java Changeset: 0741b19835b0 Author: lana Date: 2013-07-31 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0741b19835b0 Merge - src/share/classes/java/net/package.html Changeset: 8ed8e2b4b90e Author: lana Date: 2013-08-06 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8ed8e2b4b90e Merge Changeset: e057cddf0d6c Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e057cddf0d6c Added tag jdk8-b102 for changeset 8ed8e2b4b90e ! .hgtags From john.coomes at oracle.com Thu Aug 8 10:58:47 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 08 Aug 2013 17:58:47 +0000 Subject: hg: hsx/hotspot-main/nashorn: 29 new changesets Message-ID: <20130808175914.3144B486F7@hg.openjdk.java.net> Changeset: e1d19f9fd5a9 Author: jlaskey Date: 2013-07-16 17:40 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e1d19f9fd5a9 8017585: Exclude two failing tests from Nashorn CC run Reviewed-by: jlaskey, sundar, attila Contributed-by: konstantin.shefov at oracle.com + exclude/exclude_list.txt + exclude/exclude_list_cc.txt ! make/build.xml Changeset: 71cfe4e66bcb Author: jlaskey Date: 2013-07-17 11:53 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/71cfe4e66bcb 8020596: Initialization of white space strings in scanner should be done with \u strings Reviewed-by: attila, hannesw Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/parser/Lexer.java Changeset: 3d6f6b8d8bc8 Author: hannesw Date: 2013-07-17 18:20 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3d6f6b8d8bc8 8020356: ClassCastException Undefined->Scope on spiltter class generated for a large switch statement Reviewed-by: jlaskey, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/Label.java ! src/jdk/nashorn/internal/codegen/Splitter.java ! src/jdk/nashorn/internal/codegen/WeighNodes.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/LexicalContext.java + test/script/basic/JDK-8020356.js + test/script/basic/JDK-8020356.js.EXPECTED Changeset: e3307f1a30e5 Author: sundar Date: 2013-07-18 18:08 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e3307f1a30e5 8020731: Revisit checkPermission calls in Context class Reviewed-by: attila, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/NativeJavaPackage.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java - src/jdk/nashorn/internal/runtime/linker/JavaAdapterGeneratorBase.java Changeset: 624f8be5c3fe Author: attila Date: 2013-07-18 16:22 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/624f8be5c3fe 8020809: Java adapter should not allow overriding of caller sensitive methods Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java + test/script/trusted/JDK-8020809.js + test/script/trusted/JDK-8020809.js.EXPECTED Changeset: 4b06441b7624 Author: attila Date: 2013-07-18 16:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/4b06441b7624 8020820: Limit access to static members of reflective classes Reviewed-by: jlaskey, sundar ! make/build.xml ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! test/script/basic/JDK-8010946-2.js ! test/script/basic/JDK-8010946-2.js.EXPECTED ! test/script/basic/NASHORN-473.js + test/script/basic/classloader.js + test/script/basic/classloader.js.EXPECTED ! test/script/basic/javaarray.js ! test/script/sandbox/classloader.js.EXPECTED ! test/script/sandbox/reflection.js ! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java Changeset: 0cfa27ed82fe Author: sundar Date: 2013-07-23 18:17 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0cfa27ed82fe 8021122: Not all callables are handled for toString and other function valued properties Reviewed-by: attila, hannesw, jlaskey ! src/jdk/nashorn/internal/ir/debug/ASTWriter.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/arrays/IteratorAction.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java + test/script/basic/JDK-8021122.js + test/script/basic/JDK-8021122.js.EXPECTED Changeset: e86b297d26aa Author: jlaskey Date: 2013-07-23 12:00 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e86b297d26aa 8021130: Comments need to be tokens Reviewed-by: lagergren, attila Contributed-by: james.laskey at oracle.com ! src/jdk/nashorn/internal/parser/AbstractParser.java ! src/jdk/nashorn/internal/parser/Lexer.java ! src/jdk/nashorn/internal/parser/TokenType.java Changeset: ccbea9172aa5 Author: sundar Date: 2013-07-23 21:45 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ccbea9172aa5 8021164: REGRESSION: test262 failures after JDK-8021122 Reviewed-by: jlaskey, hannesw ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java Changeset: 4cb1780bc385 Author: sundar Date: 2013-07-23 21:51 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/4cb1780bc385 Merge - src/jdk/nashorn/internal/runtime/linker/JavaAdapterGeneratorBase.java Changeset: 8b97fe2b7c98 Author: attila Date: 2013-07-23 18:28 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8b97fe2b7c98 8021129: Use public lookup again Reviewed-by: lagergren, sundar ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java - src/jdk/internal/dynalink/beans/SafeUnreflector.java - src/jdk/internal/dynalink/beans/SafeUnreflectorImpl.java - src/jdk/internal/dynalink/beans/SandboxClassLoader.java - src/jdk/internal/dynalink/beans/sandbox/Unreflector.java + test/script/trusted/JDK-8021129.js + test/script/trusted/JDK-8021129.js.EXPECTED + test/src/jdk/nashorn/internal/test/models/InternalRunnable.java + test/src/jdk/nashorn/internal/test/models/RestrictedRunnable.java + test/src/jdk/nashorn/test/models/InternalRunnableSuperclass.java Changeset: a58a07a00122 Author: attila Date: 2013-07-24 11:13 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a58a07a00122 8021189: Prevent access to constructors of restricted classes Reviewed-by: lagergren, sundar ! src/jdk/internal/dynalink/beans/AbstractJavaLinker.java ! src/jdk/internal/dynalink/beans/FacetIntrospector.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java ! test/script/trusted/JDK-8006529.js ! test/script/trusted/JDK-8021129.js + test/script/trusted/JDK-8021189.js + test/script/trusted/JDK-8021189.js.EXPECTED Changeset: e4efb3ce97b2 Author: attila Date: 2013-07-24 12:48 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e4efb3ce97b2 8021246: Fix regression for 8021189 Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! test/script/trusted/JDK-8006529.js Changeset: 2a25917777f7 Author: hannesw Date: 2013-07-24 13:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/2a25917777f7 8020718: RETURN symbol has wrong type in split functions Reviewed-by: lagergren, attila ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FinalizeTypes.java ! src/jdk/nashorn/internal/codegen/MethodEmitter.java ! src/jdk/nashorn/internal/codegen/SplitMethodEmitter.java ! src/jdk/nashorn/internal/ir/Block.java ! src/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/Symbol.java Changeset: 573cc6eb66ae Author: jlaskey Date: 2013-07-24 08:25 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/573cc6eb66ae Merge - src/jdk/internal/dynalink/beans/SafeUnreflector.java - src/jdk/internal/dynalink/beans/SafeUnreflectorImpl.java - src/jdk/internal/dynalink/beans/SandboxClassLoader.java - src/jdk/internal/dynalink/beans/sandbox/Unreflector.java Changeset: dc54df348a58 Author: sundar Date: 2013-07-24 20:28 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/dc54df348a58 8021262: Make nashorn access checks consistent with underlying dynalink Reviewed-by: jlaskey, lagergren, attila ! make/code_coverage.xml ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/PropertyMap.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java ! src/jdk/nashorn/internal/runtime/Source.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/LinkerCallSite.java ! src/jdk/nashorn/internal/runtime/linker/NashornBottomLinker.java ! src/jdk/nashorn/internal/runtime/linker/NashornStaticClassLinker.java ! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java ! test/script/sandbox/nashorninternals.js ! test/script/trusted/JDK-8006529.js ! test/script/trusted/JDK-8021129.js ! test/script/trusted/JDK-8021189.js ! test/script/trusted/JDK-8021189.js.EXPECTED ! test/src/jdk/nashorn/test/models/InternalRunnableSuperclass.java Changeset: d203d68f6624 Author: sundar Date: 2013-07-24 21:01 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d203d68f6624 8021294: --verify-code option results in AnalyzerException Reviewed-by: hannesw, jlaskey ! src/jdk/nashorn/internal/runtime/Context.java Changeset: 5c035c4ccc61 Author: sundar Date: 2013-07-25 14:05 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5c035c4ccc61 8021252: invokeMethod throws NoSuchMethodException when script object is from different script context Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: f74faac51bfb Author: hannesw Date: 2013-07-25 11:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f74faac51bfb 8021244: Inconsistent stackmap with splitter threshold set very low Reviewed-by: sundar, lagergren ! src/jdk/nashorn/internal/codegen/Lower.java ! src/jdk/nashorn/internal/ir/Block.java Changeset: f22ca0f9b6ee Author: sundar Date: 2013-07-25 20:10 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f22ca0f9b6ee 8021361: ClassCastException:.ScriptObjectMirror -> ScriptObject when getInterface called on object from different ScriptContext Reviewed-by: jlaskey, attila ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java + src/jdk/nashorn/api/scripting/resources/Messages.properties ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: d55856f82352 Author: lana Date: 2013-07-26 14:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/d55856f82352 Merge Changeset: f6588f168d79 Author: hannesw Date: 2013-07-26 13:50 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f6588f168d79 8020719: Run tests with reduced splitter threshold Reviewed-by: lagergren, sundar, jlaskey ! make/build.xml ! make/project.properties + test/script/basic/NASHORN-592-dual.js + test/script/basic/NASHORN-592-dual.js.EXPECTED + test/script/basic/compile-octane-splitter.js + test/script/basic/compile-octane-splitter.js.EXPECTED + test/script/basic/splitter.js + test/script/basic/splitter.js.EXPECTED - test/script/representations/NASHORN-592a.js ! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/TestConfig.java ! test/src/jdk/nashorn/internal/test/framework/TestFinder.java Changeset: 17a947418e65 Author: jlaskey Date: 2013-07-26 09:17 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/17a947418e65 8021321: Two runsunspider tests fail after updating sunspider to 1.0 Reviewed-by: jlaskey, sundar Contributed-by: michael.horowitz at oracle.com ! test/script/basic/runsunspider.js Changeset: fbd21b00197b Author: sundar Date: 2013-07-26 20:10 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/fbd21b00197b 8021571: @fork tests should use VM options passed from project.properties Reviewed-by: lagergren, hannesw, jlaskey ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ClassGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/ConstructorGenerator.java ! buildtools/nasgen/src/jdk/nashorn/internal/tools/nasgen/PrototypeGenerator.java ! make/project.properties ! src/jdk/nashorn/internal/objects/BoundScriptFunctionImpl.java ! src/jdk/nashorn/internal/objects/PrototypeObject.java ! src/jdk/nashorn/internal/runtime/AccessorProperty.java ! src/jdk/nashorn/internal/runtime/FinalScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/Property.java ! src/jdk/nashorn/internal/runtime/PropertyListenerManager.java ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/WithObject.java ! src/jdk/nashorn/internal/runtime/linker/AdaptationException.java ! src/jdk/nashorn/internal/runtime/linker/AdaptationResult.java ! src/jdk/nashorn/internal/runtime/linker/InvokeByName.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterServices.java ! src/jdk/nashorn/internal/runtime/linker/JavaArgumentConverters.java ! src/jdk/nashorn/internal/runtime/linker/NashornCallSiteDescriptor.java ! src/jdk/nashorn/internal/runtime/linker/NashornLinker.java ! src/jdk/nashorn/internal/runtime/linker/PrimitiveLookup.java ! src/jdk/nashorn/internal/runtime/options/KeyValueOption.java ! src/jdk/nashorn/internal/runtime/options/OptionTemplate.java ! test/src/jdk/nashorn/internal/test/framework/AbstractScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/ScriptRunnable.java ! test/src/jdk/nashorn/internal/test/framework/TestConfig.java Changeset: 5fc6b7f11289 Author: sundar Date: 2013-07-29 10:28 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/5fc6b7f11289 Merge - test/script/representations/NASHORN-592a.js Changeset: 0532397d0732 Author: sundar Date: 2013-07-29 18:07 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0532397d0732 8012792: print function defined in engine.js does not handle multiple arguments Reviewed-by: hannesw ! src/jdk/nashorn/api/scripting/resources/engine.js ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: 7d5d24bdb671 Author: sundar Date: 2013-07-29 21:56 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/7d5d24bdb671 Merge Changeset: e966ff0a3ffe Author: lana Date: 2013-08-06 10:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e966ff0a3ffe Merge Changeset: 795cff5c1b5c Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/795cff5c1b5c Added tag jdk8-b102 for changeset e966ff0a3ffe ! .hgtags From john.coomes at oracle.com Thu Aug 8 10:57:42 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 08 Aug 2013 17:57:42 +0000 Subject: hg: hsx/hotspot-main/langtools: 17 new changesets Message-ID: <20130808175839.AC9EE486F5@hg.openjdk.java.net> Changeset: 80e75aa6a707 Author: jjg Date: 2013-07-17 18:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/80e75aa6a707 8014636: TestLiteralCodeInPre fails on windows Reviewed-by: ksrini ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! test/com/sun/javadoc/testCRLineSeparator/TestCRLineSeparator.java ! test/com/sun/javadoc/testLeadingSpaces/LeadingSpaces.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testLiteralCodeInPre/TestLiteralCodeInPre.java ! test/com/sun/javadoc/testRelativeLinks/TestRelativeLinks.java Changeset: 1e533c1bfb01 Author: jjg Date: 2013-07-17 19:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1e533c1bfb01 8020313: doclint doesn't reset HTML anchors correctly Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/AnchorTest2.java + test/tools/doclint/AnchorTest2.out + test/tools/doclint/AnchorTest2a.java Changeset: 1476d54fdc61 Author: jjg Date: 2013-07-17 19:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/1476d54fdc61 8020664: doclint gives incorrect warnings on normal package statements Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! test/tools/doclint/BadPackageCommentTest.out ! test/tools/doclint/DocLintTester.java + test/tools/doclint/packageTests/bad/Test.java + test/tools/doclint/packageTests/bad/Test.out + test/tools/doclint/packageTests/bad/package-info.java + test/tools/doclint/packageTests/bad/package-info.out + test/tools/doclint/packageTests/good/Test.java + test/tools/doclint/packageTests/good/package-info.java Changeset: 0a9f5cbe37d9 Author: ksrini Date: 2013-07-19 07:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0a9f5cbe37d9 8017216: javac doesn't fill in end position for some errors of type not found 8019421: Javac doesn't fill in end position for some annotation related errors 8019422: Javac doesn't fill in end position for uninitialized variable errors Reviewed-by: jjg, mcimadamore ! 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/Flow.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/EndPosTable.java + test/tools/javac/diags/examples/VarNotIntializedInDefaultConstructor.java + test/tools/javac/positions/TreeEndPosTest.java Changeset: 129751018061 Author: jjg Date: 2013-07-23 16:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/129751018061 8021215: javac gives incorrect doclint warnings on normal package statements Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! test/tools/doclint/packageTests/bad/Test.java + test/tools/doclint/packageTests/bad/Test.javac.out ! test/tools/doclint/packageTests/bad/Test.out ! test/tools/doclint/packageTests/bad/package-info.java + test/tools/doclint/packageTests/bad/package-info.javac.out ! test/tools/doclint/packageTests/bad/package-info.out ! test/tools/doclint/packageTests/good/Test.java ! test/tools/doclint/packageTests/good/package-info.java Changeset: 558fe98d1ac0 Author: emc Date: 2013-07-23 20:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/558fe98d1ac0 8016880: 42 tests in annot102* fail with compile-time errors. Summary: Fixes error in type equality when bounds of type variables have annotations. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/annotations/typeAnnotations/ErasureTest.java Changeset: 2fbe77c38802 Author: jjg Date: 2013-07-24 17:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/2fbe77c38802 8020556: doclint does not check type variables for @throws Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/util/DocTrees.java ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! test/tools/doclint/ReferenceTest.java Changeset: a218f7befd55 Author: jfranck Date: 2013-07-25 11:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a218f7befd55 8007961: javax.lang.model tests for repeating annotations fail in getAnnotationsByType Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java ! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedA1Test.java ! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB1Test.java ! test/tools/javac/processing/model/element/repeatingAnnotations/MixRepeatableAndOfficialContainerInheritedB2Test.java ! test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideATest.java ! test/tools/javac/processing/model/element/repeatingAnnotations/RepeatableOverrideBTest.java + test/tools/javac/processing/model/inheritedByType/EnsureOrder.java Changeset: 3155e77d2676 Author: mcimadamore Date: 2013-07-25 14:47 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3155e77d2676 8020804: javac crashes when speculative attribution infers intersection type with array component Summary: Assertion is causing javac to crash because of lack of support for arrays in intersection types Reviewed-by: jjg ! 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/Infer.java + test/tools/javac/lambda/8020804/T8020804.java Changeset: b02f28bf7f1c Author: mcimadamore Date: 2013-07-25 14:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b02f28bf7f1c 8016081: field initialized with lambda in annotation types doesn't compile Summary: check for annotation attributes should skip over synthetic methods Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/8016081/T8016081.java Changeset: dae52d74c1fc Author: mcimadamore Date: 2013-07-25 14:51 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/dae52d74c1fc 8020843: javac crashes on accessibility check with method reference with typevar receiver Summary: method reference overload check doesn't walk through type-variable receivers Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/ReportAccessFragment.java + test/tools/javac/lambda/8020843/T8020843a.java + test/tools/javac/lambda/8020843/T8020843a.out + test/tools/javac/lambda/8020843/T8020843b.java + test/tools/javac/lambda/8020843/T8020843b.out ! test/tools/javac/lambda/MethodReference28.out Changeset: 37048aa3ac19 Author: lana Date: 2013-07-26 14:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/37048aa3ac19 Merge Changeset: 8c4b2987edac Author: jlahoda Date: 2013-07-28 10:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8c4b2987edac 8020689: Missing LineNumberTable entries in compiled class files Reviewed-by: ksrini, mcimadamore ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/jvm/T8020689.java Changeset: cd9e8cea1b3c Author: jlahoda Date: 2013-07-28 10:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/cd9e8cea1b3c 8021338: Diamond finder may mark a required type argument as unnecessary Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! test/tools/javac/generics/diamond/6939780/T6939780.java Changeset: 7696282873f6 Author: vromero Date: 2013-07-31 10:52 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/7696282873f6 8013179: assertion failure in javac when compiling with -source 1.6 -target 1.6 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/MethodInvokedWithWrongNumberOfArgs.java Changeset: 453a305e1165 Author: lana Date: 2013-08-06 10:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/453a305e1165 Merge Changeset: 6718df4cd616 Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/6718df4cd616 Added tag jdk8-b102 for changeset 453a305e1165 ! .hgtags From roland.westrelin at oracle.com Thu Aug 8 14:03:53 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 08 Aug 2013 14:03:53 -0700 Subject: CFV: New HSX Committer: Niclas Adlertz Message-ID: <8738qj99om.fsf@oracle.com> I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. Niclas is a member of the Hotspot Compiler group. He contributed 15 changesets to HSX project and he is qualified to be committer [1]. See the end of this email for a list of 8 significant changes. Votes are due by Aug. 22, 2013. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Roland Westrelin. [1] http://openjdk.java.net/projects/#project-committer [2] http://openjdk.java.net/census#hsx [3] http://openjdk.java.net/projects#committer-vote http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc From roland.westrelin at oracle.com Thu Aug 8 14:07:47 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 08 Aug 2013 14:07:47 -0700 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <87y58b7uxo.fsf@oracle.com> Vote: yes Roland. From morris.meyer at oracle.com Thu Aug 8 14:13:44 2013 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 08 Aug 2013 14:13:44 -0700 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <52040A08.3030008@oracle.com> Vote: yes From rickard.backman at oracle.com Thu Aug 8 15:06:52 2013 From: rickard.backman at oracle.com (=?iso-8859-1?Q?Rickard_B=E4ckman?=) Date: Fri, 9 Aug 2013 00:06:52 +0200 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <87y58b7uxo.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> <87y58b7uxo.fsf@oracle.com> Message-ID: <5C32FBB3-877B-4BD1-98C1-7E7BB5D29AA8@oracle.com> Vote yes /R On Aug 8, 2013, at 11:07 PM, Roland Westrelin wrote: > > Vote: yes > > Roland. From vladimir.x.ivanov at oracle.com Thu Aug 8 15:07:15 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 08 Aug 2013 15:07:15 -0700 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <52041693.8000708@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 8/8/13 2:03 PM, Roland Westrelin wrote: > > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. > > Niclas is a member of the Hotspot Compiler group. He contributed 15 > changesets to HSX project and he is qualified to be committer [1]. See > the end of this email for a list of 8 significant changes. > > Votes are due by Aug. 22, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc > From vladimir.kozlov at oracle.com Thu Aug 8 15:14:36 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 08 Aug 2013 15:14:36 -0700 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <5204184C.7090403@oracle.com> Vote: yes On 8/8/13 2:03 PM, Roland Westrelin wrote: > > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. > > Niclas is a member of the Hotspot Compiler group. He contributed 15 > changesets to HSX project and he is qualified to be committer [1]. See > the end of this email for a list of 8 significant changes. > > Votes are due by Aug. 22, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc > From tao.mao at oracle.com Thu Aug 8 15:30:15 2013 From: tao.mao at oracle.com (Tao Mao) Date: Thu, 08 Aug 2013 15:30:15 -0700 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <52041BF7.2090203@oracle.com> Vote: yes Best, Tao On 8/8/13 2:03 PM, Roland Westrelin wrote: > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. > > Niclas is a member of the Hotspot Compiler group. He contributed 15 > changesets to HSX project and he is qualified to be committer [1]. See > the end of this email for a list of 8 significant changes. > > Votes are due by Aug. 22, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc From coleen.phillimore at oracle.com Thu Aug 8 15:34:49 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 08 Aug 2013 18:34:49 -0400 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <52041D09.70505@oracle.com> Vote: yes On 08/08/2013 05:03 PM, Roland Westrelin wrote: > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. > > Niclas is a member of the Hotspot Compiler group. He contributed 15 > changesets to HSX project and he is qualified to be committer [1]. See > the end of this email for a list of 8 significant changes. > > Votes are due by Aug. 22, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc From serguei.spitsyn at oracle.com Thu Aug 8 16:06:34 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 08 Aug 2013 16:06:34 -0700 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <5204247A.1010803@oracle.com> Vote: yes Serguei From rednaxelafx at gmail.com Thu Aug 8 17:03:01 2013 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 9 Aug 2013 08:03:01 +0800 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <5204247A.1010803@oracle.com> References: <8738qj99om.fsf@oracle.com> <5204247A.1010803@oracle.com> Message-ID: Vote: yes - Kris (kmo) From christian.tornqvist at oracle.com Thu Aug 8 17:22:26 2013 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 8 Aug 2013 20:22:26 -0400 Subject: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: Vote: yes -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Roland Westrelin Sent: Thursday, August 8, 2013 5:04 PM To: hotspot-dev developers Subject: CFV: New HSX Committer: Niclas Adlertz I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. Niclas is a member of the Hotspot Compiler group. He contributed 15 changesets to HSX project and he is qualified to be committer [1]. See the end of this email for a list of 8 significant changes. Votes are due by Aug. 22, 2013. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Roland Westrelin. [1] http://openjdk.java.net/projects/#project-committer [2] http://openjdk.java.net/census#hsx [3] http://openjdk.java.net/projects#committer-vote http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc From rickard.backman at oracle.com Thu Aug 8 22:57:15 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Fri, 09 Aug 2013 05:57:15 +0000 Subject: hg: hsx/hotspot-main/hotspot: 7 new changesets Message-ID: <20130809055732.1F93B48739@hg.openjdk.java.net> Changeset: 79a5283f4595 Author: iignatyev Date: 2013-07-29 11:54 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/79a5283f4595 8021120: TieredCompilation can be enabled even if TIERED is undefined Reviewed-by: kvn, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: 8d77d02828d9 Author: twisti Date: 2013-07-29 16:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8d77d02828d9 8016474: Crash in sun.reflect.UnsafeObjectFieldAccessorImpl.get Summary: C1's GetUnsafeObject G1 pre-barrier uses the wrong type to read the klass pointer. Reviewed-by: iveresov, kvn ! src/share/vm/c1/c1_LIRGenerator.cpp + test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java Changeset: 446cb5d25d03 Author: anoll Date: 2013-08-01 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/446cb5d25d03 8020531: Test compiler/codecache/CheckUpperLimit.java fails when memory limited Summary: Removed part of the test that required the VM to start up with -XX:ReservedCodeCacheSize=2048m Reviewed-by: kvn, rbackman ! test/compiler/codecache/CheckUpperLimit.java Changeset: 6e04c193845f Author: anoll Date: 2013-08-02 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6e04c193845f 8021301: better event messages Summary: made event messages better readable Reviewed-by: kvn, rbackman ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/utilities/exceptions.cpp Changeset: 5e0b3d7df485 Author: rbackman Date: 2013-08-05 17:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5e0b3d7df485 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 71526a36ebb4 Author: twisti Date: 2013-08-05 15:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/71526a36ebb4 8022029: GetUnsafeObjectG1PreBarrier fails on 32-bit with: Unrecognized VM option 'ObjectAlignmentInBytes=32' Reviewed-by: kvn ! test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java Changeset: dadf62510ae4 Author: rbackman Date: 2013-08-08 23:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/dadf62510ae4 Merge From stefan.karlsson at oracle.com Fri Aug 9 00:04:50 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 09 Aug 2013 09:04:50 +0200 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <52049492.6020700@oracle.com> Vote: yes On 08/08/2013 11:03 PM, Roland Westrelin wrote: > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. > > Niclas is a member of the Hotspot Compiler group. He contributed 15 > changesets to HSX project and he is qualified to be committer [1]. See > the end of this email for a list of 8 significant changes. > > Votes are due by Aug. 22, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc From thomas.schatzl at oracle.com Fri Aug 9 00:04:38 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 09 Aug 2013 09:04:38 +0200 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <1376031878.2686.0.camel@cirrus> Vote: yes On Thu, 2013-08-08 at 14:03 -0700, Roland Westrelin wrote: > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. > > Niclas is a member of the Hotspot Compiler group. He contributed 15 > changesets to HSX project and he is qualified to be committer [1]. See > the end of this email for a list of 8 significant changes. > > Votes are due by Aug. 22, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc From erik.helin at oracle.com Fri Aug 9 02:27:38 2013 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 9 Aug 2013 11:27:38 +0200 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <20130809092738.GA5453@ehelin-thinkpad> Vote: yes Thanks, Erik On 2013-08-08, Roland Westrelin wrote: > > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. > > Niclas is a member of the Hotspot Compiler group. He contributed 15 > changesets to HSX project and he is qualified to be committer [1]. See > the end of this email for a list of 8 significant changes. > > Votes are due by Aug. 22, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc From harold.seigel at oracle.com Fri Aug 9 04:36:17 2013 From: harold.seigel at oracle.com (Harold Seigel) Date: Fri, 9 Aug 2013 04:36:17 -0700 (PDT) Subject: CFV: New HSX Committer: Niclas Adlertz Message-ID: <66ea130a-a61c-4761-819a-0ee118352561@default> Vote: yes ----- Original Message ----- From: roland.westrelin at oracle.com To: hotspot-dev at openjdk.java.net Sent: Thursday, August 8, 2013 5:05:39 PM GMT -05:00 US/Canada Eastern Subject: CFV: New HSX Committer: Niclas Adlertz I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. Niclas is a member of the Hotspot Compiler group. He contributed 15 changesets to HSX project and he is qualified to be committer [1]. See the end of this email for a list of 8 significant changes. Votes are due by Aug. 22, 2013. Only current HSX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Roland Westrelin. [1] http://openjdk.java.net/projects/#project-committer [2] http://openjdk.java.net/census#hsx [3] http://openjdk.java.net/projects#committer-vote http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc From alejandro.murillo at oracle.com Fri Aug 9 05:43:29 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 09 Aug 2013 12:43:29 +0000 Subject: hg: hsx/hsx25/hotspot: 25 new changesets Message-ID: <20130809124457.26ABC48747@hg.openjdk.java.net> Changeset: b9a927798f12 Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b9a927798f12 Added tag jdk8-b102 for changeset c4697c1c4484 ! .hgtags Changeset: 79ce055063e9 Author: amurillo Date: 2013-08-02 03:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/79ce055063e9 8022124: new hotspot build - hs25-b45 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 9bd314787fad Author: mseledtsov Date: 2013-08-01 22:15 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9bd314787fad 8020614: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output Summary: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output Reviewed-by: kvn, ctornqvi, dholmes + test/testlibrary/OutputAnalyzerReportingTest.java ! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java ! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java Changeset: c01913206da5 Author: ctornqvi Date: 2013-08-01 22:20 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c01913206da5 8014294: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle Summary: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle Reviewed-by: coleenp, sspitsyn ! src/share/vm/services/management.cpp Changeset: 81e0f17ade64 Author: ctornqvi Date: 2013-08-01 22:25 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/81e0f17ade64 8009407: runtime/8000968/Test8000968.sh has incorrect check for proper config Summary: runtime/8000968/Test8000968.sh has incorrect check for proper config Reviewed-by: coleenp, mseledtsov, sspitsyn, hseigel - test/runtime/8000968/Test8000968.sh + test/runtime/CompressedOops/CompressedKlassPointerAndOops.java Changeset: 32e3bada0978 Author: kevinw Date: 2013-08-02 12:26 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/32e3bada0978 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() Reviewed-by: mgerdin, fparain, dcubed ! src/share/vm/services/gcNotifier.cpp Changeset: dee4c330acd4 Author: dcubed Date: 2013-08-02 08:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dee4c330acd4 Merge - test/runtime/8000968/Test8000968.sh Changeset: fa57c8104b76 Author: ctornqvi Date: 2013-08-02 18:12 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/fa57c8104b76 8009585: test/runtime/7196045 times out Summary: test/runtime/7196045 times out Reviewed-by: dholmes, mseledtsov - test/runtime/7196045/Test7196045.java + test/runtime/InternalApi/ThreadCpuTimesDeadlock.java Changeset: 0f209afdfcf8 Author: ctornqvi Date: 2013-08-02 18:26 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0f209afdfcf8 Merge Changeset: d02de8cac823 Author: ctornqvi Date: 2013-08-02 22:34 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d02de8cac823 Merge - test/runtime/7196045/Test7196045.java Changeset: e0379d5ba5d2 Author: kevinw Date: 2013-08-05 10:27 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e0379d5ba5d2 8021444: SA: ClassDump.run() should not ignore existing ClassFilter. Reviewed-by: minqi, poonam ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java Changeset: b67604b59546 Author: hseigel Date: 2013-08-04 16:30 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b67604b59546 7073961: [TESTBUG] closed/runtime/4845371/DBB.java failed on solaris 10 X65 Summary: Added a x86 64-bit Solaris shared library and rewrote test in Java Reviewed-by: dholmes, ctornqvi ! test/testlibrary/com/oracle/java/testlibrary/Platform.java Changeset: 9064e3a19525 Author: hseigel Date: 2013-08-05 08:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9064e3a19525 Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 22a5aff0df0b Author: dsamersoff Date: 2013-08-06 14:28 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/22a5aff0df0b 8019396: SA-JDI OSThread class initialization throws an exception Summary: Method sun.jvm.hotspot.runtime.OSThread.initialize throws a sun.jvm.hotspot.types.WrongTypeException Reviewed-by: dholmes, mgerdin ! agent/src/share/classes/sun/jvm/hotspot/jdi/JVMTIThreadState.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java Changeset: cd25d3be91c5 Author: vladidan Date: 2013-08-06 20:01 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cd25d3be91c5 8012144: multiple SIGSEGVs fails on staxf Summary: Forward port of 7u change to add additional fence() on RMO platforms, with a load_acquire on all platforms Reviewed-by: dholmes, kvn ! src/share/vm/utilities/taskqueue.hpp Changeset: f5bed20f2492 Author: dholmes Date: 2013-08-08 08:29 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f5bed20f2492 Merge Changeset: 79a5283f4595 Author: iignatyev Date: 2013-07-29 11:54 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/79a5283f4595 8021120: TieredCompilation can be enabled even if TIERED is undefined Reviewed-by: kvn, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: 8d77d02828d9 Author: twisti Date: 2013-07-29 16:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8d77d02828d9 8016474: Crash in sun.reflect.UnsafeObjectFieldAccessorImpl.get Summary: C1's GetUnsafeObject G1 pre-barrier uses the wrong type to read the klass pointer. Reviewed-by: iveresov, kvn ! src/share/vm/c1/c1_LIRGenerator.cpp + test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java Changeset: 446cb5d25d03 Author: anoll Date: 2013-08-01 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/446cb5d25d03 8020531: Test compiler/codecache/CheckUpperLimit.java fails when memory limited Summary: Removed part of the test that required the VM to start up with -XX:ReservedCodeCacheSize=2048m Reviewed-by: kvn, rbackman ! test/compiler/codecache/CheckUpperLimit.java Changeset: 6e04c193845f Author: anoll Date: 2013-08-02 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6e04c193845f 8021301: better event messages Summary: made event messages better readable Reviewed-by: kvn, rbackman ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/utilities/exceptions.cpp Changeset: 5e0b3d7df485 Author: rbackman Date: 2013-08-05 17:15 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5e0b3d7df485 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 71526a36ebb4 Author: twisti Date: 2013-08-05 15:03 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/71526a36ebb4 8022029: GetUnsafeObjectG1PreBarrier fails on 32-bit with: Unrecognized VM option 'ObjectAlignmentInBytes=32' Reviewed-by: kvn ! test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java Changeset: dadf62510ae4 Author: rbackman Date: 2013-08-08 23:49 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/dadf62510ae4 Merge Changeset: 7f55137d6aa8 Author: amurillo Date: 2013-08-09 01:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7f55137d6aa8 Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 6f9be7f87b96 Author: amurillo Date: 2013-08-09 01:32 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6f9be7f87b96 Added tag hs25-b45 for changeset 7f55137d6aa8 ! .hgtags From alejandro.murillo at oracle.com Fri Aug 9 07:03:57 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 09 Aug 2013 08:03:57 -0600 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <5204F6CD.9040805@oracle.com> vote: yes -- Alejandro From alejandro.murillo at oracle.com Fri Aug 9 08:12:56 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 09 Aug 2013 15:12:56 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130809151312.CFBF448750@hg.openjdk.java.net> Changeset: b9a927798f12 Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b9a927798f12 Added tag jdk8-b102 for changeset c4697c1c4484 ! .hgtags Changeset: 7f55137d6aa8 Author: amurillo Date: 2013-08-09 01:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7f55137d6aa8 Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 6f9be7f87b96 Author: amurillo Date: 2013-08-09 01:32 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6f9be7f87b96 Added tag hs25-b45 for changeset 7f55137d6aa8 ! .hgtags Changeset: 39127bb12d32 Author: amurillo Date: 2013-08-09 01:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/39127bb12d32 8022688: new hotspot build - hs25-b46 Reviewed-by: jcoomes ! make/hotspot_version From adomurad at redhat.com Fri Aug 9 08:16:03 2013 From: adomurad at redhat.com (Adam Domurad) Date: Fri, 09 Aug 2013 11:16:03 -0400 Subject: Segfault seemingly related to loop unswitching optimization Message-ID: <520507B3.5050603@redhat.com> Hello all. There is a bug filed on Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=982801 To quote from the bug report: > To reproduce download the code from https://github.com/rholder/jvm-loop-unswitching-bug, then run "./gradlew build". JVM crashes will occur during the test. > > As noted on the github page, adding -XX:-LoopUnswitching stops the problem occurring. It seems to affect both OpenJDK & Oracle's JDK. Does anyone know of the status of this bug ? Has anything been filed ? Best regards, -Adam From vladimir.kozlov at oracle.com Fri Aug 9 08:47:13 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 09 Aug 2013 08:47:13 -0700 Subject: Segfault seemingly related to loop unswitching optimization In-Reply-To: <520507B3.5050603@redhat.com> References: <520507B3.5050603@redhat.com> Message-ID: <52050F01.8050901@oracle.com> Hi Adam Our related bug is: http://bugs.sun.com/view_bug.do?bug_id=8021898 I am working on the fix, should be done soon. The problem is in Register Allocator. Regards, Vladimir On 8/9/13 8:16 AM, Adam Domurad wrote: > Hello all. There is a bug filed on Red Hat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=982801 > > To quote from the bug report: > >> To reproduce download the code from https://github.com/rholder/jvm-loop-unswitching-bug, then run "./gradlew build". >> JVM crashes will occur during the test. >> >> As noted on the github page, adding -XX:-LoopUnswitching stops the problem occurring. > > It seems to affect both OpenJDK & Oracle's JDK. Does anyone know of the status of this bug ? Has anything been filed ? > > Best regards, > -Adam From adomurad at redhat.com Fri Aug 9 09:02:54 2013 From: adomurad at redhat.com (Adam Domurad) Date: Fri, 09 Aug 2013 12:02:54 -0400 Subject: Segfault seemingly related to loop unswitching optimization In-Reply-To: <52050F01.8050901@oracle.com> References: <520507B3.5050603@redhat.com> <52050F01.8050901@oracle.com> Message-ID: <520512AE.9080704@redhat.com> On 08/09/2013 11:47 AM, Vladimir Kozlov wrote: > Hi Adam > > Our related bug is: > > http://bugs.sun.com/view_bug.do?bug_id=8021898 > > I am working on the fix, should be done soon. The problem is in Register > Allocator. > > Regards, > Vladimir > Thanks for the information! Happy hacking, -Adam From bengt.rutisson at oracle.com Sun Aug 11 11:16:07 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Sun, 11 Aug 2013 20:16:07 +0200 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <5207D4E7.2080100@oracle.com> Vote: yes Bengt On 8/8/13 11:03 PM, Roland Westrelin wrote: > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. > > Niclas is a member of the Hotspot Compiler group. He contributed 15 > changesets to HSX project and he is qualified to be committer [1]. See > the end of this email for a list of 8 significant changes. > > Votes are due by Aug. 22, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc From goetz.lindenmaier at sap.com Mon Aug 12 00:20:13 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 12 Aug 2013 07:20:13 +0000 Subject: Make zero compile after 8016131 and 8016697 In-Reply-To: <51FEAAFC.109@redhat.com> References: <51FEAAFC.109@redhat.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D00DD81@DEWDFEMB12A.global.corp.sap> Hi Omair, Thanks for fixing 8016697 on zero! Best regards, Goetz. -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Omair Majid Sent: Sonntag, 4. August 2013 21:27 To: hotspot-dev at openjdk.java.net Subject: Make zero compile after 8016131 and 8016697 Hi, The following webrev makes zero compile again: http://cr.openjdk.java.net/~omajid/webrevs/zero-build-broken/00/ The changes in the werbrev mirror the changes made in the following changesets: changeset: 4983:e619a2766bcc user: rbackman date: Wed Jun 12 11:17:39 2013 +0200 summary: 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' changeset: 4961:980532a806a5 user: goetz date: Thu Jun 20 15:02:05 2013 +0200 summary: 8016697: Use stubs to implement safefetch I am not sure what the best tree to use is. I made the webrev against hsx/hotspot-rt, but it applies to hsx/hotspot-main without any changes too. Any concerns with the patch? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From staffan.larsen at oracle.com Mon Aug 12 03:51:35 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 12 Aug 2013 12:51:35 +0200 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <134CC604-13DD-424D-87EA-F306332616CD@oracle.com> Vote: yes. /Staffan On 8 aug 2013, at 23:03, Roland Westrelin wrote: > > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. > > Niclas is a member of the Hotspot Compiler group. He contributed 15 > changesets to HSX project and he is qualified to be committer [1]. See > the end of this email for a list of 8 significant changes. > > Votes are due by Aug. 22, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc From peter.allwin at oracle.com Mon Aug 12 05:51:22 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Mon, 12 Aug 2013 14:51:22 +0200 Subject: RFR: 8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__" Message-ID: <3476F401-E6AF-44C3-871E-62F2681DC8D9@oracle.com> Hello! This patch addresses several Nashorn compatibility issues with in sa.js and is a merge of my patch [0] and Kris' (kmo) [1] which were developed separately. The merged change is identical to [1] with except for line 785 where I've added a conversion to JavaScript String to ensure the correct replace method is called. webrev: http://cr.openjdk.java.net/~allwin/8011888/webrev.01/ bug: http://bugs.sun.com/view_bug.do?bug_id=8011888 Thanks! /Peter [0] http://cr.openjdk.java.net/~allwin/8011888/webrev.00/ [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-July/010831.html From rednaxelafx at gmail.com Mon Aug 12 09:03:41 2013 From: rednaxelafx at gmail.com (Krystal Mok) Date: Tue, 13 Aug 2013 00:03:41 +0800 Subject: RFR: 8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__" In-Reply-To: <5208FA82.5090509@oracle.com> References: <3476F401-E6AF-44C3-871E-62F2681DC8D9@oracle.com> <5208FA82.5090509@oracle.com> Message-ID: Hi Peter, Looks good to me. Thank you! I'd like to mention again that the getHandle -> getAddress change has been purposed by Yunda, which I mentioned in [1], too. Best regards, Kris (kmo) On Monday, August 12, 2013, A. Sundararajan wrote: > > Looks good > > -Sundar > > On Monday 12 August 2013 06:21 PM, Peter Allwin wrote: > > Hello! > > This patch addresses several Nashorn compatibility issues with in sa.js > and is a merge of my patch [0] and Kris' (kmo) [1] which were developed > separately. > > The merged change is identical to [1] with except for line 785 where > I've added a conversion to JavaScript String to ensure the correct replace > method is called. > > > webrev: http://cr.openjdk.java.net/~allwin/8011888/webrev.01/ > bug: http://bugs.sun.com/view_bug.do?bug_id=8011888 > > > Thanks! > /Peter > > > [0] http://cr.openjdk.java.net/~allwin/8011888/webrev.00/ > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-July/010831.html > > > From john.r.rose at oracle.com Mon Aug 12 15:30:54 2013 From: john.r.rose at oracle.com (John Rose) Date: Mon, 12 Aug 2013 15:30:54 -0700 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: <51F7F13E.8040104@oracle.com> References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com> <51F70A00.7010505@oracle.com> <51F7317C.5030400@oracle.com> <51F74985.6070905@oracle.com> <51F74AE9.3050603@oracle.com> <51F7F13E.8040104@oracle.com> Message-ID: This fix will be delicate and may have regressions if the exact code shape (of the PopFrame-ed invokestatic call) changes. Note that member_name_arg_or_null assumes that the value in Local#0 is a DMH; there will be asserts thrown if this fails. It also assumes that the member name held by the DMH in fact corresponds to the linker call (linkToStatic, linkToVirtual, etc.) being PopFrame-ed. In fact, the linker call might in some cases be run from another source than "aload0; getfield member". Requiring that this correspondence exist always is a new internal interface that is hard to document and verify; it may also inhibit present or future optimizations. There are other approaches that might be more robust: 1. Do not allow PopFrame to linker calls, since they (by definition) throw away their trailing MemberName argument. 2. Do not make such frames visible to the user. 3. Modify the linker primitives to store a copy of their trailing MemberName argument to a new slot in the interpreter frame and compiled frame. Be sure to populate this new slot on deoptimization. ? John P.S. Sorry about the delay in commenting; I am just digging out from under JVMLS business! On Jul 30, 2013, at 10:00 AM, serguei.spitsyn at oracle.com wrote: > The updated webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.3/ > > Thanks, > Serguei > > On 7/29/13 10:11 PM, David Holmes wrote: >> Hi Serguei, >> >> I'm fine with restoring to what was in the first webrev. >> >> Further trimming of the JVMTI code is something the embedded folk could look at. It may not be worthwhile. >> >> Thanks, >> David >> >> On 30/07/2013 3:05 PM, serguei.spitsyn at oracle.com wrote: >>> On 7/29/13 8:22 PM, David Holmes wrote: >>>> On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote: >>>>> Christian and David, >>>>> >>>>> Thank you for the quick review and comments! >>>>> >>>>> This is a new version of webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2 >>>>> >>>> >>>> Sorry. You need that guard after all - at least you do if you continue >>>> to use it in interpreterRuntime - otherwise member_name_arg_or_null >>>> will not exist: >>>> >>>> __ call_VM(rax, CAST_FROM_FN_PTR(address, >>>> InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi); >>>> >>> You are right, nice catch again. >>> Probably, it was the reason, I did not remove the #if/#endif in the >>> first place. :) >>> >>>> I'm a little surprised that the assembly code does not have that whole >>>> section guarded with INCLUDE_JVMTI - perhaps it should? >>> It should. >>> But it can be non-trivial because of other dependencies like the above. >>> To make it right, both _remove_activation_preserving_args_entry and >>> generate_earlyret_entry_for >>> must be isolated with #if INCLUDE_JVMTI. >>> Then more files have to be involved in this chain of changes: >>> interpreter/templateInterpreter.hpp >>> interpreter/templateInterpreter.hpp >>> memory/universe.hpp >>> memory/universe.cpp >>> code/codeCache.hpp >>> code/codeCache.cpp >>> . . . etc .. >>> >>> Please, note, that the HOTSWAP macro is used in many places as well. >>> I'm not sure we still need it, so that another decision is needed for it. >>> >>> So, it seems that this kind of clean up is going far beyond my fix. >>> My suggestion is to restore the "#if INCLUDE_JVMTI" in 3 >>> platform-dependent files as it was in the webrev v1. >>> I'm a little bit reluctant to open another clean-up bug for this issue >>> but maybe it is needed. >>> Please, let me know if you are comfortable with this solution. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Run this through a JPRT test build for productEmb to check that the >>>> minimal VM builds ok. >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 7/28/13 9:11 PM, David Holmes wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> >>>>>>> Please, review the fix for: >>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >>>>>>> >>>>>>> Open webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 >>>>>>> >>>>>>> >>>>>> >>>>>> In the templateInterpreter code why did you put this guard on your new >>>>>> code (from x86_32 version): >>>>>> >>>>>> 1923 #if INCLUDE_JVMTI >>>>>> >>>>>> when the whole chunk of code this is situated in is specifically for >>>>>> JVMTI support >>>>>> >>>>>> 1824 // >>>>>> 1825 // JVMTI PopFrame support >>>>>> 1826 // >>>>>> >>>>>> ??? >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> Restore the appendix argument of a polymorphic intrinsic call >>>>>>> needed for a invokestatic re-execution after JVMTI PopFrame(). >>>>>>> >>>>>>> Description >>>>>>> When JVMTI's PopFrame removes a frame that was called via a call >>>>>>> site >>>>>>> that >>>>>>> takes an appendix and that call site is reexecuted the appendix is >>>>>>> not on >>>>>>> the stack anymore because it got removed by the adapter. >>>>>>> This fix is to detect such a case and push the appendix on the >>>>>>> stack >>>>>>> again before reexecution. >>>>>>> >>>>>>> >>>>>>> Testing: >>>>>>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, >>>>>>> nsk.jdi.testlist >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>> >>> > From sundararajan.athijegannathan at oracle.com Mon Aug 12 08:08:50 2013 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 12 Aug 2013 20:38:50 +0530 Subject: RFR: 8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__" In-Reply-To: <3476F401-E6AF-44C3-871E-62F2681DC8D9@oracle.com> References: <3476F401-E6AF-44C3-871E-62F2681DC8D9@oracle.com> Message-ID: <5208FA82.5090509@oracle.com> Looks good -Sundar On Monday 12 August 2013 06:21 PM, Peter Allwin wrote: > Hello! > > This patch addresses several Nashorn compatibility issues with in > sa.js and is a merge of my patch [0] and Kris' (kmo) [1] which were > developed separately. > > The merged change is identical to [1] with except for line 785 where > I've added a conversion to JavaScript String to ensure the correct > replace method is called. > > webrev: http://cr.openjdk.java.net/~allwin/8011888/webrev.01/ > > bug: http://bugs.sun.com/view_bug.do?bug_id=8011888 > > > Thanks! > /Peter > > > [0] http://cr.openjdk.java.net/~allwin/8011888/webrev.00/ > > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-July/010831.html > From mikael.gerdin at oracle.com Tue Aug 13 03:24:19 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 13 Aug 2013 12:24:19 +0200 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <520A0953.6080102@oracle.com> Vote: yes /Mikael On 2013-08-08 23:03, Roland Westrelin wrote: > > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. > > Niclas is a member of the Hotspot Compiler group. He contributed 15 > changesets to HSX project and he is qualified to be committer [1]. See > the end of this email for a list of 8 significant changes. > > Votes are due by Aug. 22, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc > From erik.helin at oracle.com Tue Aug 13 07:45:56 2013 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 13 Aug 2013 16:45:56 +0200 Subject: RFR: 8022899: SunStudio compiler can not handle EXCEPTION_MARK and inlining Message-ID: <20130813144556.GC2188@ehelin-thinkpad> Hi all, this change initializes the Thread* in the EXCEPTION_MARK macro in utilities/exception.hpp to NULL to avoid incorrect warnings from the Sun Studio 12u1 compiler. Background: HotSpot's exception handling code make use of the EXCEPTION_MARK macro defined in utilities/exception.hpp: #define EXCEPTION_MARK Thread* THREAD; ExceptionMark __em(THREAD); where THREAD is defined in the same file as: #define THREAD __the_thread__ The constructor for the class ExceptionMark takes a reference to Thread pointer and assigns it: ExceptionMark::ExceptionMark(Thread*& thread) { thread = Thread::current(); // see utilities/exceptions.cpp for the rest } This means that the Thread pointer __the_thread__ from the EXCEPTION_MARK macro will be initialized by the ExceptionMark constructor (since it takes a pointer reference as argument). However, the Sun Studio compiler sometimes gives a warning that the Thread pointer __the_thread__ is uninitialized. The following code is an example: memory/example.cpp: static void print_str(const char* s, TRAPS) { // TRAPS is defined as: tty->print_cr(s); // #define TRAPS Thread* THREAD } // in utilities/exception.hpp static inline void example(const char* s) { EXCEPTION_MARK; print_str(s, THREAD); // line 36 } void run_example() { example("This will not compile"); } memory/example.hpp: void run_example(); memory/universe.cpp: // include "runtime/example.hpp" // add a call to run_example() in universe_post_init Compiling this with Sun Studio 12u1 will (incorrectly) result in the warning: src/share/vm/memory/example.cpp", line 36: Warning: The variable __the_thread__ has not yet been assigned a value. Removing the "inline" keyword from "static inline void example" makes the code compiler without warnings. Solution: Change the EXCEPTION_MARK macro to: #define EXCEPTION_MARK Thread* THREAD = NULL; ExceptionMark __em(THREAD); Webrev: http://cr.openjdk.java.net/~ehelin/8022899/webrev.00/ Testing: - JPRT - Compiling the example described above successfully Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022899 Thanks, Erik From coleen.phillimore at oracle.com Tue Aug 13 10:34:44 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 13 Aug 2013 13:34:44 -0400 Subject: RFR: 8022899: SunStudio compiler can not handle EXCEPTION_MARK and inlining In-Reply-To: <20130813144556.GC2188@ehelin-thinkpad> References: <20130813144556.GC2188@ehelin-thinkpad> Message-ID: <520A6E34.9030706@oracle.com> This change is fine. The side effect of assigning THREAD from EXCEPTION_MARK is something the code uses a lot, so it probably shouldn't be changed. redefining the macro to be: #define EXCEPTION_MARK Thread* THREAD = Thread::current(); ExceptionMark em(THREAD); would enable removing the non-const reference to ExceptionMark constructor but it might draw in thread.inline.hpp dependencies to exceptions.hpp, which would be bad. So I think your change is fine. Coleen On 08/13/2013 10:45 AM, Erik Helin wrote: > Hi all, > > this change initializes the Thread* in the EXCEPTION_MARK macro in > utilities/exception.hpp to NULL to avoid incorrect warnings from the Sun > Studio 12u1 compiler. > > Background: > HotSpot's exception handling code make use of the EXCEPTION_MARK macro > defined in utilities/exception.hpp: > > #define EXCEPTION_MARK Thread* THREAD; ExceptionMark __em(THREAD); > > where THREAD is defined in the same file as: > > #define THREAD __the_thread__ > > The constructor for the class ExceptionMark takes a reference to Thread > pointer and assigns it: > > ExceptionMark::ExceptionMark(Thread*& thread) { > thread = Thread::current(); > // see utilities/exceptions.cpp for the rest > } > > This means that the Thread pointer __the_thread__ from the > EXCEPTION_MARK macro will be initialized by the ExceptionMark > constructor (since it takes a pointer reference as argument). > > However, the Sun Studio compiler sometimes gives a warning that the > Thread pointer __the_thread__ is uninitialized. The following code is an > example: > > memory/example.cpp: > static void print_str(const char* s, TRAPS) { // TRAPS is defined as: > tty->print_cr(s); // #define TRAPS Thread* THREAD > } // in utilities/exception.hpp > > static inline void example(const char* s) { > EXCEPTION_MARK; > > print_str(s, THREAD); // line 36 > } > > void run_example() { > example("This will not compile"); > } > > memory/example.hpp: > void run_example(); > > memory/universe.cpp: > // include "runtime/example.hpp" > // add a call to run_example() in universe_post_init > > Compiling this with Sun Studio 12u1 will (incorrectly) result in the warning: > src/share/vm/memory/example.cpp", line 36: > Warning: The variable __the_thread__ has not yet been assigned a value. > > Removing the "inline" keyword from "static inline void example" makes > the code compiler without warnings. > > Solution: > Change the EXCEPTION_MARK macro to: > > #define EXCEPTION_MARK Thread* THREAD = NULL; ExceptionMark __em(THREAD); > > Webrev: > http://cr.openjdk.java.net/~ehelin/8022899/webrev.00/ > > Testing: > - JPRT > - Compiling the example described above successfully > > Bug: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022899 > > Thanks, > Erik From christian.thalinger at oracle.com Tue Aug 13 11:29:21 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Aug 2013 11:29:21 -0700 Subject: Zero doesn't build on BSD: redefinition of 'entry_frame_call_wrapper' Message-ID: Roman, could you fix this? -- Chris /Users/cthaling/ws/hotspot/src/cpu/zero/vm/frame_zero.inline.hpp:145:32: error: redefinition of 'entry_frame_call_wrapper' inline JavaCallWrapper* frame::entry_frame_call_wrapper() const { ^ /Users/cthaling/ws/hotspot/src/share/vm/runtime/frame.hpp:356:20: note: previous definition is here JavaCallWrapper* entry_frame_call_wrapper() const { return *entry_frame_call_wrapper_addr(); } ^ 1 error generated. From omajid at redhat.com Tue Aug 13 11:59:20 2013 From: omajid at redhat.com (Omair Majid) Date: Tue, 13 Aug 2013 14:59:20 -0400 Subject: Zero doesn't build on BSD: redefinition of 'entry_frame_call_wrapper' In-Reply-To: References: Message-ID: <520A8208.5010406@redhat.com> On 08/13/2013 02:29 PM, Christian Thalinger wrote: > Roman, could you fix this? -- Chris > > /Users/cthaling/ws/hotspot/src/cpu/zero/vm/frame_zero.inline.hpp:145:32: error: redefinition of 'entry_frame_call_wrapper' > inline JavaCallWrapper* frame::entry_frame_call_wrapper() const { > ^ > /Users/cthaling/ws/hotspot/src/share/vm/runtime/frame.hpp:356:20: note: previous definition is here > JavaCallWrapper* entry_frame_call_wrapper() const { return *entry_frame_call_wrapper_addr(); } > ^ > 1 error generated. > Fix is already in hotspot-rt: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c54a3122f9c8 Cheers, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From christian.thalinger at oracle.com Tue Aug 13 12:30:55 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 13 Aug 2013 12:30:55 -0700 Subject: Zero doesn't build on BSD: redefinition of 'entry_frame_call_wrapper' In-Reply-To: <520A8208.5010406@redhat.com> References: <520A8208.5010406@redhat.com> Message-ID: <1DFB44AC-9F8F-4D43-85AD-C29BFA834362@oracle.com> On Aug 13, 2013, at 11:59 AM, Omair Majid wrote: > On 08/13/2013 02:29 PM, Christian Thalinger wrote: >> Roman, could you fix this? -- Chris >> >> /Users/cthaling/ws/hotspot/src/cpu/zero/vm/frame_zero.inline.hpp:145:32: error: redefinition of 'entry_frame_call_wrapper' >> inline JavaCallWrapper* frame::entry_frame_call_wrapper() const { >> ^ >> /Users/cthaling/ws/hotspot/src/share/vm/runtime/frame.hpp:356:20: note: previous definition is here >> JavaCallWrapper* entry_frame_call_wrapper() const { return *entry_frame_call_wrapper_addr(); } >> ^ >> 1 error generated. >> > > Fix is already in hotspot-rt: > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/c54a3122f9c8 Doh. I was almost positive that this was fixed but I didn't see it. Although I reviewed it ;-) Thanks. -- Chris > > Cheers, > Omair > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From dawid.weiss at gmail.com Tue Aug 13 23:27:25 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Wed, 14 Aug 2013 08:27:25 +0200 Subject: G1GC/ JIT compilation bug hunt. Message-ID: Hi everyone, I am a committer to the Lucene/Solr project. We've recently hit what we believe is a JIT/GC bug -- it manifests itself only when G1GC is used, on a 32-bit VM: Using Java: 32bit/jdk1.8.0-ea-b102 -server -XX:+UseG1GC Java: 32bit/jdk1.7.0_25 -server -XX:+UseG1GC Here is the Lucene issue where more information is available: https://issues.apache.org/jira/browse/LUCENE-5168 In the essence, the problem is that the code hits an assertion (in Java) which it should never reach. There used to be a problem with our implementation of readByte which tripped C2, but this was patched by an alternate implementation a while back -- see here, line 97 (inside readVInt): http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/lucene/core/src/java/org/apache/lucene/store/DataInput.java This time it seems to be something else and is *not* easily reproducible on a smaller example (it's not even reproducible on that particular test all the time). Is there anything you can think of that we can do and which would help you in narrowing down what the problem might be? I initially thought to pass -XX:+PrintCompilation -XX:+PrintAssembly but this will result in a huge log as this happens some time in the middle of a test run (and not always). If there's a shorter route I'd be happy to use it. Dawid From mikael.gerdin at oracle.com Tue Aug 13 23:58:55 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 14 Aug 2013 08:58:55 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: Message-ID: <520B2AAF.2090609@oracle.com> Hi Dawid, On 2013-08-14 08:27, Dawid Weiss wrote: > Hi everyone, > > I am a committer to the Lucene/Solr project. We've recently hit what > we believe is a JIT/GC bug -- it manifests itself only when G1GC is > used, on a 32-bit VM: > > Using Java: 32bit/jdk1.8.0-ea-b102 -server -XX:+UseG1GC > Java: 32bit/jdk1.7.0_25 -server -XX:+UseG1GC > > Here is the Lucene issue where more information is available: > https://issues.apache.org/jira/browse/LUCENE-5168 > > In the essence, the problem is that the code hits an assertion (in > Java) which it should never reach. There used to be a problem with our > implementation of readByte which tripped C2, but this was patched by > an alternate implementation a while back -- see here, line 97 (inside > readVInt): > > http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/lucene/core/src/java/org/apache/lucene/store/DataInput.java > > This time it seems to be something else and is *not* easily > reproducible on a smaller example (it's not even reproducible on that > particular test all the time). > > Is there anything you can think of that we can do and which would help > you in narrowing down what the problem might be? I initially thought > to pass -XX:+PrintCompilation -XX:+PrintAssembly but this will result > in a huge log as this happens some time in the middle of a test run > (and not always). If there's a shorter route I'd be happy to use it. If you have a guess about which method is mis-compiled you can try with -XX:CompileCommand="print org/apache/foo::method" This enables +PrintNMethods on a per-method basis. If you suspect several methods you can use CompileCommandFile and create a text file with several "print" commands. You also need to compile the hsdis disassembler library and place it in the jre/lib/i386 directory to get the actual output from +Print{NMethods,Assembly}. /Mikael > > Dawid > From mikael.gerdin at oracle.com Wed Aug 14 00:06:18 2013 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 14 Aug 2013 09:06:18 +0200 Subject: RFR: 8022899: SunStudio compiler can not handle EXCEPTION_MARK and inlining In-Reply-To: <520A6E34.9030706@oracle.com> References: <20130813144556.GC2188@ehelin-thinkpad> <520A6E34.9030706@oracle.com> Message-ID: <520B2C6A.5070500@oracle.com> Erik, I agree with Coleen, I think this change is a good work-around. /Mikael On 2013-08-13 19:34, Coleen Phillimore wrote: > > This change is fine. The side effect of assigning THREAD from > EXCEPTION_MARK is something the code uses a lot, so it probably > shouldn't be changed. > > redefining the macro to be: > > #define EXCEPTION_MARK Thread* THREAD = Thread::current(); > ExceptionMark em(THREAD); > > would enable removing the non-const reference to ExceptionMark > constructor but it might draw in thread.inline.hpp dependencies to > exceptions.hpp, which would be bad. > > So I think your change is fine. > > Coleen > > On 08/13/2013 10:45 AM, Erik Helin wrote: >> Hi all, >> >> this change initializes the Thread* in the EXCEPTION_MARK macro in >> utilities/exception.hpp to NULL to avoid incorrect warnings from the Sun >> Studio 12u1 compiler. >> >> Background: >> HotSpot's exception handling code make use of the EXCEPTION_MARK macro >> defined in utilities/exception.hpp: >> >> #define EXCEPTION_MARK Thread* THREAD; ExceptionMark __em(THREAD); >> >> where THREAD is defined in the same file as: >> >> #define THREAD __the_thread__ >> >> The constructor for the class ExceptionMark takes a reference to Thread >> pointer and assigns it: >> >> ExceptionMark::ExceptionMark(Thread*& thread) { >> thread = Thread::current(); >> // see utilities/exceptions.cpp for the rest >> } >> >> This means that the Thread pointer __the_thread__ from the >> EXCEPTION_MARK macro will be initialized by the ExceptionMark >> constructor (since it takes a pointer reference as argument). >> >> However, the Sun Studio compiler sometimes gives a warning that the >> Thread pointer __the_thread__ is uninitialized. The following code is an >> example: >> >> memory/example.cpp: >> static void print_str(const char* s, TRAPS) { // TRAPS is defined as: >> tty->print_cr(s); // #define TRAPS >> Thread* THREAD >> } // in >> utilities/exception.hpp >> >> static inline void example(const char* s) { >> EXCEPTION_MARK; >> >> print_str(s, THREAD); // line 36 >> } >> >> void run_example() { >> example("This will not compile"); >> } >> >> memory/example.hpp: >> void run_example(); >> >> memory/universe.cpp: >> // include "runtime/example.hpp" >> // add a call to run_example() in universe_post_init >> >> Compiling this with Sun Studio 12u1 will (incorrectly) result in the >> warning: >> src/share/vm/memory/example.cpp", line 36: >> Warning: The variable __the_thread__ has not yet been assigned a value. >> >> Removing the "inline" keyword from "static inline void example" makes >> the code compiler without warnings. >> >> Solution: >> Change the EXCEPTION_MARK macro to: >> >> #define EXCEPTION_MARK Thread* THREAD = NULL; ExceptionMark >> __em(THREAD); >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8022899/webrev.00/ >> >> Testing: >> - JPRT >> - Compiling the example described above successfully >> >> Bug: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022899 >> >> Thanks, >> Erik > From goetz.lindenmaier at sap.com Wed Aug 14 01:08:08 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Aug 2013 08:08:08 +0000 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <57C1A33A-2D35-4745-977A-84C786AA87A6@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> <57C1A33A-2D35-4745-977A-84C786AA87A6@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D011357@DEWDFEMB12A.global.corp.sap> Hi, Sorry for the long delay, I had off some time. For an examle output I forced a SIGSEGV in chaitin. In hs_err you get for STEP 90: new: siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000018 old: siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000018 si_errno is skipped in the new output, as it's 0. STEP 255: new: Signal Handlers: SIGSEGV: [libjvm.so+0xc03f0d], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO SIGBUS: [libjvm.so+0xc03f0d], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO SIGFPE: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO SIGPIPE: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO SIGXFSZ: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO SIGILL: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO SIGUSR1: SIG_DFL, sa_mask[0]=0, sa_flags=none SIGUSR2: [libjvm.so+0xa57167], sa_mask[0]=0, sa_flags=SA_RESTART|SA_SIGINFO SIGHUP: [libjvm.so+0xa593d5], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO SIGINT: [libjvm.so+0xa593d5], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO SIGTERM: [libjvm.so+0xa593d5], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO SIGQUIT: [libjvm.so+0xa593d5], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO old: Signal Handlers: SIGSEGV: [libjvm.so+0xc0450d], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGBUS: [libjvm.so+0xc0450d], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGFPE: [libjvm.so+0xa54cf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGPIPE: [libjvm.so+0xa54cf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGXFSZ: [libjvm.so+0xa54cf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGILL: [libjvm.so+0xa54cf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 SIGUSR2: [libjvm.so+0xa57427], sa_mask[0]=0x00000000, sa_flags=0x10000004 SIGHUP: [libjvm.so+0xa599d7], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGINT: [libjvm.so+0xa599d7], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGTERM: [libjvm.so+0xa599d7], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGQUIT: [libjvm.so+0xa599d7], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 I'll include a link to an old and new hs_err file in the next webrev I'll make. Best regards, Goetz. -----Original Message----- From: Christian Thalinger [mailto:christian.thalinger at oracle.com] Sent: Freitag, 26. Juli 2013 18:21 To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' Subject: Re: RFR(M): 8020775: PPC64 (part 12): posix signal printing Could you paste an example output? -- Chris On Jul 25, 2013, at 4:11 PM, "Lindenmaier, Goetz" wrote: > Hi, > > we'd like to contribute our posix signal printing. > We implemented some routines to print signal and sa_flags information > in the os/posix files, and call them from > os::print_siginfo and print_signal_handler() in the various unix > variant directories. > The output is a bit more verbose than the existing version. > > We contribute this here, as our aix code uses this too. > > Please review this and test it if you think we should add this. > We'd appreciate it. > http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ > > Thanks and best regards, > Goetz. From erik.helin at oracle.com Wed Aug 14 04:49:13 2013 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 14 Aug 2013 13:49:13 +0200 Subject: RFR: 8022899: SunStudio compiler can not handle EXCEPTION_MARK and inlining In-Reply-To: <520B2C6A.5070500@oracle.com> References: <20130813144556.GC2188@ehelin-thinkpad> <520A6E34.9030706@oracle.com> <520B2C6A.5070500@oracle.com> Message-ID: <20130814114913.GB2649@ehelin-thinkpad> Coleen and Mikael, thanks for reviewing! Erik On 2013-08-14, Mikael Gerdin wrote: > Erik, > > I agree with Coleen, I think this change is a good work-around. > > /Mikael > > > On 2013-08-13 19:34, Coleen Phillimore wrote: > > > >This change is fine. The side effect of assigning THREAD from > >EXCEPTION_MARK is something the code uses a lot, so it probably > >shouldn't be changed. > > > >redefining the macro to be: > > > >#define EXCEPTION_MARK Thread* THREAD = Thread::current(); > >ExceptionMark em(THREAD); > > > >would enable removing the non-const reference to ExceptionMark > >constructor but it might draw in thread.inline.hpp dependencies to > >exceptions.hpp, which would be bad. > > > >So I think your change is fine. > > > >Coleen > > > >On 08/13/2013 10:45 AM, Erik Helin wrote: > >>Hi all, > >> > >>this change initializes the Thread* in the EXCEPTION_MARK macro in > >>utilities/exception.hpp to NULL to avoid incorrect warnings from the Sun > >>Studio 12u1 compiler. > >> > >>Background: > >>HotSpot's exception handling code make use of the EXCEPTION_MARK macro > >>defined in utilities/exception.hpp: > >> > >> #define EXCEPTION_MARK Thread* THREAD; ExceptionMark __em(THREAD); > >> > >>where THREAD is defined in the same file as: > >> > >> #define THREAD __the_thread__ > >> > >>The constructor for the class ExceptionMark takes a reference to Thread > >>pointer and assigns it: > >> > >> ExceptionMark::ExceptionMark(Thread*& thread) { > >> thread = Thread::current(); > >> // see utilities/exceptions.cpp for the rest > >> } > >> > >>This means that the Thread pointer __the_thread__ from the > >>EXCEPTION_MARK macro will be initialized by the ExceptionMark > >>constructor (since it takes a pointer reference as argument). > >> > >>However, the Sun Studio compiler sometimes gives a warning that the > >>Thread pointer __the_thread__ is uninitialized. The following code is an > >>example: > >> > >>memory/example.cpp: > >> static void print_str(const char* s, TRAPS) { // TRAPS is defined as: > >> tty->print_cr(s); // #define TRAPS > >>Thread* THREAD > >> } // in > >>utilities/exception.hpp > >> > >> static inline void example(const char* s) { > >> EXCEPTION_MARK; > >> > >> print_str(s, THREAD); // line 36 > >> } > >> > >> void run_example() { > >> example("This will not compile"); > >> } > >> > >>memory/example.hpp: > >> void run_example(); > >> > >>memory/universe.cpp: > >> // include "runtime/example.hpp" > >> // add a call to run_example() in universe_post_init > >> > >>Compiling this with Sun Studio 12u1 will (incorrectly) result in the > >>warning: > >>src/share/vm/memory/example.cpp", line 36: > >>Warning: The variable __the_thread__ has not yet been assigned a value. > >> > >>Removing the "inline" keyword from "static inline void example" makes > >>the code compiler without warnings. > >> > >>Solution: > >>Change the EXCEPTION_MARK macro to: > >> > >> #define EXCEPTION_MARK Thread* THREAD = NULL; ExceptionMark > >>__em(THREAD); > >> > >>Webrev: > >>http://cr.openjdk.java.net/~ehelin/8022899/webrev.00/ > >> > >>Testing: > >>- JPRT > >>- Compiling the example described above successfully > >> > >>Bug: > >>http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022899 > >> > >>Thanks, > >>Erik > > From dawid.weiss at gmail.com Wed Aug 14 05:38:50 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Wed, 14 Aug 2013 14:38:50 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: <520B2AAF.2090609@oracle.com> References: <520B2AAF.2090609@oracle.com> Message-ID: Thanks Mikael. Limiting the assembly output is a good hint, I'll try to reproduce it and see what happens. Dawid On Wed, Aug 14, 2013 at 8:58 AM, Mikael Gerdin wrote: > Hi Dawid, > > > On 2013-08-14 08:27, Dawid Weiss wrote: >> >> Hi everyone, >> >> I am a committer to the Lucene/Solr project. We've recently hit what >> we believe is a JIT/GC bug -- it manifests itself only when G1GC is >> used, on a 32-bit VM: >> >> Using Java: 32bit/jdk1.8.0-ea-b102 -server -XX:+UseG1GC >> Java: 32bit/jdk1.7.0_25 -server -XX:+UseG1GC >> >> Here is the Lucene issue where more information is available: >> https://issues.apache.org/jira/browse/LUCENE-5168 >> >> In the essence, the problem is that the code hits an assertion (in >> Java) which it should never reach. There used to be a problem with our >> implementation of readByte which tripped C2, but this was patched by >> an alternate implementation a while back -- see here, line 97 (inside >> readVInt): >> >> >> http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/lucene/core/src/java/org/apache/lucene/store/DataInput.java >> >> This time it seems to be something else and is *not* easily >> reproducible on a smaller example (it's not even reproducible on that >> particular test all the time). >> >> Is there anything you can think of that we can do and which would help >> you in narrowing down what the problem might be? I initially thought >> to pass -XX:+PrintCompilation -XX:+PrintAssembly but this will result >> in a huge log as this happens some time in the middle of a test run >> (and not always). If there's a shorter route I'd be happy to use it. > > > If you have a guess about which method is mis-compiled you can try with > -XX:CompileCommand="print org/apache/foo::method" > This enables +PrintNMethods on a per-method basis. > > If you suspect several methods you can use CompileCommandFile and create a > text file with several "print" commands. > > You also need to compile the hsdis disassembler library and place it in the > jre/lib/i386 directory to get the actual output from > +Print{NMethods,Assembly}. > > /Mikael > >> >> Dawid >> > From uschindler at apache.org Wed Aug 14 05:48:16 2013 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 14 Aug 2013 14:48:16 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: <520B2AAF.2090609@oracle.com> Message-ID: <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> Hi Dawid, To find the bad optimization, we could also use the same approach like shown in my talks about the bug hunting done at the time of the famous Java 7 Porter Stemmer bug: Most of us (Java coders, not Hotspot developers) don't have a debug version of the JDK installed with those special libraries. You can try to switch off optimization for methods you suspect to have a problem. Once the bug no longer happens, you have the bad code part (see PDF of http://berlinbuzzwords.de/sessions/testing-lucene-and-solr-various-jvms-bugs-bugs-bugs): "-XX:CompileCommand=exclude,your/package/Class,method". After that you can request assembly output for the broken method in a second step. Uwe ----- Uwe Schindler uschindler at apache.org Apache Lucene PMC Chair / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev- > bounces at openjdk.java.net] On Behalf Of Dawid Weiss > Sent: Wednesday, August 14, 2013 2:39 PM > To: Mikael Gerdin > Cc: hotspot-dev > Subject: Re: G1GC/ JIT compilation bug hunt. > > Thanks Mikael. Limiting the assembly output is a good hint, I'll try to > reproduce it and see what happens. > > Dawid > > On Wed, Aug 14, 2013 at 8:58 AM, Mikael Gerdin > wrote: > > Hi Dawid, > > > > > > On 2013-08-14 08:27, Dawid Weiss wrote: > >> > >> Hi everyone, > >> > >> I am a committer to the Lucene/Solr project. We've recently hit what > >> we believe is a JIT/GC bug -- it manifests itself only when G1GC is > >> used, on a 32-bit VM: > >> > >> Using Java: 32bit/jdk1.8.0-ea-b102 -server -XX:+UseG1GC > >> Java: 32bit/jdk1.7.0_25 -server -XX:+UseG1GC > >> > >> Here is the Lucene issue where more information is available: > >> https://issues.apache.org/jira/browse/LUCENE-5168 > >> > >> In the essence, the problem is that the code hits an assertion (in > >> Java) which it should never reach. There used to be a problem with > >> our implementation of readByte which tripped C2, but this was patched > >> by an alternate implementation a while back -- see here, line 97 > >> (inside > >> readVInt): > >> > >> > >> > http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/lucene/ > >> core/src/java/org/apache/lucene/store/DataInput.java > >> > >> This time it seems to be something else and is *not* easily > >> reproducible on a smaller example (it's not even reproducible on that > >> particular test all the time). > >> > >> Is there anything you can think of that we can do and which would > >> help you in narrowing down what the problem might be? I initially > >> thought to pass -XX:+PrintCompilation -XX:+PrintAssembly but this > >> will result in a huge log as this happens some time in the middle of > >> a test run (and not always). If there's a shorter route I'd be happy to use > it. > > > > > > If you have a guess about which method is mis-compiled you can try > > with -XX:CompileCommand="print org/apache/foo::method" > > This enables +PrintNMethods on a per-method basis. > > > > If you suspect several methods you can use CompileCommandFile and > > create a text file with several "print" commands. > > > > You also need to compile the hsdis disassembler library and place it > > in the > > jre/lib/i386 directory to get the actual output from > > +Print{NMethods,Assembly}. > > > > /Mikael > > > >> > >> Dawid > >> > > From dawid.weiss at gmail.com Wed Aug 14 05:54:02 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Wed, 14 Aug 2013 14:54:02 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> Message-ID: I don't have a debug build but I have hsdis so I can dump the assembly ;) Robert mentioned the code passes with -Xint and -Xbatch so it's probably a dynamic optimization of some sort. I'll do some digging later today, thanks for the hint, Uwe. Dawid From goetz.lindenmaier at sap.com Wed Aug 14 06:02:35 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Aug 2013 13:02:35 +0000 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <51F2C9D1.60907@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> <51F2C9D1.60907@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D011426@DEWDFEMB12A.global.corp.sap> Hi, > I think it is good cleanup. Thank you, Goetz. Thanks! Merits go to Thomas Stuefe who initially redesigned this. I added him as contributor. http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig-2/ In general: The 'describe' functions compute the string containing the desired information. The 'print' functions decide how to publish this information. It's just a separation of concern. We even test them separately. We have a row of additional signal printing routines that are not 'short'. We use them to write much more information into the hs_err file. I did not contribute them, as I assume you will not like it if the hs_err file get's bigger. In addition I added support for real time signals, and a workaround for redundant SIGIOT. > Could you align elements/names in tables in get_signal_name() and > get_signal_code_description() to make them aligned with each other and > with #ifdefs? Done, see webrev. It looks better for most of the tables, but not for info[] in get_signal_name. I think it does not help there, I would prefer the layout without all the white space. > It looks like all unixes (including bsd) have NSIG value defined (I > could be wrong). you can use it directly instead of MAX_SIGNAL_NUMBER. There are some good reasons not to use NSIG for this constant, but they are in the code generating more verbose output, which I did not contribute. So I removed it. (E.g., sometimes it's a function and thus can not be used as array size.) > describe_signal_set_short() method is bogus. Why you overwrite buf[0] > with "0" or "1" and the rest of buffer with 0 each time? Should it be > And why you need separate describe_signal_set_short() method? And why > you need *10 for buffer size Oh, you are right, fixed. I had to change this, as we are using fixBufferStream for printing here. We implemented fixBufferStream in ostream.hpp extending outputStream to print to a given, fixed buffer. I didn't want to contribute that because it's used only here in the port. > I would prefer to see the code similar to > describe_sa_flags() with list of signals instead of "01". Yes, it would > be different from current code but it would much more useful to have > signal names. It's the short routine, replacing an int printed in a line. Signal names would be far too long here. I can contribute STEP(225, "(printing signal handlers)" ) if (_verbose) { #ifdef _WIN32 os::print_signal_handlers(st, buf, sizeof(buf)); #else os::Posix::print_current_signal_handlers(st); #endif st->cr(); } which would do what you have in mind here, I think. > In describe_sa_flags(): > size_t remaining = size-1; // leave space for /0 I think this is correct. Below we test accordingly. > In get_signal_code_description(): Add break: Fixed. > Put on different lines: > + out->s_name = out->s_desc = "unknown"; Fixed. > Why not use s_name instead of s_code to match out->s_name? I renamed this a bit, I hope this makes it better. If you think it's useful for OpenJDK, I can contribute the fixBufferStream and the more verbose printing methods. Best regards, Goetz. On 7/25/13 4:11 PM, Lindenmaier, Goetz wrote: > Hi, > > we'd like to contribute our posix signal printing. > We implemented some routines to print signal and sa_flags information > in the os/posix files, and call them from > os::print_siginfo and print_signal_handler() in the various unix > variant directories. > The output is a bit more verbose than the existing version. > > We contribute this here, as our aix code uses this too. > > Please review this and test it if you think we should add this. > We'd appreciate it. > http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ > > Thanks and best regards, > Goetz. > From goetz.lindenmaier at sap.com Wed Aug 14 06:27:27 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Aug 2013 13:27:27 +0000 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <51F5D77B.6040009@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> <51F5D77B.6040009@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D011445@DEWDFEMB12A.global.corp.sap> Hi David, Yes, it's not all pure posix, but it can be handled the same for all unixes with some exceptions. I removed MAX_SIGNAL_NUMBER and could remove two of the APPLE defines. This leaves 5 pure os-dependencies. See also my reply to Vladimirs mail and the webrev there. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Montag, 29. Juli 2013 04:46 To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' Subject: Re: RFR(M): 8020775: PPC64 (part 12): posix signal printing On 26/07/2013 9:11 AM, Lindenmaier, Goetz wrote: > Hi, > > we'd like to contribute our posix signal printing. This really isn't "posix signals" as it combines all the OS specific signal definitions into one chunk of code. + // A number high enough to contain all possible signal numbers. + #define MAX_SIGNAL_NUMBER 70 Why do you need this when you use sigaddset to check validity anyway? What is this "maximum signal number" meant to represent anyway? The maximum signal number on the platform, or the maximum signal number for a signal that the JVM will install a handler for? The runtime team will need to take a good look at this. Personally I'd rather not see all the different OS stuff piled in together. I'd certainly like to see as little duplication as possible, but I'd rather platform specific stuff was dealt with in platform specific files. David ----- > We implemented some routines to print signal and sa_flags information > in the os/posix files, and call them from > os::print_siginfo and print_signal_handler() in the various unix > variant directories. > The output is a bit more verbose than the existing version. > > We contribute this here, as our aix code uses this too. > Please review this and test it if you think we should add this. > We'd appreciate it. > http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ > > Thanks and best regards, > Goetz. > From pbouchard8 at gmail.com Wed Aug 14 09:01:02 2013 From: pbouchard8 at gmail.com (Phil Bouchard) Date: Wed, 14 Aug 2013 12:01:02 -0400 Subject: Deterministic memory manager of constant complexity Message-ID: <520BA9BE.70008@gmail.com> Hello, I am a software engineer who wrote the following: http://finitetheory.com/author.html I would like to propose Java a new deterministic memory manager of constant complexity that will make applications run smoothly and never to lag again. Its documentation is available at: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.html As a practical example, the applications on the Android will run much better. Sincerely yours, Phil Bouchard From christian.thalinger at oracle.com Wed Aug 14 09:33:50 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 14 Aug 2013 09:33:50 -0700 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D011357@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> <57C1A33A-2D35-4745-977A-84C786AA87A6@oracle.com> <4295855A5C1DE049A61835A1887419CC0D011357@DEWDFEMB12A.global.corp.sap> Message-ID: <3B5D036F-ED25-43A9-B751-DE861558C49B@oracle.com> On Aug 14, 2013, at 1:08 AM, "Lindenmaier, Goetz" wrote: > Hi, > > Sorry for the long delay, I had off some time. > > For an examle output I forced a SIGSEGV in chaitin. Looks good. Thanks. -- Chris > > In hs_err you get for STEP 90: > > new: siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000018 > old: siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000018 > > si_errno is skipped in the new output, as it's 0. > > STEP 255: > > new: > Signal Handlers: > SIGSEGV: [libjvm.so+0xc03f0d], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGBUS: [libjvm.so+0xc03f0d], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGFPE: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGPIPE: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGXFSZ: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGILL: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGUSR1: SIG_DFL, sa_mask[0]=0, sa_flags=none > SIGUSR2: [libjvm.so+0xa57167], sa_mask[0]=0, sa_flags=SA_RESTART|SA_SIGINFO > SIGHUP: [libjvm.so+0xa593d5], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGINT: [libjvm.so+0xa593d5], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGTERM: [libjvm.so+0xa593d5], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGQUIT: [libjvm.so+0xa593d5], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > > old: > Signal Handlers: > SIGSEGV: [libjvm.so+0xc0450d], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGBUS: [libjvm.so+0xc0450d], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGFPE: [libjvm.so+0xa54cf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGPIPE: [libjvm.so+0xa54cf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGXFSZ: [libjvm.so+0xa54cf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGILL: [libjvm.so+0xa54cf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 > SIGUSR2: [libjvm.so+0xa57427], sa_mask[0]=0x00000000, sa_flags=0x10000004 > SIGHUP: [libjvm.so+0xa599d7], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGINT: [libjvm.so+0xa599d7], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGTERM: [libjvm.so+0xa599d7], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGQUIT: [libjvm.so+0xa599d7], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > > I'll include a link to an old and new hs_err file in the next webrev I'll make. > > Best regards, > Goetz. > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Freitag, 26. Juli 2013 18:21 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' > Subject: Re: RFR(M): 8020775: PPC64 (part 12): posix signal printing > > Could you paste an example output? > > -- Chris > > On Jul 25, 2013, at 4:11 PM, "Lindenmaier, Goetz" wrote: > >> Hi, >> >> we'd like to contribute our posix signal printing. >> We implemented some routines to print signal and sa_flags information >> in the os/posix files, and call them from >> os::print_siginfo and print_signal_handler() in the various unix >> variant directories. >> The output is a bit more verbose than the existing version. >> >> We contribute this here, as our aix code uses this too. >> >> Please review this and test it if you think we should add this. >> We'd appreciate it. >> http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ >> >> Thanks and best regards, >> Goetz. > From daniel.daugherty at oracle.com Wed Aug 14 16:05:01 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 14 Aug 2013 23:05:01 +0000 Subject: hg: hsx/hotspot-main/hotspot: 13 new changesets Message-ID: <20130814230534.15435488A4@hg.openjdk.java.net> Changeset: ca0165daa6ec Author: sspitsyn Date: 2013-08-06 16:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ca0165daa6ec 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments Summary: Restore the appendix argument after PopFrame() call Reviewed-by: twisti, coleenp Contributed-by: serguei.spitsyn at oracle.com ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: c54a3122f9c8 Author: omajid Date: 2013-08-06 12:28 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c54a3122f9c8 8022188: Make zero compile after 8016131 and 8016697 Reviewed-by: dholmes, twisti ! src/cpu/zero/vm/entryFrame_zero.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp Changeset: 196aa14f9f29 Author: dholmes Date: 2013-08-06 21:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/196aa14f9f29 Merge Changeset: 195ff07bc7f6 Author: dsamersoff Date: 2013-08-07 19:02 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/195ff07bc7f6 8021771: warning stat64 is deprecated - when building on OSX 10.7.5 Summary: stat64 have to be replaced with stat Reviewed-by: dholmes, kmo Contributed-by: rednaxelafx at gmail.com ! src/os/bsd/vm/attachListener_bsd.cpp Changeset: 31f3b1e1c5e5 Author: dcubed Date: 2013-08-08 09:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/31f3b1e1c5e5 8016601: Unable to build hsx24 on Windows using project creator and Visual Studio Summary: ProjectCreator tool is modified to support two new options: '-relativeAltSrcInclude' and '-altRelativeInclude' which prevents IDE linker errors. Also fixed some cmd line build linker warnings. Misc cleanups. Reviewed-by: rdurbin, coleenp ! make/windows/create.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/trace.make ! make/windows/makefiles/vm.make ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java Changeset: c661fa2e5189 Author: iklam Date: 2013-08-08 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c661fa2e5189 8022093: syntax error near "umpiconninfo_t" -- when building on Solaris 10 Summary: Added extra help message in make/solaris/makefiles/dtrace.make Reviewed-by: dholmes, sspitsyn ! make/solaris/makefiles/dtrace.make Changeset: 57ac7245594c Author: minqi Date: 2013-08-08 15:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/57ac7245594c 8019583: [TESTBUG] runtime/7107135 always passes Summary: If java test return none zero, the value will be override by 'if' statement, the exit value will always '0' and pass. Fix by recording the result in a variable. Reviewed-by: coleenp, dholmes, iklam Contributed-by: yumin.qi at oracle.com ! test/runtime/7107135/Test7107135.sh Changeset: 6222a021d582 Author: minqi Date: 2013-08-08 20:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6222a021d582 Merge Changeset: 98aa538fd97e Author: mikael Date: 2013-08-09 09:51 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/98aa538fd97e 8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012 R2 Summary: Add support for recognizing Windows 8.1 and Server 2012 R2 and minor cleanup Reviewed-by: coleenp, dsamersoff ! src/os/windows/vm/os_windows.cpp Changeset: ed7c17e7d45b Author: dcubed Date: 2013-08-09 13:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ed7c17e7d45b Merge Changeset: 7b03590c334b Author: dcubed Date: 2013-08-09 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7b03590c334b Merge Changeset: bd0e82136b03 Author: iklam Date: 2013-08-10 10:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bd0e82136b03 8022740: Visual 2008 IDE build is broken Summary: Fixed project generation code, and added warning to upgrade to VS 2008 SP1. Reviewed-by: dcubed, ccheung ! make/windows/projectfiles/common/Makefile ! src/share/tools/ProjectCreator/FileTreeCreator.java ! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java ! src/share/tools/ProjectCreator/FileTreeCreatorVC7.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java Changeset: 85147f28faba Author: coleenp Date: 2013-08-12 17:24 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/85147f28faba 8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32 Summary: ActiveMethodOopsCache was used to keep track of old versions of some methods that are cached in Universe but is buggy with permgen removal and not needed anymore Reviewed-by: sspitsyn, dcubed, mseledtsov ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! test/runtime/RedefineObject/Agent.java ! test/runtime/RedefineObject/TestRedefineObject.java + test/runtime/RedefineObject/WalkThroughInvoke.java From dawid.weiss at gmail.com Thu Aug 15 02:44:32 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Thu, 15 Aug 2013 11:44:32 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> Message-ID: This just has to have something to do with G1GC, inlining, escape analysis and c2 optimizations (as if there was anything else :). Seems like an update to one of the variables is lost (nextSlice method in ByteSliceReader). This method is inlined heavily; I checked the following, all of which results in no errors. 1) passed "-XX:-Inline" - no errors 2) excluded separately "nextSlice" and the "parent" method from compilation - no errors 3) "-XX:-DoEscapeAnalysis" - preventing escape analysis - no errors 4) added a dummy value flush in ByteSliceReader.nextSlice by modifying: upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK; to foo = upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK; where foo is a static field with no other accesses -- no errors. 5) Changing G1GC to any other GC - no errors. I also dumped the generated assembly for the flush() method. It's huge and, sigh, it's sometimes different even for two runs with identical options; I'm guessing parallel compilation tasks hit different stats? I noticed upto field write gets optimized away for certain loops but the entire logic after all the ideal graph optimizations is not clear from the assembly dump. So it's still an open issue. D. On Wed, Aug 14, 2013 at 2:54 PM, Dawid Weiss wrote: > I don't have a debug build but I have hsdis so I can dump the assembly > ;) Robert mentioned the code passes with -Xint and -Xbatch so it's > probably a dynamic optimization of some sort. I'll do some digging > later today, thanks for the hint, Uwe. > > Dawid From goetz.lindenmaier at sap.com Thu Aug 15 05:10:27 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 15 Aug 2013 12:10:27 +0000 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX Message-ID: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> Hi, I prepared a webrev for 8023033: PPC64 (part 13): basic changes for AIX http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ This contains the basic shared changes needed for the AIX port, as there are - #includes - Fixes to get the code compiling with xlC/on AIX - Basic adaptions as in vm_version.cpp. It also determines the placement and naming of the aix files, which will go to os/aix and os_cpu/aix_ppc, as you can see in http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ Some details about the compilation problems: relocInfo.hpp: xlC wants initialization in inline implementation. vmreg.hpp: BAD is defined in AIX system header sys/param.h. Renamed. allocation.hpp xlC complains: runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" member "StackObj::operator delete(void *)" cannot be accessed. sharedRuntimeTrig.cpp Aix defines hz to be 100, see sys/m_param.h. Renamed. debug.hpp With other include order we get a lot of memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not declared. Please review and test this change. Comments are welcome. Thanks and best regards, Goetz. From vladimir.kozlov at oracle.com Thu Aug 15 08:51:35 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Aug 2013 08:51:35 -0700 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> Message-ID: <520CF907.3040908@oracle.com> Goetz, I only see 2 problems which you did not explain: nmethod.hpp. Why the next change? we don't use C++ exceptions: - void* operator new(size_t size, int nmethod_size); + void* operator new(size_t size, int nmethod_size) throw (); port.hpp. Did AIX has the same definitions for jlong and julong?: +#ifndef _AIX +// These conflict with /usr/include/sys/inttypes.h on aix. typedef jlong int64; // Java long for my 64-bit type typedef julong uint64; // Java long for my 64-bit type +#endif And of cause we need to test these changes with compilers we use. Thanks, Vladimir On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: > Hi, > > I prepared a webrev for > 8023033: PPC64 (part 13): basic changes for AIX > http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ > > This contains the basic shared changes needed for the AIX port, > as there are > - #includes > - Fixes to get the code compiling with xlC/on AIX > - Basic adaptions as in vm_version.cpp. > > It also determines the placement and naming of the aix files, > which will go to os/aix and os_cpu/aix_ppc, as you can see in > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ > > Some details about the compilation problems: > > relocInfo.hpp: > xlC wants initialization in inline implementation. > > vmreg.hpp: > BAD is defined in AIX system header sys/param.h. Renamed. > > allocation.hpp > xlC complains: > runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" member "StackObj::operator delete(void *)" cannot be accessed. > > sharedRuntimeTrig.cpp > Aix defines hz to be 100, see sys/m_param.h. Renamed. > > debug.hpp > With other include order we get a lot of > memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not declared. > > > Please review and test this change. Comments are welcome. > > Thanks and best regards, > Goetz. > From john.coomes at oracle.com Thu Aug 15 10:42:38 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 15 Aug 2013 17:42:38 +0000 Subject: hg: hsx/hotspot-main/corba: 4 new changesets Message-ID: <20130815174245.8675C488E1@hg.openjdk.java.net> Changeset: cc11a0efb4f9 Author: aefimov Date: 2013-08-01 14:59 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/cc11a0efb4f9 8015987: The corba repo contains unneeded .sjava files Reviewed-by: alanb, chegar, coffeys - src/share/classes/com/sun/corba/se/impl/copyobject/JavaInputStream.sjava - src/share/classes/com/sun/corba/se/impl/copyobject/JavaOutputStream.sjava - src/share/classes/com/sun/corba/se/impl/interceptors/ThreadCurrentStack.sjava - src/share/classes/com/sun/corba/se/impl/orbutil/DefineWrapper.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl_save.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLTypesUtil_save.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/transport/BufferConnectionImpl.sjava Changeset: 342a954b68f3 Author: lana Date: 2013-08-06 16:54 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/342a954b68f3 Merge Changeset: 49c4a777fdfd Author: lana Date: 2013-08-13 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/49c4a777fdfd Merge Changeset: d411c60a8c2f Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/d411c60a8c2f Added tag jdk8-b103 for changeset 49c4a777fdfd ! .hgtags From john.coomes at oracle.com Thu Aug 15 10:42:29 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 15 Aug 2013 17:42:29 +0000 Subject: hg: hsx/hotspot-main: Added tag jdk8-b103 for changeset b7e64be81c8a Message-ID: <20130815174229.EF78F488E0@hg.openjdk.java.net> Changeset: ceefd94ef326 Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/ceefd94ef326 Added tag jdk8-b103 for changeset b7e64be81c8a ! .hgtags From john.coomes at oracle.com Thu Aug 15 10:42:53 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 15 Aug 2013 17:42:53 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b103 for changeset b1ceab582fc6 Message-ID: <20130815174304.4D76D488E2@hg.openjdk.java.net> Changeset: a22fe9bd01e6 Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/a22fe9bd01e6 Added tag jdk8-b103 for changeset b1ceab582fc6 ! .hgtags From john.coomes at oracle.com Thu Aug 15 10:43:14 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 15 Aug 2013 17:43:14 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b103 for changeset 6cdc6ed98780 Message-ID: <20130815174323.16EA5488E3@hg.openjdk.java.net> Changeset: 42211ab0ab1c Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/42211ab0ab1c Added tag jdk8-b103 for changeset 6cdc6ed98780 ! .hgtags From rickard.backman at oracle.com Thu Aug 15 10:49:33 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Thu, 15 Aug 2013 17:49:33 +0000 Subject: hg: hsx/hotspot-main/hotspot: 6 new changesets Message-ID: <20130815174952.A91EB488E4@hg.openjdk.java.net> Changeset: d1034bd8cefc Author: adlertz Date: 2013-08-07 17:56 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d1034bd8cefc 8022284: Hide internal data structure in PhaseCFG Summary: Hide private node to block mapping using public interface Reviewed-by: kvn, roland ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ce8969c36762 Author: adlertz Date: 2013-08-07 18:04 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ce8969c36762 8022475: Remove unneeded ad-files Summary: Remove .ad files that are not used Reviewed-by: kvn ! make/bsd/makefiles/adlc.make ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! make/windows/makefiles/adlc.make - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 5394ec69f112 Author: rbackman Date: 2013-08-09 18:05 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5394ec69f112 Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 11237ee74aae Author: iignatyev Date: 2013-08-10 10:01 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/11237ee74aae 8019915: whitebox testClearMethodStateTest fails with tiered on sparc Summary: 'compileonly' directive has beens added to each 'compiler/whitebox' test Reviewed-by: kvn ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/compiler/whitebox/SetForceInlineMethodTest.java Changeset: bcc4f6f54d83 Author: kvn Date: 2013-08-14 10:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bcc4f6f54d83 8022993: Convert MAX_UNROLL constant to LoopMaxUnroll C2 flag Summary: Replace MAX_UNROLL constant with new C2 LoopMaxUnroll flag. Reviewed-by: roland ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/loopTransform.cpp Changeset: 56b94e55267a Author: rbackman Date: 2013-08-15 15:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/56b94e55267a Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad From john.coomes at oracle.com Thu Aug 15 10:45:53 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 15 Aug 2013 17:45:53 +0000 Subject: hg: hsx/hotspot-main/jdk: 64 new changesets Message-ID: <20130815180010.99540488E5@hg.openjdk.java.net> Changeset: 1c6bfb303ffc Author: prr Date: 2013-08-06 13:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1c6bfb303ffc 8022175: Fix doclint warnings in javax.print Reviewed-by: darcy ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/MultiDocPrintJob.java ! src/share/classes/javax/print/PrintService.java ! src/share/classes/javax/print/ServiceUI.java ! src/share/classes/javax/print/ServiceUIFactory.java ! src/share/classes/javax/print/attribute/AttributeSet.java ! src/share/classes/javax/print/attribute/DateTimeSyntax.java ! src/share/classes/javax/print/attribute/DocAttributeSet.java ! src/share/classes/javax/print/attribute/EnumSyntax.java ! src/share/classes/javax/print/attribute/HashAttributeSet.java ! src/share/classes/javax/print/attribute/IntegerSyntax.java ! src/share/classes/javax/print/attribute/PrintJobAttributeSet.java ! src/share/classes/javax/print/attribute/PrintRequestAttributeSet.java ! src/share/classes/javax/print/attribute/PrintServiceAttributeSet.java ! src/share/classes/javax/print/attribute/ResolutionSyntax.java ! src/share/classes/javax/print/attribute/Size2DSyntax.java ! src/share/classes/javax/print/attribute/standard/Chromaticity.java ! src/share/classes/javax/print/attribute/standard/Compression.java ! src/share/classes/javax/print/attribute/standard/Finishings.java ! src/share/classes/javax/print/attribute/standard/JobKOctets.java ! src/share/classes/javax/print/attribute/standard/MediaPrintableArea.java ! src/share/classes/javax/print/attribute/standard/MediaSize.java ! src/share/classes/javax/print/attribute/standard/PresentationDirection.java ! src/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java ! src/share/classes/javax/print/attribute/standard/PrinterResolution.java Changeset: c3b91dc2504a Author: jgodinez Date: 2013-08-06 14:22 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c3b91dc2504a 8021583: test/javax/print/autosense/PrintAutoSenseData.java throwing NPE Reviewed-by: jchen, prr ! src/solaris/classes/sun/print/UnixPrintJob.java ! src/windows/classes/sun/print/Win32PrintJob.java ! test/javax/print/attribute/autosense/PrintAutoSenseData.java + test/javax/print/attribute/autosense/sample.txt Changeset: fe04f40cf469 Author: prr Date: 2013-08-06 17:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fe04f40cf469 8022455: Fix doclint warnings in javax.imageio Reviewed-by: darcy ! src/share/classes/javax/imageio/ImageIO.java ! src/share/classes/javax/imageio/ImageReadParam.java ! src/share/classes/javax/imageio/ImageReader.java ! src/share/classes/javax/imageio/ImageTypeSpecifier.java ! src/share/classes/javax/imageio/ImageWriteParam.java ! src/share/classes/javax/imageio/ImageWriter.java ! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java ! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageReadParam.java ! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageWriteParam.java ! src/share/classes/javax/imageio/spi/ImageReaderSpi.java ! src/share/classes/javax/imageio/spi/ImageWriterSpi.java ! src/share/classes/javax/imageio/spi/ServiceRegistry.java ! src/share/classes/javax/imageio/stream/ImageInputStream.java ! src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java ! src/share/classes/javax/imageio/stream/ImageOutputStream.java Changeset: c827ad8c1101 Author: prr Date: 2013-08-06 17:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c827ad8c1101 8022447: Fix doclint warnings in java.awt.image Reviewed-by: darcy ! src/share/classes/java/awt/image/BufferStrategy.java ! src/share/classes/java/awt/image/BufferedImage.java ! src/share/classes/java/awt/image/ByteLookupTable.java ! src/share/classes/java/awt/image/ColorModel.java ! src/share/classes/java/awt/image/DirectColorModel.java ! src/share/classes/java/awt/image/ImageProducer.java ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/java/awt/image/MemoryImageSource.java ! src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java ! src/share/classes/java/awt/image/PixelGrabber.java ! src/share/classes/java/awt/image/RGBImageFilter.java ! src/share/classes/java/awt/image/ShortLookupTable.java ! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java ! src/share/classes/java/awt/image/WritableRaster.java Changeset: 9314c199003d Author: lana Date: 2013-08-06 22:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9314c199003d Merge - src/share/classes/java/net/package.html Changeset: ab64c138d5bd Author: prr Date: 2013-08-07 18:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ab64c138d5bd 8014883: java.awt.container.add(component comp object constraints) doesn't work as expected on some linux platforms Reviewed-by: jgodinez ! makefiles/CompileNativeLibraries.gmk ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 645a37a3559f Author: leonidr Date: 2013-08-01 01:26 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/645a37a3559f 8021815: Add regression test for JDK-8007267 Reviewed-by: serb + test/com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java Changeset: 495ca130cbde Author: alexsch Date: 2013-08-01 17:09 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/495ca130cbde 7161568: [macosx] api/javax_swing/JTabbedPane/index2.html#varios fails Reviewed-by: malenkov, serb ! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java + test/javax/swing/JTabbedPane/4361477/bug4361477.java + test/javax/swing/JTabbedPane/6495408/bug6495408.java + test/javax/swing/JTabbedPane/7161568/bug7161568.java Changeset: e76b1568d002 Author: leonidr Date: 2013-08-02 15:42 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e76b1568d002 8021381: JavaFX scene included in Swing JDialog not starting from Web Start Reviewed-by: art, dcherepanov ! src/share/classes/sun/awt/AppContext.java Changeset: 07abddc1d7f2 Author: leonidr Date: 2013-08-06 17:07 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/07abddc1d7f2 8022247: java/awt/EventDispatchThread/LoopRobustness/LoopRobustness throws NPE Reviewed-by: art ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java Changeset: 27d1bdf2f7d9 Author: mcherkas Date: 2013-08-06 17:29 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/27d1bdf2f7d9 8016833: Underlines and strikethrough not rendering correctly Reviewed-by: alexsch, serb Contributed-by: anton.nashatyrev at oracle.com ! src/share/classes/javax/swing/text/GlyphView.java + test/javax/swing/text/StyledEditorKit/8016833/bug8016833.java Changeset: f8ed88f5ed87 Author: alexsch Date: 2013-08-07 18:32 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f8ed88f5ed87 8022532: [parfait] Potential memory leak in gtk2_interface.c Reviewed-by: art, serb ! src/solaris/native/sun/awt/gtk2_interface.c Changeset: 7706a622d35f Author: alexsch Date: 2013-08-07 18:58 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7706a622d35f 8013849: Awt assert on Hashtable.cpp:124 Reviewed-by: serb ! src/windows/native/sun/windows/awt_Component.cpp + test/java/awt/event/KeyEvent/DeadKey/DeadKeySystemAssertionDialog.java Changeset: f70492d969e7 Author: serb Date: 2013-08-07 19:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f70492d969e7 7124339: [macosx] setIconImage is not endlessly tolerant to the broken image-arguments Reviewed-by: alexsch, leonidr ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 540192229a69 Author: art Date: 2013-08-07 21:31 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/540192229a69 6551589: ContainerListener Documentation may be incorrect Reviewed-by: serb ! src/share/classes/java/awt/event/ContainerListener.java Changeset: 9bcc3f2af980 Author: lana Date: 2013-08-07 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9bcc3f2af980 Merge - src/share/classes/java/net/package.html Changeset: e193c4ad940a Author: lana Date: 2013-08-07 19:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e193c4ad940a Merge Changeset: c49b538ef054 Author: chegar Date: 2013-08-01 12:38 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c49b538ef054 8022061: More ProblemList.txt updates (7/2013) Reviewed-by: alanb, psandoz ! test/ProblemList.txt Changeset: 36f4cf8872f3 Author: igerasim Date: 2013-07-30 21:11 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/36f4cf8872f3 7192942: (coll) Inefficient calculation of power of two in HashMap Reviewed-by: mduigou ! src/share/classes/java/util/HashMap.java Changeset: 54329c24c2f4 Author: igerasim Date: 2013-07-29 12:35 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/54329c24c2f4 8020669: (fs) Files.readAllBytes() does not read any data when Files.size() is 0 Reviewed-by: alanb, chegar, martin, rriggs ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java Changeset: d6de149b9f20 Author: xuelei Date: 2013-08-01 07:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d6de149b9f20 7127524: P11TlsPrfGenerator has anonymous inner class with serialVersionUID Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java Changeset: cd13a4a45a37 Author: chegar Date: 2013-08-01 16:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cd13a4a45a37 8022087: Fix doclint issues in j.u.Deque & Queue Reviewed-by: chegar, darcy Contributed-by: Doug Lea
! src/share/classes/java/util/Deque.java ! src/share/classes/java/util/Queue.java Changeset: 0be7839d4599 Author: psandoz Date: 2013-08-01 15:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0be7839d4599 8020016: Numerous splitereator impls do not throw NPE for null Consumers Reviewed-by: mduigou, alanb, henryjen ! src/share/classes/java/util/stream/SpinedBuffer.java ! src/share/classes/java/util/stream/StreamSpliterators.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java ! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java Changeset: 29f153e11683 Author: weijun Date: 2013-08-02 08:59 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/29f153e11683 8021789: jarsigner parses alias as command line option (depending on locale) Reviewed-by: vinnie ! src/share/classes/sun/security/tools/jarsigner/Main.java + test/sun/security/tools/jarsigner/collator.sh Changeset: 40221b09812f Author: uta Date: 2013-08-02 13:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/40221b09812f 8020191: System.getProperty("os.name") returns "Windows NT (unknown)" on Windows 8.1 Reviewed-by: alanb, khazra, chegar ! src/windows/native/java/lang/java_props_md.c ! src/windows/resource/java.manifest Changeset: 60c275e56a69 Author: chegar Date: 2013-08-02 11:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/60c275e56a69 8022121: Remove superfluous @test tag from SpliteratorTraversingAndSplittingTest Reviewed-by: psandoz ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java Changeset: 6ec910ff3ea1 Author: chegar Date: 2013-08-02 14:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6ec910ff3ea1 8020291: j.u.c.CompletionStage 8020435: CompletableFuture/Basic.java fails on single core machine Reviewed-by: chegar, psandoz Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/CompletableFuture.java + src/share/classes/java/util/concurrent/CompletionStage.java ! test/ProblemList.txt ! test/java/util/concurrent/CompletableFuture/Basic.java Changeset: 42b786f2fb99 Author: mullan Date: 2013-08-02 08:30 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/42b786f2fb99 8001319: Add SecurityPermission "insertProvider" target name Reviewed-by: vinnie ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/SecurityPermission.java + test/java/security/Security/AddProvider.java + test/java/security/Security/AddProvider.policy.1 + test/java/security/Security/AddProvider.policy.2 + test/java/security/Security/AddProvider.policy.3 Changeset: 7bbc6c2351d7 Author: mullan Date: 2013-08-02 08:37 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7bbc6c2351d7 Merge - src/share/classes/java/net/package.html - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 0a778e487a73 Author: mullan Date: 2013-08-02 09:38 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0a778e487a73 Merge Changeset: 33617583c545 Author: bpb Date: 2013-07-31 10:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/33617583c545 6476168: (fmt) Inconsistency formatting subnormal doubles with hexadecimal conversion Summary: Update specification to match implementation. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/Formatter.java ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicDouble.java Changeset: 883cc296ec89 Author: bchristi Date: 2013-08-02 15:30 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/883cc296ec89 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X Summary: On Mac, default to UTF-8 if no environmental hints are available Reviewed-by: naoto, ddehaven ! src/solaris/native/java/lang/java_props_md.c + test/java/lang/System/MacEncoding/ExpectedEncoding.java + test/java/lang/System/MacEncoding/MacJNUEncoding.sh + test/java/lang/System/MacEncoding/TestFileEncoding.java - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh Changeset: dd1040690e31 Author: bpb Date: 2013-08-02 11:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dd1040690e31 8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect Summary: Fail test if errors; fix test values; port BigDecimal version to BigInteger Reviewed-by: smarks, alanb Contributed-by: Brian Burkhalter ! test/java/math/BigDecimal/CompareToTests.java ! test/java/math/BigInteger/CompareToTests.java Changeset: 80da091343af Author: darcy Date: 2013-08-05 07:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/80da091343af 8022190: Fix varargs lint warnings in the JDK Reviewed-by: alanb, lancea, alexsch ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/swing/AccumulativeRunnable.java Changeset: 87367a1c7f76 Author: sundar Date: 2013-08-05 21:31 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/87367a1c7f76 8016531: jconsole-plugin script demo does not work with nashorn Reviewed-by: lagergren, hannesw Contributed-by: rieberandreas at gmail.com ! 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/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/sample/scripting/scriptpad/README.txt ! src/share/sample/scripting/scriptpad/src/resources/conc.js ! src/share/sample/scripting/scriptpad/src/resources/mm.js Changeset: 31759750ff63 Author: smarks Date: 2013-08-05 19:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/31759750ff63 8020854: change RMI javadocs to specify that remote objects are exported to the wildcard address Reviewed-by: rgallard, alanb ! src/share/classes/java/rmi/server/RMISocketFactory.java ! src/share/classes/java/rmi/server/UnicastRemoteObject.java Changeset: fce446b29577 Author: dsamersoff Date: 2013-08-06 14:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fce446b29577 8011038: sourceObj validation during desereliazation of RelationNotification should be relaxed Summary: sourceObj could be set to null by setSource() relax a validation of deserialized object. Reviewed-by: sjiang, skoivu, dfuchs ! src/share/classes/javax/management/relation/RelationNotification.java Changeset: 6773af0dda02 Author: chegar Date: 2013-08-06 15:35 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6773af0dda02 8022344: Additional debug info for test/java/net/NetworkInterface/IndexTest.java Reviewed-by: michaelm, alanb ! test/java/net/NetworkInterface/IndexTest.java Changeset: 1f4af3e0447e Author: mullan Date: 2013-08-06 08:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1f4af3e0447e 8022120: JCK test api/javax_xml/crypto/dsig/TransformService/index_ParamMethods fails Summary: TransformService.init and marshalParams must throw NullPointerException when parent parameter is null Reviewed-by: xuelei ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java + test/javax/xml/crypto/dsig/TransformService/NullParent.java Changeset: ba634b53f53a Author: mullan Date: 2013-08-06 08:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ba634b53f53a Merge Changeset: cd0ea5563523 Author: jfranck Date: 2013-08-06 18:54 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cd0ea5563523 7184826: (reflect) Add support for Project Lambda concepts in core reflection Reviewed-by: darcy, jfranck Contributed-by: Amy Lu + test/java/lang/reflect/DefaultStaticTest/DefaultStaticInvokeTest.java + test/java/lang/reflect/DefaultStaticTest/DefaultStaticTestData.java + test/java/lang/reflect/DefaultStaticTest/helper/Declared.java + test/java/lang/reflect/DefaultStaticTest/helper/Mod.java ! test/java/lang/reflect/Method/DefaultMethodModeling.java ! test/java/lang/reflect/Method/IsDefaultTest.java Changeset: 98643f3ddf40 Author: darcy Date: 2013-08-06 13:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/98643f3ddf40 8022174: Fix doclint warnings in javax.sound 8022404: Fix doclint issues in java.applet Reviewed-by: prr ! src/share/classes/java/applet/AppletContext.java ! src/share/classes/javax/sound/midi/MetaMessage.java ! src/share/classes/javax/sound/midi/MidiDevice.java ! src/share/classes/javax/sound/midi/MidiDeviceReceiver.java ! src/share/classes/javax/sound/midi/MidiDeviceTransmitter.java ! src/share/classes/javax/sound/midi/MidiFileFormat.java ! src/share/classes/javax/sound/midi/MidiMessage.java ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/sound/midi/ShortMessage.java ! src/share/classes/javax/sound/midi/Synthesizer.java ! src/share/classes/javax/sound/midi/SysexMessage.java ! src/share/classes/javax/sound/midi/Track.java ! src/share/classes/javax/sound/sampled/AudioFileFormat.java ! src/share/classes/javax/sound/sampled/AudioFormat.java ! src/share/classes/javax/sound/sampled/AudioSystem.java ! src/share/classes/javax/sound/sampled/BooleanControl.java ! src/share/classes/javax/sound/sampled/Mixer.java ! src/share/classes/javax/sound/sampled/spi/FormatConversionProvider.java Changeset: 12c1b78acf9a Author: lagergren Date: 2013-08-06 12:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/12c1b78acf9a 8022412: Fixed warnings in java.util root, except for HashMap Reviewed-by: mduigou, darcy Contributed-by: marcus.lagergren at oracle.com ! src/share/classes/java/util/ArrayPrefixHelpers.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Comparator.java ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/WeakHashMap.java Changeset: 8112076ae424 Author: juh Date: 2013-08-06 13:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8112076ae424 8022439: Fix lint warnings in sun.security.ec Reviewed-by: darcy ! src/share/classes/sun/security/ec/ECDSASignature.java Changeset: 69cfd941aec2 Author: juh Date: 2013-08-06 14:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/69cfd941aec2 8022443: Fix lint warnings in sun.security.pkcs12 Reviewed-by: darcy ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java Changeset: 31e923842d49 Author: smarks Date: 2013-08-06 14:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/31e923842d49 8022440: suppress deprecation warnings in sun.rmi Reviewed-by: mduigou ! src/share/classes/sun/rmi/runtime/Log.java ! src/share/classes/sun/rmi/server/ActivatableRef.java ! src/share/classes/sun/rmi/server/Dispatcher.java ! src/share/classes/sun/rmi/server/LoaderHandler.java ! src/share/classes/sun/rmi/server/UnicastRef.java ! src/share/classes/sun/rmi/server/UnicastServerRef.java ! src/share/classes/sun/rmi/server/Util.java ! src/share/classes/sun/rmi/transport/DGCImpl.java ! src/share/classes/sun/rmi/transport/StreamRemoteCall.java ! src/share/classes/sun/rmi/transport/Transport.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/TCPTransport.java Changeset: 4b8b811059db Author: dxu Date: 2013-08-06 14:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4b8b811059db 8022410: Fix Javac Warnings in com.sun.security.auth Package Reviewed-by: darcy ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/SubjectCodeSource.java Changeset: d5694d78ebc6 Author: darcy Date: 2013-08-06 16:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d5694d78ebc6 8022406: Fix doclint issues in java.beans Reviewed-by: prr ! src/share/classes/java/beans/AppletInitializer.java ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/ConstructorProperties.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/Expression.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PersistenceDelegate.java ! src/share/classes/java/beans/PropertyChangeSupport.java ! src/share/classes/java/beans/PropertyDescriptor.java ! src/share/classes/java/beans/Transient.java ! src/share/classes/java/beans/VetoableChangeSupport.java ! src/share/classes/java/beans/beancontext/BeanContext.java ! src/share/classes/java/beans/beancontext/BeanContextChild.java ! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java ! src/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java ! src/share/classes/java/beans/beancontext/BeanContextServices.java ! src/share/classes/java/beans/beancontext/BeanContextServicesSupport.java ! src/share/classes/java/beans/beancontext/BeanContextSupport.java Changeset: 939c3be6cc86 Author: briangoetz Date: 2013-06-28 16:26 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/939c3be6cc86 8015318: Extend Collector with 'finish' operation Reviewed-by: mduigou Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/util/DoubleSummaryStatistics.java ! src/share/classes/java/util/IntSummaryStatistics.java ! src/share/classes/java/util/LongSummaryStatistics.java ! src/share/classes/java/util/StringJoiner.java ! src/share/classes/java/util/stream/Collector.java ! src/share/classes/java/util/stream/Collectors.java ! src/share/classes/java/util/stream/DelegatingStream.java ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/ReduceOps.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/package-info.java ! test/java/util/stream/test/org/openjdk/tests/java/util/FillableStringTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java ! test/jdk/lambda/MethodReferenceTestInstanceMethod.java ! test/jdk/lambda/separate/TestHarness.java Changeset: 6cc8c2ad9804 Author: darcy Date: 2013-08-06 16:45 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6cc8c2ad9804 8022453: Fix doclint issues in javax.accessibility Reviewed-by: prr ! src/share/classes/javax/accessibility/Accessible.java ! src/share/classes/javax/accessibility/AccessibleBundle.java ! src/share/classes/javax/accessibility/AccessibleExtendedTable.java ! src/share/classes/javax/accessibility/AccessibleRelationSet.java ! src/share/classes/javax/accessibility/AccessibleTable.java ! src/share/classes/javax/accessibility/AccessibleTableModelChange.java ! src/share/classes/javax/accessibility/AccessibleTextSequence.java ! src/share/classes/javax/accessibility/AccessibleValue.java Changeset: 2bc9ce1aade5 Author: lana Date: 2013-08-06 17:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2bc9ce1aade5 Merge Changeset: 7ab5f19a9a31 Author: lana Date: 2013-08-06 17:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7ab5f19a9a31 Merge Changeset: e303c228bf31 Author: henryjen Date: 2013-08-06 17:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e303c228bf31 8022446: Fix serial warnings in java.util.stream Reviewed-by: darcy ! src/share/classes/java/util/stream/AbstractShortCircuitTask.java ! src/share/classes/java/util/stream/AbstractTask.java ! src/share/classes/java/util/stream/FindOps.java ! src/share/classes/java/util/stream/ForEachOps.java ! src/share/classes/java/util/stream/MatchOps.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/ReduceOps.java ! src/share/classes/java/util/stream/SliceOps.java Changeset: 1d21ff5c2b3f Author: dxu Date: 2013-08-06 18:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1d21ff5c2b3f 8022478: Fix Warnings In sun.net.www.protocol.http Package Reviewed-by: darcy ! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java Changeset: e117fcdd2176 Author: mduigou Date: 2013-08-06 18:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e117fcdd2176 8022476: cleanup some raw types and unchecked warnings in java.util.stream Reviewed-by: darcy Contributed-by: mike.duigou at oracle.com, henry.jen at oracle.com ! src/share/classes/java/util/Optional.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/AbstractShortCircuitTask.java ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/ReduceOps.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Sink.java ! src/share/classes/java/util/stream/SortedOps.java ! src/share/classes/java/util/stream/StreamSpliterators.java Changeset: 906dd23334c1 Author: weijun Date: 2013-08-07 19:06 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/906dd23334c1 7151062: [macosx] SCDynamicStore prints error messages to stderr Reviewed-by: xuelei ! src/macosx/native/java/util/SCDynamicStoreConfig.m Changeset: 99f4319763a9 Author: sundar Date: 2013-08-07 18:16 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/99f4319763a9 8022483: Nashorn compatibility issues in jhat's OQL feature Reviewed-by: lagergren, attila, hannesw ! src/share/classes/com/sun/tools/hat/resources/hat.js ! src/share/classes/com/sun/tools/hat/resources/oqlhelp.html Changeset: 8c7cf4926157 Author: xuelei Date: 2013-08-07 06:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8c7cf4926157 8013809: deadlock in SSLSocketImpl between between write and close Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/SSLSocketImpl.java Changeset: c1f129f62f36 Author: lagergren Date: 2013-08-07 08:08 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c1f129f62f36 8022454: Fixed various serializations and deprecation warnings in java.util, java.net and sun.tools Reviewed-by: darcy Contributed-by: marcus.lagergren at oracle.com ! src/share/classes/java/net/SocketAddress.java ! src/share/classes/java/util/logging/XMLFormatter.java ! src/share/classes/sun/tools/jar/JarException.java Changeset: d1c82d5bee3f Author: dxu Date: 2013-08-07 12:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d1c82d5bee3f 8022554: Fix Warnings in sun.invoke.anon Package Reviewed-by: darcy, mduigou, lancea ! src/share/classes/sun/invoke/anon/ConstantPoolPatch.java Changeset: 8c50c27418d3 Author: smarks Date: 2013-08-07 16:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8c50c27418d3 8022479: clean up warnings from sun.tools.asm Reviewed-by: lancea, darcy ! src/share/classes/sun/tools/asm/Assembler.java ! src/share/classes/sun/tools/asm/ConstantPool.java ! src/share/classes/sun/tools/asm/Instruction.java ! src/share/classes/sun/tools/asm/SwitchData.java ! src/share/classes/sun/tools/asm/TryData.java Changeset: 23e68a8e4b91 Author: lana Date: 2013-08-07 19:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/23e68a8e4b91 Merge - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh Changeset: e0f6039c0290 Author: lana Date: 2013-08-13 10:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e0f6039c0290 Merge Changeset: f1d8d15bfcb5 Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f1d8d15bfcb5 Added tag jdk8-b103 for changeset e0f6039c0290 ! .hgtags From john.coomes at oracle.com Thu Aug 15 11:02:29 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 15 Aug 2013 18:02:29 +0000 Subject: hg: hsx/hotspot-main/langtools: 11 new changesets Message-ID: <20130815180313.16165488E6@hg.openjdk.java.net> Changeset: 05370ef9dccb Author: ksrini Date: 2013-07-31 08:37 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/05370ef9dccb 8014826: c.s.t.javac.tree.Pretty.visitNewArray() prints duplicate dimension markers Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/tree/Pretty.java + test/tools/javac/tree/NewArrayPretty.java Changeset: 99b60bcf3862 Author: vromero Date: 2013-08-06 15:08 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/99b60bcf3862 8022186: javac generates dead code if a try with an empty body has a finalizer Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T8022186/DeadCodeGeneratedForEmptyTryTest.java Changeset: 051e64d0816e Author: jfranck Date: 2013-08-07 01:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/051e64d0816e 8009367: Wrong kind of name used in comparison in javax.lang.model code for repeatable annotations Reviewed-by: jjg, darcy ! src/share/classes/com/sun/tools/javac/model/JavacAnnoConstructs.java + test/tools/javac/processing/model/element/8009367/TestQualifiedNameUsed.java + test/tools/javac/processing/model/element/8009367/p/Q.java + test/tools/javac/processing/model/element/8009367/p/QQ.java + test/tools/javac/processing/model/element/8009367/p/R.java + test/tools/javac/processing/model/element/8009367/p/RR.java Changeset: f3ea20a6e958 Author: lana Date: 2013-08-06 17:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f3ea20a6e958 Merge Changeset: b926dc251be8 Author: lana Date: 2013-08-06 17:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b926dc251be8 Merge Changeset: f3deeccbf4cf Author: vromero Date: 2013-08-07 10:41 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f3deeccbf4cf 8020997: TreeMaker.AnnotationBuilder creates broken element literals with repeating annotations Reviewed-by: jjg, jfranck ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/T8020997/CannotCompileRepeatedAnnoTest.java Changeset: c7dcf899ffff Author: vromero Date: 2013-08-07 11:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/c7dcf899ffff 8008274: javac should not reference/use sample code Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/Main.java Changeset: 8c55df2442c1 Author: bpatel Date: 2013-08-07 15:00 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8c55df2442c1 7198274: RFE : Javadoc Accessibility : Use CSS styles rather than or tags Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.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/ClassWriterImpl.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/HtmlDocletWriter.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/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PropertyWriterImpl.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/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testJavaFX/TestJavaFX.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/com/sun/javadoc/testPackageDeprecation/TestPackageDeprecation.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java Changeset: 33294f02c9a5 Author: bpatel Date: 2013-08-07 16:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/33294f02c9a5 4749567: stddoclet: Add CSS style for setting header/footer to be italic Reviewed-by: jjg ! 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/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css + test/com/sun/javadoc/testOptions/TestOptions.java + test/com/sun/javadoc/testOptions/pkg/Foo.java Changeset: 76cfe7c61f25 Author: lana Date: 2013-08-13 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/76cfe7c61f25 Merge Changeset: dd4a00c220c6 Author: cl Date: 2013-08-15 09:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/dd4a00c220c6 Added tag jdk8-b103 for changeset 76cfe7c61f25 ! .hgtags From john.coomes at oracle.com Thu Aug 15 11:03:24 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 15 Aug 2013 18:03:24 +0000 Subject: hg: hsx/hotspot-main/nashorn: 5 new changesets Message-ID: <20130815180333.48EE4488E7@hg.openjdk.java.net> Changeset: 0ad00ae4fec6 Author: hannesw Date: 2013-08-01 12:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0ad00ae4fec6 8020132: Big object literal with numerical keys exceeds method size Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java + test/script/basic/JDK-8020132.js + test/script/basic/JDK-8020132.js.EXPECTED Changeset: bb0f3c896cb7 Author: sundar Date: 2013-08-06 13:10 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/bb0f3c896cb7 Merge Changeset: ab90c566272d Author: lana Date: 2013-08-06 17:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ab90c566272d Merge Changeset: 414203de4374 Author: lana Date: 2013-08-13 10:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/414203de4374 Merge Changeset: afc100513451 Author: cl Date: 2013-08-15 09:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/afc100513451 Added tag jdk8-b103 for changeset 414203de4374 ! .hgtags From Peter.B.Kessler at Oracle.COM Thu Aug 15 11:16:28 2013 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Thu, 15 Aug 2013 11:16:28 -0700 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> Message-ID: <520D1AFC.7050505@Oracle.COM> On 08/15/13 02:44, Dawid Weiss wrote: > This just has to have something to do with G1GC, inlining, escape > analysis and c2 optimizations (as if there was anything else :). > > Seems like an update to one of the variables is lost (nextSlice method > in ByteSliceReader). This method is inlined heavily; I checked the > following, all of which results in no errors. > > 1) passed "-XX:-Inline" - no errors > > 2) excluded separately "nextSlice" and the "parent" method from > compilation - no errors > > 3) "-XX:-DoEscapeAnalysis" - preventing escape analysis - no errors > > 4) added a dummy value flush in ByteSliceReader.nextSlice by modifying: > > upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK; > > to > > foo = upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK; > > where foo is a static field with no other accesses -- no errors. This is interesting. "upto" is an int, so it's not like storing its value in foo gives G1GC a root to discover objects that it didn't have before, e.g., if a write-barrier were missing. This change would seem to let G1GC off the hook. Except to the extent that using G1GC somehow triggers the bug. I don't understand enough about your code to guess why. What happens if you perturb "upto" in other ways. E.g., by declaring it "volatile" even though this code seems to be single-threaded. Or by making "upto" private and using accessor methods? I'm just guessing. ... peter > 5) Changing G1GC to any other GC - no errors. > > I also dumped the generated assembly for the flush() method. It's huge > and, sigh, it's sometimes different even for two runs with identical > options; I'm guessing parallel compilation tasks hit different stats? > I noticed upto field write gets optimized away for certain loops but > the entire logic after all the ideal graph optimizations is not clear > from the assembly dump. > > So it's still an open issue. > > D. > > > On Wed, Aug 14, 2013 at 2:54 PM, Dawid Weiss wrote: >> I don't have a debug build but I have hsdis so I can dump the assembly >> ;) Robert mentioned the code passes with -Xint and -Xbatch so it's >> probably a dynamic optimization of some sort. I'll do some digging >> later today, thanks for the hint, Uwe. >> >> Dawid From dawid.weiss at gmail.com Thu Aug 15 11:31:13 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Thu, 15 Aug 2013 20:31:13 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: <520D1AFC.7050505@Oracle.COM> References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> Message-ID: Yeah, I don't understand it either. An assembly dump shows code differences though -- perhaps it's a side effect of something... don't know, still digging, time permitting. I'll let you know if I can figure out something more useful. On Thu, Aug 15, 2013 at 8:16 PM, Peter B. Kessler wrote: > On 08/15/13 02:44, Dawid Weiss wrote: >> >> This just has to have something to do with G1GC, inlining, escape >> analysis and c2 optimizations (as if there was anything else :). >> >> Seems like an update to one of the variables is lost (nextSlice method >> in ByteSliceReader). This method is inlined heavily; I checked the >> following, all of which results in no errors. >> >> 1) passed "-XX:-Inline" - no errors >> >> 2) excluded separately "nextSlice" and the "parent" method from >> compilation - no errors >> >> 3) "-XX:-DoEscapeAnalysis" - preventing escape analysis - no errors >> >> 4) added a dummy value flush in ByteSliceReader.nextSlice by modifying: >> >> upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK; >> >> to >> >> foo = upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK; >> >> where foo is a static field with no other accesses -- no errors. > > > This is interesting. "upto" is an int, so it's not like storing its value > in foo gives G1GC a root to discover objects that it didn't have before, > e.g., if a write-barrier were missing. This change would seem to let G1GC > off the hook. Except to the extent that using G1GC somehow triggers the > bug. I don't understand enough about your code to guess why. > > What happens if you perturb "upto" in other ways. E.g., by declaring it > "volatile" even though this code seems to be single-threaded. Or by making > "upto" private and using accessor methods? > > I'm just guessing. > > ... peter > > >> 5) Changing G1GC to any other GC - no errors. >> >> I also dumped the generated assembly for the flush() method. It's huge >> and, sigh, it's sometimes different even for two runs with identical >> options; I'm guessing parallel compilation tasks hit different stats? >> I noticed upto field write gets optimized away for certain loops but >> the entire logic after all the ideal graph optimizations is not clear >> from the assembly dump. >> >> So it's still an open issue. >> >> D. >> >> >> On Wed, Aug 14, 2013 at 2:54 PM, Dawid Weiss >> wrote: >>> >>> I don't have a debug build but I have hsdis so I can dump the assembly >>> ;) Robert mentioned the code passes with -Xint and -Xbatch so it's >>> probably a dynamic optimization of some sort. I'll do some digging >>> later today, thanks for the hint, Uwe. >>> >>> Dawid From vladimir.kozlov at oracle.com Thu Aug 15 12:03:07 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Aug 2013 12:03:07 -0700 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> Message-ID: <520D25EB.7030005@oracle.com> Dawid, It is with high probability Compiler problem. G1 has larger write-barrier code then other GCs. It can affect inlining decisions. You can try to change -XX:InlineSmallCode=1000 value. It controls inlining of methods which were already compiled. You can also try -Xbatch -XX:CICompilerCount=1 to get serial compilations. Vladimir On 8/15/13 11:31 AM, Dawid Weiss wrote: > Yeah, I don't understand it either. An assembly dump shows code > differences though -- perhaps it's a side effect of something... don't > know, still digging, time permitting. I'll let you know if I can > figure out something more useful. > > On Thu, Aug 15, 2013 at 8:16 PM, Peter B. Kessler > wrote: >> On 08/15/13 02:44, Dawid Weiss wrote: >>> >>> This just has to have something to do with G1GC, inlining, escape >>> analysis and c2 optimizations (as if there was anything else :). >>> >>> Seems like an update to one of the variables is lost (nextSlice method >>> in ByteSliceReader). This method is inlined heavily; I checked the >>> following, all of which results in no errors. >>> >>> 1) passed "-XX:-Inline" - no errors >>> >>> 2) excluded separately "nextSlice" and the "parent" method from >>> compilation - no errors >>> >>> 3) "-XX:-DoEscapeAnalysis" - preventing escape analysis - no errors >>> >>> 4) added a dummy value flush in ByteSliceReader.nextSlice by modifying: >>> >>> upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK; >>> >>> to >>> >>> foo = upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK; >>> >>> where foo is a static field with no other accesses -- no errors. >> >> >> This is interesting. "upto" is an int, so it's not like storing its value >> in foo gives G1GC a root to discover objects that it didn't have before, >> e.g., if a write-barrier were missing. This change would seem to let G1GC >> off the hook. Except to the extent that using G1GC somehow triggers the >> bug. I don't understand enough about your code to guess why. >> >> What happens if you perturb "upto" in other ways. E.g., by declaring it >> "volatile" even though this code seems to be single-threaded. Or by making >> "upto" private and using accessor methods? >> >> I'm just guessing. >> >> ... peter >> >> >>> 5) Changing G1GC to any other GC - no errors. >>> >>> I also dumped the generated assembly for the flush() method. It's huge >>> and, sigh, it's sometimes different even for two runs with identical >>> options; I'm guessing parallel compilation tasks hit different stats? >>> I noticed upto field write gets optimized away for certain loops but >>> the entire logic after all the ideal graph optimizations is not clear >>> from the assembly dump. >>> >>> So it's still an open issue. >>> >>> D. >>> >>> >>> On Wed, Aug 14, 2013 at 2:54 PM, Dawid Weiss >>> wrote: >>>> >>>> I don't have a debug build but I have hsdis so I can dump the assembly >>>> ;) Robert mentioned the code passes with -Xint and -Xbatch so it's >>>> probably a dynamic optimization of some sort. I'll do some digging >>>> later today, thanks for the hint, Uwe. >>>> >>>> Dawid From goetz.lindenmaier at sap.com Thu Aug 15 14:32:00 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 15 Aug 2013 21:32:00 +0000 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <520CF907.3040908@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> Hi Vladimir, throw is needed because it`s there in the implementation in nmethod.cpp. (So you are using it a bit at least :)) xlc says "nmethod.cpp", line 802.7: 1540-0400 (S) "nmethod::operator new(size_t, int)" has a conflicting declaration. "nmethod.hpp", line 268.9: 1540-0424 (I) "operator new" is declared on line 268 of "nmethod.hpp". int64 is defined correctly, uint64 is not defined, but never used in hotspot. I can not reproduce an error, but that's rather old coding from our VM. We also switched from xlc8 to xlc10 in the course of this project. I will test some more and talk to the person who implemented that tomorrow, and if possible remove the change. Best regards & thanks for the review, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, August 15, 2013 5:52 PM To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net; Albert Noll (albert.noll at oracle.com) Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX Goetz, I only see 2 problems which you did not explain: nmethod.hpp. Why the next change? we don't use C++ exceptions: - void* operator new(size_t size, int nmethod_size); + void* operator new(size_t size, int nmethod_size) throw (); port.hpp. Did AIX has the same definitions for jlong and julong?: +#ifndef _AIX +// These conflict with /usr/include/sys/inttypes.h on aix. typedef jlong int64; // Java long for my 64-bit type typedef julong uint64; // Java long for my 64-bit type +#endif And of cause we need to test these changes with compilers we use. Thanks, Vladimir On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: > Hi, > > I prepared a webrev for > 8023033: PPC64 (part 13): basic changes for AIX > http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ > > This contains the basic shared changes needed for the AIX port, > as there are > - #includes > - Fixes to get the code compiling with xlC/on AIX > - Basic adaptions as in vm_version.cpp. > > It also determines the placement and naming of the aix files, > which will go to os/aix and os_cpu/aix_ppc, as you can see in > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ > > Some details about the compilation problems: > > relocInfo.hpp: > xlC wants initialization in inline implementation. > > vmreg.hpp: > BAD is defined in AIX system header sys/param.h. Renamed. > > allocation.hpp > xlC complains: > runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" member "StackObj::operator delete(void *)" cannot be accessed. > > sharedRuntimeTrig.cpp > Aix defines hz to be 100, see sys/m_param.h. Renamed. > > debug.hpp > With other include order we get a lot of > memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not declared. > > > Please review and test this change. Comments are welcome. > > Thanks and best regards, > Goetz. > From vladimir.kozlov at oracle.com Thu Aug 15 14:54:12 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Aug 2013 14:54:12 -0700 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> Message-ID: <520D4E04.3010709@oracle.com> On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > throw is needed because it`s there in the implementation in nmethod.cpp. > (So you are using it a bit at least :)) > xlc says > "nmethod.cpp", line 802.7: 1540-0400 (S) "nmethod::operator new(size_t, int)" has a conflicting declaration. > "nmethod.hpp", line 268.9: 1540-0424 (I) "operator new" is declared on line 268 of "nmethod.hpp". Okay, it is just declaration. > > int64 is defined correctly, uint64 is not defined, but never used in hotspot. > I can not reproduce an error, but that's rather old coding from our VM. > We also switched from xlc8 to xlc10 in the course of this project. > I will test some more and talk to the person who implemented that tomorrow, > and if possible remove the change. Okay, I will test it also. Vladimir > > Best regards & thanks for the review, > Goetz. > > > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, August 15, 2013 5:52 PM > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net; Albert Noll (albert.noll at oracle.com) > Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX > > Goetz, > > I only see 2 problems which you did not explain: > > nmethod.hpp. Why the next change? we don't use C++ exceptions: > > - void* operator new(size_t size, int nmethod_size); > + void* operator new(size_t size, int nmethod_size) throw (); > > port.hpp. Did AIX has the same definitions for jlong and julong?: > > +#ifndef _AIX > +// These conflict with /usr/include/sys/inttypes.h on aix. > typedef jlong int64; // Java long for my 64-bit type > typedef julong uint64; // Java long for my 64-bit type > +#endif > > > And of cause we need to test these changes with compilers we use. > > Thanks, > Vladimir > > On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I prepared a webrev for >> 8023033: PPC64 (part 13): basic changes for AIX >> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >> >> This contains the basic shared changes needed for the AIX port, >> as there are >> - #includes >> - Fixes to get the code compiling with xlC/on AIX >> - Basic adaptions as in vm_version.cpp. >> >> It also determines the placement and naming of the aix files, >> which will go to os/aix and os_cpu/aix_ppc, as you can see in >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >> >> Some details about the compilation problems: >> >> relocInfo.hpp: >> xlC wants initialization in inline implementation. >> >> vmreg.hpp: >> BAD is defined in AIX system header sys/param.h. Renamed. >> >> allocation.hpp >> xlC complains: >> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" member "StackObj::operator delete(void *)" cannot be accessed. >> >> sharedRuntimeTrig.cpp >> Aix defines hz to be 100, see sys/m_param.h. Renamed. >> >> debug.hpp >> With other include order we get a lot of >> memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not declared. >> >> >> Please review and test this change. Comments are welcome. >> >> Thanks and best regards, >> Goetz. >> From david.holmes at oracle.com Thu Aug 15 17:14:38 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Aug 2013 10:14:38 +1000 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <520D4E04.3010709@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> Message-ID: <520D6EEE.1040906@oracle.com> On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: > On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> throw is needed because it`s there in the implementation in nmethod.cpp. >> (So you are using it a bit at least :)) >> xlc says >> "nmethod.cpp", line 802.7: 1540-0400 (S) "nmethod::operator >> new(size_t, int)" has a conflicting declaration. >> "nmethod.hpp", line 268.9: 1540-0424 (I) "operator new" is declared on >> line 268 of "nmethod.hpp". > > Okay, it is just declaration. Why do we have throw here: void* nmethod::operator new(size_t size, int nmethod_size) throw () { // Not critical, may return null if there is too little continuous memory return CodeCache::allocate(nmethod_size); } Seems to me it should be removed if anything. David ----- > >> >> int64 is defined correctly, uint64 is not defined, but never used in >> hotspot. >> I can not reproduce an error, but that's rather old coding from our VM. >> We also switched from xlc8 to xlc10 in the course of this project. >> I will test some more and talk to the person who implemented that >> tomorrow, >> and if possible remove the change. > > Okay, I will test it also. > > Vladimir > >> >> Best regards & thanks for the review, >> Goetz. >> >> >> >> >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Thursday, August 15, 2013 5:52 PM >> To: Lindenmaier, Goetz >> Cc: 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net; >> Albert Noll (albert.noll at oracle.com) >> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX >> >> Goetz, >> >> I only see 2 problems which you did not explain: >> >> nmethod.hpp. Why the next change? we don't use C++ exceptions: >> >> - void* operator new(size_t size, int nmethod_size); >> + void* operator new(size_t size, int nmethod_size) throw (); >> >> port.hpp. Did AIX has the same definitions for jlong and julong?: >> >> +#ifndef _AIX >> +// These conflict with /usr/include/sys/inttypes.h on aix. >> typedef jlong int64; // Java long for my 64-bit type >> typedef julong uint64; // Java long for my 64-bit type >> +#endif >> >> >> And of cause we need to test these changes with compilers we use. >> >> Thanks, >> Vladimir >> >> On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I prepared a webrev for >>> 8023033: PPC64 (part 13): basic changes for AIX >>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >>> >>> This contains the basic shared changes needed for the AIX port, >>> as there are >>> - #includes >>> - Fixes to get the code compiling with xlC/on AIX >>> - Basic adaptions as in vm_version.cpp. >>> >>> It also determines the placement and naming of the aix files, >>> which will go to os/aix and os_cpu/aix_ppc, as you can see in >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >>> >>> >>> Some details about the compilation problems: >>> >>> relocInfo.hpp: >>> xlC wants initialization in inline implementation. >>> >>> vmreg.hpp: >>> BAD is defined in AIX system header sys/param.h. Renamed. >>> >>> allocation.hpp >>> xlC complains: >>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" >>> member "StackObj::operator delete(void *)" cannot be accessed. >>> >>> sharedRuntimeTrig.cpp >>> Aix defines hz to be 100, see sys/m_param.h. Renamed. >>> >>> debug.hpp >>> With other include order we get a lot of >>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not >>> declared. >>> >>> >>> Please review and test this change. Comments are welcome. >>> >>> Thanks and best regards, >>> Goetz. >>> From david.holmes at oracle.com Thu Aug 15 17:48:19 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Aug 2013 10:48:19 +1000 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> Message-ID: <520D76D3.7000605@oracle.com> Hi Goetz, On 15/08/2013 10:10 PM, Lindenmaier, Goetz wrote: > I prepared a webrev for > 8023033: PPC64 (part 13): basic changes for AIX > http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ > > This contains the basic shared changes needed for the AIX port, > as there are > - #includes Aside: Seeing this I'm now firmly convinced that the platform-include mechanism is worse than the old includeDB mechanism that it replaced. We really need a way to #include these based on the value of the platform variable :( > - Fixes to get the code compiling with xlC/on AIX Are there makefile changes for xlC support as well? > - Basic adaptions as in vm_version.cpp. > > It also determines the placement and naming of the aix files, > which will go to os/aix and os_cpu/aix_ppc, as you can see in > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ > > Some details about the compilation problems: > > relocInfo.hpp: > xlC wants initialization in inline implementation. > > vmreg.hpp: > BAD is defined in AIX system header sys/param.h. Renamed. > > allocation.hpp > xlC complains: > runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" member "StackObj::operator delete(void *)" cannot be accessed. Hmmm. So the whole point of these being private was so that they could not be called but we had to override the use of the global operators. The concrete implementations then give fatal errors if you do manage to use them (impossible?). So making them public is undesirable. Is there some other way to resolve this? A pragma to tell xlC to ignore the perceived problem? > sharedRuntimeTrig.cpp > Aix defines hz to be 100, see sys/m_param.h. Renamed. It #defines a lowercase constant! Ouch! :) > debug.hpp > With other include order we get a lot of > memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not declared. Curious. BTW have you tested with and without precompiled headers enabled? > > Please review and test this change. Comments are welcome. Typo in src/share/vm/memory/universe.cpp: preserverd src/share/vm/utilities/resourceHash.hpp: Is this recognized as a compiler bug? Thanks, David > Thanks and best regards, > Goetz. > From vladimir.kozlov at oracle.com Thu Aug 15 22:20:55 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Aug 2013 22:20:55 -0700 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <520D6EEE.1040906@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> <520D6EEE.1040906@oracle.com> Message-ID: <520DB6B7.2050901@oracle.com> I thought trow() was added long time ago. But it was added, I think by accident, very recently: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a7fb14888912 I missed it when I did the review of those changes. We should remove throw. Vladimir On 8/15/13 5:14 PM, David Holmes wrote: > On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: >> On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> throw is needed because it`s there in the implementation in nmethod.cpp. >>> (So you are using it a bit at least :)) >>> xlc says >>> "nmethod.cpp", line 802.7: 1540-0400 (S) "nmethod::operator >>> new(size_t, int)" has a conflicting declaration. >>> "nmethod.hpp", line 268.9: 1540-0424 (I) "operator new" is declared on >>> line 268 of "nmethod.hpp". >> >> Okay, it is just declaration. > > Why do we have throw here: > > void* nmethod::operator new(size_t size, int nmethod_size) throw () { > // Not critical, may return null if there is too little continuous memory > return CodeCache::allocate(nmethod_size); > } > > Seems to me it should be removed if anything. > > David > ----- > >> >>> >>> int64 is defined correctly, uint64 is not defined, but never used in >>> hotspot. >>> I can not reproduce an error, but that's rather old coding from our VM. >>> We also switched from xlc8 to xlc10 in the course of this project. >>> I will test some more and talk to the person who implemented that >>> tomorrow, >>> and if possible remove the change. >> >> Okay, I will test it also. >> >> Vladimir >> >>> >>> Best regards & thanks for the review, >>> Goetz. >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Thursday, August 15, 2013 5:52 PM >>> To: Lindenmaier, Goetz >>> Cc: 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net; >>> Albert Noll (albert.noll at oracle.com) >>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX >>> >>> Goetz, >>> >>> I only see 2 problems which you did not explain: >>> >>> nmethod.hpp. Why the next change? we don't use C++ exceptions: >>> >>> - void* operator new(size_t size, int nmethod_size); >>> + void* operator new(size_t size, int nmethod_size) throw (); >>> >>> port.hpp. Did AIX has the same definitions for jlong and julong?: >>> >>> +#ifndef _AIX >>> +// These conflict with /usr/include/sys/inttypes.h on aix. >>> typedef jlong int64; // Java long for my 64-bit type >>> typedef julong uint64; // Java long for my 64-bit type >>> +#endif >>> >>> >>> And of cause we need to test these changes with compilers we use. >>> >>> Thanks, >>> Vladimir >>> >>> On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I prepared a webrev for >>>> 8023033: PPC64 (part 13): basic changes for AIX >>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >>>> >>>> This contains the basic shared changes needed for the AIX port, >>>> as there are >>>> - #includes >>>> - Fixes to get the code compiling with xlC/on AIX >>>> - Basic adaptions as in vm_version.cpp. >>>> >>>> It also determines the placement and naming of the aix files, >>>> which will go to os/aix and os_cpu/aix_ppc, as you can see in >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >>>> >>>> >>>> Some details about the compilation problems: >>>> >>>> relocInfo.hpp: >>>> xlC wants initialization in inline implementation. >>>> >>>> vmreg.hpp: >>>> BAD is defined in AIX system header sys/param.h. Renamed. >>>> >>>> allocation.hpp >>>> xlC complains: >>>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" >>>> member "StackObj::operator delete(void *)" cannot be accessed. >>>> >>>> sharedRuntimeTrig.cpp >>>> Aix defines hz to be 100, see sys/m_param.h. Renamed. >>>> >>>> debug.hpp >>>> With other include order we get a lot of >>>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not >>>> declared. >>>> >>>> >>>> Please review and test this change. Comments are welcome. >>>> >>>> Thanks and best regards, >>>> Goetz. >>>> From stefan.karlsson at oracle.com Thu Aug 15 22:58:57 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 16 Aug 2013 07:58:57 +0200 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <520D76D3.7000605@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520D76D3.7000605@oracle.com> Message-ID: <520DBFA1.2060606@oracle.com> On 8/16/13 2:48 AM, David Holmes wrote: > Hi Goetz, > > On 15/08/2013 10:10 PM, Lindenmaier, Goetz wrote: >> I prepared a webrev for >> 8023033: PPC64 (part 13): basic changes for AIX >> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >> >> This contains the basic shared changes needed for the AIX port, >> as there are >> - #includes > > Aside: Seeing this I'm now firmly convinced that the platform-include > mechanism is worse than the old includeDB mechanism that it replaced. > We really need a way to #include these based on the value of the > platform variable :( Dave, You were always firmly convinced of that. :) Do you have a solution to the platform include problem that doesn't involve listing _all_ includes in separate list files? In the short term, we could at least hide os_<>.inline.hpp in a dispatch file. Just like we did for: 8003935: Simplify the needed includes for using Thread::current() http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3852 Here's a list of the added includes from the AIX patch: 18 +# include "os_aix.inline.hpp" 4 +# include "orderAccess_aix_ppc.inline.hpp" 3 +# include "jvm_aix.h" 2 +# include "c2_globals_aix.hpp" 2 +# include "c1_globals_aix.hpp" 1 +# include "vmStructs_aix_ppc.hpp" 1 +# include "utilities/globalDefinitions_xlc.hpp" 1 +# include "thread_aix_ppc.hpp" 1 +# include "thread_aix.inline.hpp" 1 +# include "threadLS_aix_ppc.hpp" 1 +# include "os_aix_ppc.hpp" 1 +# include "os_aix.hpp" 1 +# include "osThread_aix.hpp" 1 +# include "interfaceSupport_aix.hpp" 1 +# include "globals_aix_ppc.hpp" 1 +# include "globals_aix.hpp" 1 +# include "c2_globals_ppc.hpp" 1 +# include "atomic_aix_ppc.inline.hpp" StefanK > >> - Fixes to get the code compiling with xlC/on AIX > > Are there makefile changes for xlC support as well? > >> - Basic adaptions as in vm_version.cpp. >> >> It also determines the placement and naming of the aix files, >> which will go to os/aix and os_cpu/aix_ppc, as you can see in >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >> >> >> Some details about the compilation problems: >> >> relocInfo.hpp: >> xlC wants initialization in inline implementation. >> >> vmreg.hpp: >> BAD is defined in AIX system header sys/param.h. Renamed. >> >> allocation.hpp >> xlC complains: >> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" >> member "StackObj::operator delete(void *)" cannot be accessed. > > Hmmm. So the whole point of these being private was so that they could > not be called but we had to override the use of the global operators. > The concrete implementations then give fatal errors if you do manage > to use them (impossible?). So making them public is undesirable. > > Is there some other way to resolve this? A pragma to tell xlC to > ignore the perceived problem? > >> sharedRuntimeTrig.cpp >> Aix defines hz to be 100, see sys/m_param.h. Renamed. > > It #defines a lowercase constant! Ouch! :) > >> debug.hpp >> With other include order we get a lot of >> memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not >> declared. > > Curious. BTW have you tested with and without precompiled headers > enabled? > >> >> Please review and test this change. Comments are welcome. > > Typo in src/share/vm/memory/universe.cpp: preserverd > > src/share/vm/utilities/resourceHash.hpp: > > Is this recognized as a compiler bug? > > Thanks, > David > >> Thanks and best regards, >> Goetz. >> From david.holmes at oracle.com Thu Aug 15 23:26:55 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Aug 2013 16:26:55 +1000 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <520DBFA1.2060606@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520D76D3.7000605@oracle.com> <520DBFA1.2060606@oracle.com> Message-ID: <520DC62F.809@oracle.com> Stefan, Let's start a new thread on this :) David On 16/08/2013 3:58 PM, Stefan Karlsson wrote: > On 8/16/13 2:48 AM, David Holmes wrote: >> Hi Goetz, >> >> On 15/08/2013 10:10 PM, Lindenmaier, Goetz wrote: >>> I prepared a webrev for >>> 8023033: PPC64 (part 13): basic changes for AIX >>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >>> >>> This contains the basic shared changes needed for the AIX port, >>> as there are >>> - #includes >> >> Aside: Seeing this I'm now firmly convinced that the platform-include >> mechanism is worse than the old includeDB mechanism that it replaced. >> We really need a way to #include these based on the value of the >> platform variable :( > > Dave, > > You were always firmly convinced of that. :) > > Do you have a solution to the platform include problem that doesn't > involve listing _all_ includes in separate list files? > > In the short term, we could at least hide os_<>.inline.hpp in a dispatch > file. Just like we did for: > 8003935: Simplify the needed includes for using Thread::current() > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3852 > > Here's a list of the added includes from the AIX patch: > 18 +# include "os_aix.inline.hpp" > 4 +# include "orderAccess_aix_ppc.inline.hpp" > 3 +# include "jvm_aix.h" > 2 +# include "c2_globals_aix.hpp" > 2 +# include "c1_globals_aix.hpp" > 1 +# include "vmStructs_aix_ppc.hpp" > 1 +# include "utilities/globalDefinitions_xlc.hpp" > 1 +# include "thread_aix_ppc.hpp" > 1 +# include "thread_aix.inline.hpp" > 1 +# include "threadLS_aix_ppc.hpp" > 1 +# include "os_aix_ppc.hpp" > 1 +# include "os_aix.hpp" > 1 +# include "osThread_aix.hpp" > 1 +# include "interfaceSupport_aix.hpp" > 1 +# include "globals_aix_ppc.hpp" > 1 +# include "globals_aix.hpp" > 1 +# include "c2_globals_ppc.hpp" > 1 +# include "atomic_aix_ppc.inline.hpp" > > StefanK > >> >>> - Fixes to get the code compiling with xlC/on AIX >> >> Are there makefile changes for xlC support as well? >> >>> - Basic adaptions as in vm_version.cpp. >>> >>> It also determines the placement and naming of the aix files, >>> which will go to os/aix and os_cpu/aix_ppc, as you can see in >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >>> >>> >>> Some details about the compilation problems: >>> >>> relocInfo.hpp: >>> xlC wants initialization in inline implementation. >>> >>> vmreg.hpp: >>> BAD is defined in AIX system header sys/param.h. Renamed. >>> >>> allocation.hpp >>> xlC complains: >>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" >>> member "StackObj::operator delete(void *)" cannot be accessed. >> >> Hmmm. So the whole point of these being private was so that they could >> not be called but we had to override the use of the global operators. >> The concrete implementations then give fatal errors if you do manage >> to use them (impossible?). So making them public is undesirable. >> >> Is there some other way to resolve this? A pragma to tell xlC to >> ignore the perceived problem? >> >>> sharedRuntimeTrig.cpp >>> Aix defines hz to be 100, see sys/m_param.h. Renamed. >> >> It #defines a lowercase constant! Ouch! :) >> >>> debug.hpp >>> With other include order we get a lot of >>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not >>> declared. >> >> Curious. BTW have you tested with and without precompiled headers >> enabled? >> >>> >>> Please review and test this change. Comments are welcome. >> >> Typo in src/share/vm/memory/universe.cpp: preserverd >> >> src/share/vm/utilities/resourceHash.hpp: >> >> Is this recognized as a compiler bug? >> >> Thanks, >> David >> >>> Thanks and best regards, >>> Goetz. >>> > From dawid.weiss at gmail.com Thu Aug 15 23:45:21 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Fri, 16 Aug 2013 08:45:21 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: <520D25EB.7030005@oracle.com> References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> Message-ID: > It is with high probability Compiler problem. I believe so. I've re-run the tests with 1.8b102 and the problem is still there, although it's more difficult to show -- I ran a 100 full builds yesterday, five of them tripped on assertions that should be unreachable. > G1 has larger write-barrier code then other GCs. It can affect inlining > decisions. You can try to change -XX:InlineSmallCode=1000 value. It controls > inlining of methods which were already compiled. > > You can also try -Xbatch -XX:CICompilerCount=1 to get serial compilations. Thanks for these tips, Vladimir -- very helpful. I hope you don't mind me asking one more question - we had a discussion with another Lucene developer yesterday -- is -Xbatch deterministic in the sense that if you run a single thread/ deterministic piece of code it will always trigger compiles at the same time? What happens if there are two uncoordinated threads that hit a set of the same methods (and thus when the compiler kicks in the statistics will probably be different for each independent run)? This question originated from a broader discussion where we were wondering how you, the compiler-guru guys approach the debugging in case something like this pops up -- a bug that is very hard to reproduce, that manifests itself rarely and for which pretty much any change at the Java level changes the compilation and thus generates completely different code. This seems to be a tough nut to crack. Dawid From vladimir.kozlov at oracle.com Fri Aug 16 00:50:25 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Aug 2013 00:50:25 -0700 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> Message-ID: <520DD9C1.1030303@oracle.com> On 8/15/13 11:45 PM, Dawid Weiss wrote: >> It is with high probability Compiler problem. > > I believe so. I've re-run the tests with 1.8b102 and the problem is > still there, although it's more difficult to show -- I ran a 100 full > builds yesterday, five of them tripped on assertions that should be > unreachable. We switched on -XX:+TieredCompilation by default in b102. Switch it off to use only C2 compiler which has the problem. > >> G1 has larger write-barrier code then other GCs. It can affect inlining >> decisions. You can try to change -XX:InlineSmallCode=1000 value. It controls >> inlining of methods which were already compiled. >> >> You can also try -Xbatch -XX:CICompilerCount=1 to get serial compilations. > > Thanks for these tips, Vladimir -- very helpful. I hope you don't mind > me asking one more question - we had a discussion with another Lucene > developer yesterday -- is -Xbatch deterministic in the sense that if > you run a single thread/ deterministic piece of code it will always > trigger compiles at the same time? What happens if there are two > uncoordinated threads that hit a set of the same methods (and thus > when the compiler kicks in the statistics will probably be different > for each independent run)? -Xbatch (equivalent to -XX:-BackgroubdCompilation) will block only thread which first put compilation task on compile queue. Other threads check that the task in the queue and resume execution without waiting. You still can't get full determinism with several java threads, as you notice. But it can reduce some variations in inlining decision because compilation will be executed by one Compiler thread (instead of 2 by default). So if compilation tasks are put on queue at the same order in different runs you most likely will get the same code generation. Of cause usually the order is slightly different (especially during startup when there are a lot of compilation requests) so you can still get different results. > > This question originated from a broader discussion where we were > wondering how you, the compiler-guru guys approach the debugging in > case something like this pops up -- a bug that is very hard to > reproduce, that manifests itself rarely and for which pretty much any > change at the Java level changes the compilation and thus generates > completely different code. This seems to be a tough nut to crack. We usually try to reproduce the problem with debug version of VM which have a lot asserts and we may hit one which helps identify the problem. You are lucky if you can reproduce a problem in debug VM in debugger. We try to get assembler output of compiled method during run when it crushes. hs_err file has address and offset in compiled code and small code snippet which helps to find the code. After that we "look hard" on assembler code and try to figure out what is wrong with it and which compiler part can generate such code pattern. There is debug flag -XX:AbortVMOnException==java.lang.NullPointerException which allow to abort VM on exceptions. And with -XX:+ShowMessageBoxOnError flag we allow to attach debugger to VM when it happened. When we get only core file it is tough. We try to use Serviceability Agent to extract information and compiled code from it and other data. An other suggestion for you. Since you can avoid problem with switched off EA you can try to switch off only -XX:-OptimizePtrCompare "Use escape analysis to optimize pointers compare" -XX:-EliminateAutoBox "Control optimizations for autobox elimination" Vladimir > > Dawid > From bengt.rutisson at oracle.com Fri Aug 16 03:14:38 2013 From: bengt.rutisson at oracle.com (bengt.rutisson at oracle.com) Date: Fri, 16 Aug 2013 10:14:38 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8 new changesets Message-ID: <20130816101457.8BA9948929@hg.openjdk.java.net> Changeset: 9766f73e770d Author: stefank Date: 2013-05-31 14:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9766f73e770d 8022880: False sharing between PSPromotionManager instances Summary: Pad the PSPromotionManager instances in the manager array. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp + src/share/vm/memory/padded.hpp + src/share/vm/memory/padded.inline.hpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 330dfb0476f4 Author: brutisso Date: 2013-08-14 09:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/330dfb0476f4 8022800: Use specific generations rather than generation iteration Reviewed-by: jmasa, ehelin ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genRemSet.hpp Changeset: 3f22cbf5275d Author: brutisso Date: 2013-08-14 10:55 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3f22cbf5275d Merge Changeset: 5d9995d16b26 Author: ehelin Date: 2013-08-14 13:49 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5d9995d16b26 8022899: SunStudio compiler can not handle EXCEPTION_MARK and inlining Reviewed-by: coleenp, mgerdin ! src/share/vm/utilities/exceptions.hpp Changeset: bd902affe102 Author: brutisso Date: 2013-08-15 10:05 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/bd902affe102 8023021: Unnecessary clearing of the card table introduced by the fix for JDK-8023013 Reviewed-by: stefank, ehelin ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genRemSet.hpp Changeset: 274ce305e5b9 Author: ehelin Date: 2013-08-13 18:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/274ce305e5b9 8020598: ObjectCountEventSender::send needs INCLUDE_TRACE guards when building OpenJDK with INCLUDE_TRACE=0 Reviewed-by: stefank, brutisso, sjohanss ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp Changeset: 33d39b75663f Author: ehelin Date: 2013-08-15 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/33d39b75663f Merge Changeset: 5a62937e55b3 Author: brutisso Date: 2013-08-16 09:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5a62937e55b3 Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad From goetz.lindenmaier at sap.com Fri Aug 16 04:14:10 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 16 Aug 2013 11:14:10 +0000 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <520DC62F.809@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520D76D3.7000605@oracle.com> <520DBFA1.2060606@oracle.com> <520DC62F.809@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D014C9C@DEWDFEMB12A.global.corp.sap> Hi David, I share your irritation about the long include chains, but didn't like includeDB too much either. Worst are os_cpu includes, and we have 5 additional platforms :( I would prefer most if the platform file names would not include the platform, but os|cpu|os_cpu. The path is sufficient to differentiate them. Then all could be configured by the search paths of the compiler. It might lead to confusion with the editors (both, tools and people), though. As the most realistic approach I would also see dispatch files. In many cases, there is anyways a shared file named similarly. assembler_ is a good example how to do it, I think. By the way, I added aix before bsd, after linux,solaris,windows. I think a complete alphabetic ordering would be better. If this is consent, I'll do the editing. Best regards, Goetz. -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Friday, August 16, 2013 8:27 AM To: Stefan Karlsson Cc: Lindenmaier, Goetz; 'Vladimir Kozlov'; ppc-aix-port-dev at openjdk.java.net; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX Stefan, Let's start a new thread on this :) David On 16/08/2013 3:58 PM, Stefan Karlsson wrote: > On 8/16/13 2:48 AM, David Holmes wrote: >> Hi Goetz, >> >> On 15/08/2013 10:10 PM, Lindenmaier, Goetz wrote: >>> I prepared a webrev for >>> 8023033: PPC64 (part 13): basic changes for AIX >>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >>> >>> This contains the basic shared changes needed for the AIX port, >>> as there are >>> - #includes >> >> Aside: Seeing this I'm now firmly convinced that the platform-include >> mechanism is worse than the old includeDB mechanism that it replaced. >> We really need a way to #include these based on the value of the >> platform variable :( > > Dave, > > You were always firmly convinced of that. :) > > Do you have a solution to the platform include problem that doesn't > involve listing _all_ includes in separate list files? > > In the short term, we could at least hide os_<>.inline.hpp in a dispatch > file. Just like we did for: > 8003935: Simplify the needed includes for using Thread::current() > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3852 > > Here's a list of the added includes from the AIX patch: > 18 +# include "os_aix.inline.hpp" > 4 +# include "orderAccess_aix_ppc.inline.hpp" > 3 +# include "jvm_aix.h" > 2 +# include "c2_globals_aix.hpp" > 2 +# include "c1_globals_aix.hpp" > 1 +# include "vmStructs_aix_ppc.hpp" > 1 +# include "utilities/globalDefinitions_xlc.hpp" > 1 +# include "thread_aix_ppc.hpp" > 1 +# include "thread_aix.inline.hpp" > 1 +# include "threadLS_aix_ppc.hpp" > 1 +# include "os_aix_ppc.hpp" > 1 +# include "os_aix.hpp" > 1 +# include "osThread_aix.hpp" > 1 +# include "interfaceSupport_aix.hpp" > 1 +# include "globals_aix_ppc.hpp" > 1 +# include "globals_aix.hpp" > 1 +# include "c2_globals_ppc.hpp" > 1 +# include "atomic_aix_ppc.inline.hpp" > > StefanK > >> >>> - Fixes to get the code compiling with xlC/on AIX >> >> Are there makefile changes for xlC support as well? >> >>> - Basic adaptions as in vm_version.cpp. >>> >>> It also determines the placement and naming of the aix files, >>> which will go to os/aix and os_cpu/aix_ppc, as you can see in >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >>> >>> >>> Some details about the compilation problems: >>> >>> relocInfo.hpp: >>> xlC wants initialization in inline implementation. >>> >>> vmreg.hpp: >>> BAD is defined in AIX system header sys/param.h. Renamed. >>> >>> allocation.hpp >>> xlC complains: >>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" >>> member "StackObj::operator delete(void *)" cannot be accessed. >> >> Hmmm. So the whole point of these being private was so that they could >> not be called but we had to override the use of the global operators. >> The concrete implementations then give fatal errors if you do manage >> to use them (impossible?). So making them public is undesirable. >> >> Is there some other way to resolve this? A pragma to tell xlC to >> ignore the perceived problem? >> >>> sharedRuntimeTrig.cpp >>> Aix defines hz to be 100, see sys/m_param.h. Renamed. >> >> It #defines a lowercase constant! Ouch! :) >> >>> debug.hpp >>> With other include order we get a lot of >>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not >>> declared. >> >> Curious. BTW have you tested with and without precompiled headers >> enabled? >> >>> >>> Please review and test this change. Comments are welcome. >> >> Typo in src/share/vm/memory/universe.cpp: preserverd >> >> src/share/vm/utilities/resourceHash.hpp: >> >> Is this recognized as a compiler bug? >> >> Thanks, >> David >> >>> Thanks and best regards, >>> Goetz. >>> > From goetz.lindenmaier at sap.com Fri Aug 16 05:21:13 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 16 Aug 2013 12:21:13 +0000 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <520DB6B7.2050901@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> <520D6EEE.1040906@oracle.com> <520DB6B7.2050901@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D015CCA@DEWDFEMB12A.global.corp.sap> Hi, - I removed the throw() - I removed the #ifndef in port.hpp - I fixed the typeo. http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-2/ I always build without precompiled headers, the nightbuild with them. Yes, there will be makefiles for aix, and the platform files. tTe prototype patches are here http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0014_aix_make_changes.patch http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0015_aix_ppc_files.patch But the make change contains mostly new files, except for --- a/make/defs.make Tue Jul 23 21:07:11 2013 +0200 +++ b/make/defs.make Tue Jul 23 22:13:05 2013 +0200 @@ -166,11 +166,15 @@ HOST := $(shell uname -n) endif -# If not SunOS, not Linux and not BSD, assume Windows +# If not SunOS, not Linux not BSD and not AIX, assume Windows ifneq ($(OS), Linux) ifneq ($(OS), SunOS) ifneq ($(OS), bsd) - OSNAME=windows + ifneq ($(OS), AIX) + OSNAME=windows + else + OSNAME=aix + endif else OSNAME=bsd endif Best regards, Goetz -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, August 16, 2013 7:21 AM To: David Holmes Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX I thought trow() was added long time ago. But it was added, I think by accident, very recently: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a7fb14888912 I missed it when I did the review of those changes. We should remove throw. Vladimir On 8/15/13 5:14 PM, David Holmes wrote: > On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: >> On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: >>> Hi Vladimir, >>> >>> throw is needed because it`s there in the implementation in nmethod.cpp. >>> (So you are using it a bit at least :)) >>> xlc says >>> "nmethod.cpp", line 802.7: 1540-0400 (S) "nmethod::operator >>> new(size_t, int)" has a conflicting declaration. >>> "nmethod.hpp", line 268.9: 1540-0424 (I) "operator new" is declared on >>> line 268 of "nmethod.hpp". >> >> Okay, it is just declaration. > > Why do we have throw here: > > void* nmethod::operator new(size_t size, int nmethod_size) throw () { > // Not critical, may return null if there is too little continuous memory > return CodeCache::allocate(nmethod_size); > } > > Seems to me it should be removed if anything. > > David > ----- > >> >>> >>> int64 is defined correctly, uint64 is not defined, but never used in >>> hotspot. >>> I can not reproduce an error, but that's rather old coding from our VM. >>> We also switched from xlc8 to xlc10 in the course of this project. >>> I will test some more and talk to the person who implemented that >>> tomorrow, >>> and if possible remove the change. >> >> Okay, I will test it also. >> >> Vladimir >> >>> >>> Best regards & thanks for the review, >>> Goetz. >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Thursday, August 15, 2013 5:52 PM >>> To: Lindenmaier, Goetz >>> Cc: 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net; >>> Albert Noll (albert.noll at oracle.com) >>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX >>> >>> Goetz, >>> >>> I only see 2 problems which you did not explain: >>> >>> nmethod.hpp. Why the next change? we don't use C++ exceptions: >>> >>> - void* operator new(size_t size, int nmethod_size); >>> + void* operator new(size_t size, int nmethod_size) throw (); >>> >>> port.hpp. Did AIX has the same definitions for jlong and julong?: >>> >>> +#ifndef _AIX >>> +// These conflict with /usr/include/sys/inttypes.h on aix. >>> typedef jlong int64; // Java long for my 64-bit type >>> typedef julong uint64; // Java long for my 64-bit type >>> +#endif >>> >>> >>> And of cause we need to test these changes with compilers we use. >>> >>> Thanks, >>> Vladimir >>> >>> On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I prepared a webrev for >>>> 8023033: PPC64 (part 13): basic changes for AIX >>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >>>> >>>> This contains the basic shared changes needed for the AIX port, >>>> as there are >>>> - #includes >>>> - Fixes to get the code compiling with xlC/on AIX >>>> - Basic adaptions as in vm_version.cpp. >>>> >>>> It also determines the placement and naming of the aix files, >>>> which will go to os/aix and os_cpu/aix_ppc, as you can see in >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >>>> >>>> >>>> Some details about the compilation problems: >>>> >>>> relocInfo.hpp: >>>> xlC wants initialization in inline implementation. >>>> >>>> vmreg.hpp: >>>> BAD is defined in AIX system header sys/param.h. Renamed. >>>> >>>> allocation.hpp >>>> xlC complains: >>>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" >>>> member "StackObj::operator delete(void *)" cannot be accessed. >>>> >>>> sharedRuntimeTrig.cpp >>>> Aix defines hz to be 100, see sys/m_param.h. Renamed. >>>> >>>> debug.hpp >>>> With other include order we get a lot of >>>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not >>>> declared. >>>> >>>> >>>> Please review and test this change. Comments are welcome. >>>> >>>> Thanks and best regards, >>>> Goetz. >>>> From stefan.karlsson at oracle.com Fri Aug 16 06:09:03 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 16 Aug 2013 15:09:03 +0200 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D015CCA@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> <520D6EEE.1040906@oracle.com> <520DB6B7.2050901@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015CCA@DEWDFEMB12A.global.corp.sap> Message-ID: <520E246F.1060704@oracle.com> Hi Goetz, On 8/16/13 2:21 PM, Lindenmaier, Goetz wrote: > Hi, > > - I removed the throw() > - I removed the #ifndef in port.hpp > - I fixed the typeo. > http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-2/ > > I always build without precompiled headers, the nightbuild with > them. utilities/debug.hpp.udiff.html -#include "prims/jvm.h" #include "utilities/globalDefinitions.hpp" +#include "prims/jvm.h" I don't think your change to debug.hpp is the correct way to solve the problems you were seeing with metaspace.hpp. Swapping the files just means that someone else might hit the same problem adding prims/jvm.hpp to another file. You probably have a circular include dependency somewhere in the code. Could you revert the change to utilities/debug.hpp and try to figure out what the real problem is? thanks, StefanK > > Yes, there will be makefiles for aix, and the platform files. tTe prototype > patches are here > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0014_aix_make_changes.patch > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0015_aix_ppc_files.patch > > But the make change contains mostly new files, except for > > --- a/make/defs.make Tue Jul 23 21:07:11 2013 +0200 > +++ b/make/defs.make Tue Jul 23 22:13:05 2013 +0200 > @@ -166,11 +166,15 @@ > HOST := $(shell uname -n) > endif > > -# If not SunOS, not Linux and not BSD, assume Windows > +# If not SunOS, not Linux not BSD and not AIX, assume Windows > ifneq ($(OS), Linux) > ifneq ($(OS), SunOS) > ifneq ($(OS), bsd) > - OSNAME=windows > + ifneq ($(OS), AIX) > + OSNAME=windows > + else > + OSNAME=aix > + endif > else > OSNAME=bsd > endif > > > Best regards, > Goetz > > > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Friday, August 16, 2013 7:21 AM > To: David Holmes > Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX > > I thought trow() was added long time ago. But it was added, I think by accident, very recently: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a7fb14888912 > > I missed it when I did the review of those changes. > > We should remove throw. > > Vladimir > > On 8/15/13 5:14 PM, David Holmes wrote: >> On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: >>> On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: >>>> Hi Vladimir, >>>> >>>> throw is needed because it`s there in the implementation in nmethod.cpp. >>>> (So you are using it a bit at least :)) >>>> xlc says >>>> "nmethod.cpp", line 802.7: 1540-0400 (S) "nmethod::operator >>>> new(size_t, int)" has a conflicting declaration. >>>> "nmethod.hpp", line 268.9: 1540-0424 (I) "operator new" is declared on >>>> line 268 of "nmethod.hpp". >>> Okay, it is just declaration. >> Why do we have throw here: >> >> void* nmethod::operator new(size_t size, int nmethod_size) throw () { >> // Not critical, may return null if there is too little continuous memory >> return CodeCache::allocate(nmethod_size); >> } >> >> Seems to me it should be removed if anything. >> >> David >> ----- >> >>>> int64 is defined correctly, uint64 is not defined, but never used in >>>> hotspot. >>>> I can not reproduce an error, but that's rather old coding from our VM. >>>> We also switched from xlc8 to xlc10 in the course of this project. >>>> I will test some more and talk to the person who implemented that >>>> tomorrow, >>>> and if possible remove the change. >>> Okay, I will test it also. >>> >>> Vladimir >>> >>>> Best regards & thanks for the review, >>>> Goetz. >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Thursday, August 15, 2013 5:52 PM >>>> To: Lindenmaier, Goetz >>>> Cc: 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net; >>>> Albert Noll (albert.noll at oracle.com) >>>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX >>>> >>>> Goetz, >>>> >>>> I only see 2 problems which you did not explain: >>>> >>>> nmethod.hpp. Why the next change? we don't use C++ exceptions: >>>> >>>> - void* operator new(size_t size, int nmethod_size); >>>> + void* operator new(size_t size, int nmethod_size) throw (); >>>> >>>> port.hpp. Did AIX has the same definitions for jlong and julong?: >>>> >>>> +#ifndef _AIX >>>> +// These conflict with /usr/include/sys/inttypes.h on aix. >>>> typedef jlong int64; // Java long for my 64-bit type >>>> typedef julong uint64; // Java long for my 64-bit type >>>> +#endif >>>> >>>> >>>> And of cause we need to test these changes with compilers we use. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> I prepared a webrev for >>>>> 8023033: PPC64 (part 13): basic changes for AIX >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >>>>> >>>>> This contains the basic shared changes needed for the AIX port, >>>>> as there are >>>>> - #includes >>>>> - Fixes to get the code compiling with xlC/on AIX >>>>> - Basic adaptions as in vm_version.cpp. >>>>> >>>>> It also determines the placement and naming of the aix files, >>>>> which will go to os/aix and os_cpu/aix_ppc, as you can see in >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >>>>> >>>>> >>>>> Some details about the compilation problems: >>>>> >>>>> relocInfo.hpp: >>>>> xlC wants initialization in inline implementation. >>>>> >>>>> vmreg.hpp: >>>>> BAD is defined in AIX system header sys/param.h. Renamed. >>>>> >>>>> allocation.hpp >>>>> xlC complains: >>>>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" >>>>> member "StackObj::operator delete(void *)" cannot be accessed. >>>>> >>>>> sharedRuntimeTrig.cpp >>>>> Aix defines hz to be 100, see sys/m_param.h. Renamed. >>>>> >>>>> debug.hpp >>>>> With other include order we get a lot of >>>>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not >>>>> declared. >>>>> >>>>> >>>>> Please review and test this change. Comments are welcome. >>>>> >>>>> Thanks and best regards, >>>>> Goetz. >>>>> From coleen.phillimore at oracle.com Fri Aug 16 07:18:56 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 16 Aug 2013 10:18:56 -0400 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <520DBFA1.2060606@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520D76D3.7000605@oracle.com> <520DBFA1.2060606@oracle.com> Message-ID: <520E34D0.4030104@oracle.com> I was going to say the same thing as StefanK. We were also planning to clean out some of the os/cpu/platform dependent includes so that they didn't leak out to shared code. Removing includeDB enabled that. Coleen On 8/16/2013 1:58 AM, Stefan Karlsson wrote: > On 8/16/13 2:48 AM, David Holmes wrote: >> Hi Goetz, >> >> On 15/08/2013 10:10 PM, Lindenmaier, Goetz wrote: >>> I prepared a webrev for >>> 8023033: PPC64 (part 13): basic changes for AIX >>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >>> >>> This contains the basic shared changes needed for the AIX port, >>> as there are >>> - #includes >> >> Aside: Seeing this I'm now firmly convinced that the platform-include >> mechanism is worse than the old includeDB mechanism that it replaced. >> We really need a way to #include these based on the value of the >> platform variable :( > > Dave, > > You were always firmly convinced of that. :) > > Do you have a solution to the platform include problem that doesn't > involve listing _all_ includes in separate list files? > > In the short term, we could at least hide os_<>.inline.hpp in a > dispatch file. Just like we did for: > 8003935: Simplify the needed includes for using Thread::current() > http://hg.openjdk.java.net/hsx/hotspot-gc/hotspot/rev/3852 > > Here's a list of the added includes from the AIX patch: > 18 +# include "os_aix.inline.hpp" > 4 +# include "orderAccess_aix_ppc.inline.hpp" > 3 +# include "jvm_aix.h" > 2 +# include "c2_globals_aix.hpp" > 2 +# include "c1_globals_aix.hpp" > 1 +# include "vmStructs_aix_ppc.hpp" > 1 +# include "utilities/globalDefinitions_xlc.hpp" > 1 +# include "thread_aix_ppc.hpp" > 1 +# include "thread_aix.inline.hpp" > 1 +# include "threadLS_aix_ppc.hpp" > 1 +# include "os_aix_ppc.hpp" > 1 +# include "os_aix.hpp" > 1 +# include "osThread_aix.hpp" > 1 +# include "interfaceSupport_aix.hpp" > 1 +# include "globals_aix_ppc.hpp" > 1 +# include "globals_aix.hpp" > 1 +# include "c2_globals_ppc.hpp" > 1 +# include "atomic_aix_ppc.inline.hpp" > > StefanK > >> >>> - Fixes to get the code compiling with xlC/on AIX >> >> Are there makefile changes for xlC support as well? >> >>> - Basic adaptions as in vm_version.cpp. >>> >>> It also determines the placement and naming of the aix files, >>> which will go to os/aix and os_cpu/aix_ppc, as you can see in >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >>> >>> >>> Some details about the compilation problems: >>> >>> relocInfo.hpp: >>> xlC wants initialization in inline implementation. >>> >>> vmreg.hpp: >>> BAD is defined in AIX system header sys/param.h. Renamed. >>> >>> allocation.hpp >>> xlC complains: >>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" >>> member "StackObj::operator delete(void *)" cannot be accessed. >> >> Hmmm. So the whole point of these being private was so that they >> could not be called but we had to override the use of the global >> operators. The concrete implementations then give fatal errors if you >> do manage to use them (impossible?). So making them public is >> undesirable. >> >> Is there some other way to resolve this? A pragma to tell xlC to >> ignore the perceived problem? >> >>> sharedRuntimeTrig.cpp >>> Aix defines hz to be 100, see sys/m_param.h. Renamed. >> >> It #defines a lowercase constant! Ouch! :) >> >>> debug.hpp >>> With other include order we get a lot of >>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not >>> declared. >> >> Curious. BTW have you tested with and without precompiled headers >> enabled? >> >>> >>> Please review and test this change. Comments are welcome. >> >> Typo in src/share/vm/memory/universe.cpp: preserverd >> >> src/share/vm/utilities/resourceHash.hpp: >> >> Is this recognized as a compiler bug? >> >> Thanks, >> David >> >>> Thanks and best regards, >>> Goetz. >>> > From alejandro.murillo at oracle.com Fri Aug 16 07:57:10 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 16 Aug 2013 14:57:10 +0000 Subject: hg: hsx/hsx25/hotspot: 31 new changesets Message-ID: <20130816145816.9F34F48939@hg.openjdk.java.net> Changeset: 0bbd1c775bef Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/0bbd1c775bef Added tag jdk8-b103 for changeset 6f9be7f87b96 ! .hgtags Changeset: 39127bb12d32 Author: amurillo Date: 2013-08-09 01:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/39127bb12d32 8022688: new hotspot build - hs25-b46 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ca0165daa6ec Author: sspitsyn Date: 2013-08-06 16:33 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ca0165daa6ec 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments Summary: Restore the appendix argument after PopFrame() call Reviewed-by: twisti, coleenp Contributed-by: serguei.spitsyn at oracle.com ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: c54a3122f9c8 Author: omajid Date: 2013-08-06 12:28 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c54a3122f9c8 8022188: Make zero compile after 8016131 and 8016697 Reviewed-by: dholmes, twisti ! src/cpu/zero/vm/entryFrame_zero.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp Changeset: 196aa14f9f29 Author: dholmes Date: 2013-08-06 21:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/196aa14f9f29 Merge Changeset: 195ff07bc7f6 Author: dsamersoff Date: 2013-08-07 19:02 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/195ff07bc7f6 8021771: warning stat64 is deprecated - when building on OSX 10.7.5 Summary: stat64 have to be replaced with stat Reviewed-by: dholmes, kmo Contributed-by: rednaxelafx at gmail.com ! src/os/bsd/vm/attachListener_bsd.cpp Changeset: 31f3b1e1c5e5 Author: dcubed Date: 2013-08-08 09:21 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/31f3b1e1c5e5 8016601: Unable to build hsx24 on Windows using project creator and Visual Studio Summary: ProjectCreator tool is modified to support two new options: '-relativeAltSrcInclude' and '-altRelativeInclude' which prevents IDE linker errors. Also fixed some cmd line build linker warnings. Misc cleanups. Reviewed-by: rdurbin, coleenp ! make/windows/create.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/trace.make ! make/windows/makefiles/vm.make ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java Changeset: c661fa2e5189 Author: iklam Date: 2013-08-08 14:45 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c661fa2e5189 8022093: syntax error near "umpiconninfo_t" -- when building on Solaris 10 Summary: Added extra help message in make/solaris/makefiles/dtrace.make Reviewed-by: dholmes, sspitsyn ! make/solaris/makefiles/dtrace.make Changeset: 57ac7245594c Author: minqi Date: 2013-08-08 15:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/57ac7245594c 8019583: [TESTBUG] runtime/7107135 always passes Summary: If java test return none zero, the value will be override by 'if' statement, the exit value will always '0' and pass. Fix by recording the result in a variable. Reviewed-by: coleenp, dholmes, iklam Contributed-by: yumin.qi at oracle.com ! test/runtime/7107135/Test7107135.sh Changeset: 6222a021d582 Author: minqi Date: 2013-08-08 20:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6222a021d582 Merge Changeset: 98aa538fd97e Author: mikael Date: 2013-08-09 09:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/98aa538fd97e 8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012 R2 Summary: Add support for recognizing Windows 8.1 and Server 2012 R2 and minor cleanup Reviewed-by: coleenp, dsamersoff ! src/os/windows/vm/os_windows.cpp Changeset: ed7c17e7d45b Author: dcubed Date: 2013-08-09 13:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ed7c17e7d45b Merge Changeset: 7b03590c334b Author: dcubed Date: 2013-08-09 15:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7b03590c334b Merge Changeset: bd0e82136b03 Author: iklam Date: 2013-08-10 10:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bd0e82136b03 8022740: Visual 2008 IDE build is broken Summary: Fixed project generation code, and added warning to upgrade to VS 2008 SP1. Reviewed-by: dcubed, ccheung ! make/windows/projectfiles/common/Makefile ! src/share/tools/ProjectCreator/FileTreeCreator.java ! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java ! src/share/tools/ProjectCreator/FileTreeCreatorVC7.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java Changeset: 85147f28faba Author: coleenp Date: 2013-08-12 17:24 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/85147f28faba 8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32 Summary: ActiveMethodOopsCache was used to keep track of old versions of some methods that are cached in Universe but is buggy with permgen removal and not needed anymore Reviewed-by: sspitsyn, dcubed, mseledtsov ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! test/runtime/RedefineObject/Agent.java ! test/runtime/RedefineObject/TestRedefineObject.java + test/runtime/RedefineObject/WalkThroughInvoke.java Changeset: d1034bd8cefc Author: adlertz Date: 2013-08-07 17:56 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d1034bd8cefc 8022284: Hide internal data structure in PhaseCFG Summary: Hide private node to block mapping using public interface Reviewed-by: kvn, roland ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ce8969c36762 Author: adlertz Date: 2013-08-07 18:04 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ce8969c36762 8022475: Remove unneeded ad-files Summary: Remove .ad files that are not used Reviewed-by: kvn ! make/bsd/makefiles/adlc.make ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! make/windows/makefiles/adlc.make - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 5394ec69f112 Author: rbackman Date: 2013-08-09 18:05 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5394ec69f112 Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 11237ee74aae Author: iignatyev Date: 2013-08-10 10:01 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/11237ee74aae 8019915: whitebox testClearMethodStateTest fails with tiered on sparc Summary: 'compileonly' directive has beens added to each 'compiler/whitebox' test Reviewed-by: kvn ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/compiler/whitebox/SetForceInlineMethodTest.java Changeset: bcc4f6f54d83 Author: kvn Date: 2013-08-14 10:21 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bcc4f6f54d83 8022993: Convert MAX_UNROLL constant to LoopMaxUnroll C2 flag Summary: Replace MAX_UNROLL constant with new C2 LoopMaxUnroll flag. Reviewed-by: roland ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/loopTransform.cpp Changeset: 56b94e55267a Author: rbackman Date: 2013-08-15 15:26 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/56b94e55267a Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 9766f73e770d Author: stefank Date: 2013-05-31 14:32 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9766f73e770d 8022880: False sharing between PSPromotionManager instances Summary: Pad the PSPromotionManager instances in the manager array. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp + src/share/vm/memory/padded.hpp + src/share/vm/memory/padded.inline.hpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 330dfb0476f4 Author: brutisso Date: 2013-08-14 09:02 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/330dfb0476f4 8022800: Use specific generations rather than generation iteration Reviewed-by: jmasa, ehelin ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genRemSet.hpp Changeset: 3f22cbf5275d Author: brutisso Date: 2013-08-14 10:55 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3f22cbf5275d Merge Changeset: 5d9995d16b26 Author: ehelin Date: 2013-08-14 13:49 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5d9995d16b26 8022899: SunStudio compiler can not handle EXCEPTION_MARK and inlining Reviewed-by: coleenp, mgerdin ! src/share/vm/utilities/exceptions.hpp Changeset: bd902affe102 Author: brutisso Date: 2013-08-15 10:05 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/bd902affe102 8023021: Unnecessary clearing of the card table introduced by the fix for JDK-8023013 Reviewed-by: stefank, ehelin ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genRemSet.hpp Changeset: 274ce305e5b9 Author: ehelin Date: 2013-08-13 18:16 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/274ce305e5b9 8020598: ObjectCountEventSender::send needs INCLUDE_TRACE guards when building OpenJDK with INCLUDE_TRACE=0 Reviewed-by: stefank, brutisso, sjohanss ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp Changeset: 33d39b75663f Author: ehelin Date: 2013-08-15 06:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/33d39b75663f Merge Changeset: 5a62937e55b3 Author: brutisso Date: 2013-08-16 09:02 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5a62937e55b3 Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 580430d131cc Author: amurillo Date: 2013-08-16 04:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/580430d131cc Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 104743074675 Author: amurillo Date: 2013-08-16 04:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/104743074675 Added tag hs25-b46 for changeset 580430d131cc ! .hgtags From vladimir.kozlov at oracle.com Fri Aug 16 09:54:42 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Aug 2013 09:54:42 -0700 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D011357@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> <57C1A33A-2D35-4745-977A-84C786AA87A6@oracle.com> <4295855A5C1DE049A61835A1887419CC0D011357@DEWDFEMB12A.global.corp.sap> Message-ID: <520E5952.9070708@oracle.com> It would be nice if you can produce the same alignment in output: SIGSEGV: [libjvm.so+0xc03f0d], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO SIGBUS: [libjvm.so+0xc03f0d], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO SIGFPE: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO SIGPIPE: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO Vladimir On 8/14/13 1:08 AM, Lindenmaier, Goetz wrote: > Hi, > > Sorry for the long delay, I had off some time. > > For an examle output I forced a SIGSEGV in chaitin. > > In hs_err you get for STEP 90: > > new: siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000018 > old: siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000018 > > si_errno is skipped in the new output, as it's 0. > > STEP 255: > > new: > Signal Handlers: > SIGSEGV: [libjvm.so+0xc03f0d], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGBUS: [libjvm.so+0xc03f0d], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGFPE: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGPIPE: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGXFSZ: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGILL: [libjvm.so+0xa54a30], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGUSR1: SIG_DFL, sa_mask[0]=0, sa_flags=none > SIGUSR2: [libjvm.so+0xa57167], sa_mask[0]=0, sa_flags=SA_RESTART|SA_SIGINFO > SIGHUP: [libjvm.so+0xa593d5], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGINT: [libjvm.so+0xa593d5], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGTERM: [libjvm.so+0xa593d5], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > SIGQUIT: [libjvm.so+0xa593d5], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > > old: > Signal Handlers: > SIGSEGV: [libjvm.so+0xc0450d], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGBUS: [libjvm.so+0xc0450d], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGFPE: [libjvm.so+0xa54cf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGPIPE: [libjvm.so+0xa54cf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGXFSZ: [libjvm.so+0xa54cf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGILL: [libjvm.so+0xa54cf0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 > SIGUSR2: [libjvm.so+0xa57427], sa_mask[0]=0x00000000, sa_flags=0x10000004 > SIGHUP: [libjvm.so+0xa599d7], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGINT: [libjvm.so+0xa599d7], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGTERM: [libjvm.so+0xa599d7], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > SIGQUIT: [libjvm.so+0xa599d7], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 > > I'll include a link to an old and new hs_err file in the next webrev I'll make. > > Best regards, > Goetz. > > -----Original Message----- > From: Christian Thalinger [mailto:christian.thalinger at oracle.com] > Sent: Freitag, 26. Juli 2013 18:21 > To: Lindenmaier, Goetz > Cc: 'hotspot-dev at openjdk.java.net'; 'ppc-aix-port-dev at openjdk.java.net'; 'Vladimir Kozlov' > Subject: Re: RFR(M): 8020775: PPC64 (part 12): posix signal printing > > Could you paste an example output? > > -- Chris > > On Jul 25, 2013, at 4:11 PM, "Lindenmaier, Goetz" wrote: > >> Hi, >> >> we'd like to contribute our posix signal printing. >> We implemented some routines to print signal and sa_flags information >> in the os/posix files, and call them from >> os::print_siginfo and print_signal_handler() in the various unix >> variant directories. >> The output is a bit more verbose than the existing version. >> >> We contribute this here, as our aix code uses this too. >> >> Please review this and test it if you think we should add this. >> We'd appreciate it. >> http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ >> >> Thanks and best regards, >> Goetz. > From vladimir.kozlov at oracle.com Fri Aug 16 10:12:08 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Aug 2013 10:12:08 -0700 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <51F5D77B.6040009@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> <51F5D77B.6040009@oracle.com> Message-ID: <520E5D68.3000202@oracle.com> David, On 7/28/13 7:46 PM, David Holmes wrote: > On 26/07/2013 9:11 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> we'd like to contribute our posix signal printing. > > This really isn't "posix signals" as it combines all the OS specific > signal definitions into one chunk of code. Currently it is the only place in our sources where we can combine code for all unix variations. > > + // A number high enough to contain all possible signal numbers. > + #define MAX_SIGNAL_NUMBER 70 > > Why do you need this when you use sigaddset to check validity anyway? > What is this "maximum signal number" meant to represent anyway? The > maximum signal number on the platform, or the maximum signal number for > a signal that the JVM will install a handler for? > > The runtime team will need to take a good look at this. Personally I'd > rather not see all the different OS stuff piled in together. I'd > certainly like to see as little duplication as possible, but I'd rather > platform specific stuff was dealt with in platform specific files. It is just printing unification to avoid a lot of duplication. I agree that methods is_valid_signal() could stay in platform specific files. But to have the rest, signals names and print methods, in one place I think is good. Regards, Vladimir > > David > ----- > >> We implemented some routines to print signal and sa_flags information >> in the os/posix files, and call them from >> os::print_siginfo and print_signal_handler() in the various unix >> variant directories. >> The output is a bit more verbose than the existing version. >> >> We contribute this here, as our aix code uses this too. > > > >> Please review this and test it if you think we should add this. >> We'd appreciate it. >> http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ >> >> Thanks and best regards, >> Goetz. >> From coleen.phillimore at oracle.com Fri Aug 16 10:47:20 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 16 Aug 2013 13:47:20 -0400 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <520E5D68.3000202@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> <51F5D77B.6040009@oracle.com> <520E5D68.3000202@oracle.com> Message-ID: <520E65A8.1090803@oracle.com> On 8/16/2013 1:12 PM, Vladimir Kozlov wrote: > David, > > On 7/28/13 7:46 PM, David Holmes wrote: >> On 26/07/2013 9:11 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> we'd like to contribute our posix signal printing. >> >> This really isn't "posix signals" as it combines all the OS specific >> signal definitions into one chunk of code. > > Currently it is the only place in our sources where we can combine > code for all unix variations. Yes, we're renaming "posix" to "xnix", so it's good to not duplicate the code in all the unix variations with this change, just because it's not "posix". Coleen > >> >> + // A number high enough to contain all possible signal numbers. >> + #define MAX_SIGNAL_NUMBER 70 >> >> Why do you need this when you use sigaddset to check validity anyway? >> What is this "maximum signal number" meant to represent anyway? The >> maximum signal number on the platform, or the maximum signal number for >> a signal that the JVM will install a handler for? >> >> The runtime team will need to take a good look at this. Personally I'd >> rather not see all the different OS stuff piled in together. I'd >> certainly like to see as little duplication as possible, but I'd rather >> platform specific stuff was dealt with in platform specific files. > > It is just printing unification to avoid a lot of duplication. > I agree that methods is_valid_signal() could stay in platform specific > files. But to have the rest, signals names and print methods, in one > place I think is good. > > Regards, > Vladimir > >> >> David >> ----- >> >>> We implemented some routines to print signal and sa_flags information >>> in the os/posix files, and call them from >>> os::print_siginfo and print_signal_handler() in the various unix >>> variant directories. >>> The output is a bit more verbose than the existing version. >>> >>> We contribute this here, as our aix code uses this too. >> >> >> >>> Please review this and test it if you think we should add this. >>> We'd appreciate it. >>> http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ >>> >>> Thanks and best regards, >>> Goetz. >>> From vladimir.kozlov at oracle.com Fri Aug 16 11:13:58 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 16 Aug 2013 11:13:58 -0700 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D011426@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> <51F2C9D1.60907@oracle.com> <4295855A5C1DE049A61835A1887419CC0D011426@DEWDFEMB12A.global.corp.sap> Message-ID: <520E6BE6.70904@oracle.com> Hi, Goetz On 8/14/13 6:02 AM, Lindenmaier, Goetz wrote: > Hi, > >> I think it is good cleanup. Thank you, Goetz. > Thanks! Merits go to Thomas Stuefe who initially redesigned this. > I added him as contributor. > > http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig-2/ > > In general: The 'describe' functions compute the string containing > the desired information. The 'print' functions decide how to > publish this information. It's just a separation of concern. We even > test them separately. > We have a row of additional signal printing routines that are not > 'short'. We use them to write much more information into the hs_err > file. I did not contribute them, as I assume you will not like it if the > hs_err file get's bigger. > In addition I added support for real time signals, and a workaround for redundant > SIGIOT. > >> Could you align elements/names in tables in get_signal_name() and >> get_signal_code_description() to make them aligned with each other and >> with #ifdefs? > Done, see webrev. It looks better for most of the tables, but not > for info[] in get_signal_name. I think it does not help there, I would prefer > the layout without all the white space. I like this new layout even in info[], thanks. > >> It looks like all unixes (including bsd) have NSIG value defined (I >> could be wrong). you can use it directly instead of MAX_SIGNAL_NUMBER. > There are some good reasons not to use NSIG for this constant, but > they are in the code generating more verbose output, which I did not contribute. > So I removed it. (E.g., sometimes it's a function and thus can not be used > as array size.) Okay. > >> describe_signal_set_short() method is bogus. Why you overwrite buf[0] >> with "0" or "1" and the rest of buffer with 0 each time? Should it be >> And why you need separate describe_signal_set_short() method? And why >> you need *10 for buffer size > Oh, you are right, fixed. I had to change this, as we are using fixBufferStream for I still do not get your code in describe_signal_set_short(). Why not do it like next? Note, I changed '<' to '<=' to print 32 and 31: const char* os::Posix::describe_signal_set_short(const sigset_t* set, char* buffer, size_t buf_size) { assert(buf_size = (NUM_IMPORTANT_SIGS + 1), "wrong buffer size"); // Note: for shortness, just print out the first 32. That should // cover most of the useful ones, apart from realtime signals. for (int sig = 1; sig <= NUM_IMPORTANT_SIGS; sig++) { const int rc = sigismember(set, sig); if (rc == -1 && errno == EINVAL) { buffer[sig-1] = '?'; } else { buffer[sig-1] = rc == 0 ? '0' : '1'; } } buffer[NUM_IMPORTANT_SIGS] = 0; return buffer; } > printing here. We implemented fixBufferStream in ostream.hpp extending > outputStream to print to a given, fixed buffer. > I didn't want to contribute that because it's used only here in the port. >> I would prefer to see the code similar to >> describe_sa_flags() with list of signals instead of "01". Yes, it would >> be different from current code but it would much more useful to have >> signal names. > It's the short routine, replacing an int printed in a line. Signal names > would be far too long here. I can contribute Okay, yes it would be too long. > STEP(225, "(printing signal handlers)" ) > if (_verbose) { > #ifdef _WIN32 > os::print_signal_handlers(st, buf, sizeof(buf)); > #else > os::Posix::print_current_signal_handlers(st); > #endif > st->cr(); > } > which would do what you have in mind here, I think. > >> In describe_sa_flags(): >> size_t remaining = size-1; // leave space for /0 > I think this is correct. Below we test accordingly. The code in the loop in describe_sa_flags() is incorrect because strlen(p) gives size of all stored sa names. It should be strlen(flaginfo[idx].s). I also don't see why it is while() loop and not simple for(). > >> In get_signal_code_description(): Add break: > Fixed. >> Put on different lines: >> + out->s_name = out->s_desc = "unknown"; > Fixed. > >> Why not use s_name instead of s_code to match out->s_name? > I renamed this a bit, I hope this makes it better. Good. > > If you think it's useful for OpenJDK, I can contribute the fixBufferStream > and the more verbose printing methods. Not now :) thanks, Vladimir > > Best regards, > Goetz. > > On 7/25/13 4:11 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> we'd like to contribute our posix signal printing. >> We implemented some routines to print signal and sa_flags information >> in the os/posix files, and call them from >> os::print_siginfo and print_signal_handler() in the various unix >> variant directories. >> The output is a bit more verbose than the existing version. >> >> We contribute this here, as our aix code uses this too. >> >> Please review this and test it if you think we should add this. >> We'd appreciate it. >> http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ >> >> Thanks and best regards, >> Goetz. >> From alejandro.murillo at oracle.com Fri Aug 16 13:08:18 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 16 Aug 2013 20:08:18 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130816200843.43B074894D@hg.openjdk.java.net> Changeset: 0bbd1c775bef Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/0bbd1c775bef Added tag jdk8-b103 for changeset 6f9be7f87b96 ! .hgtags Changeset: 580430d131cc Author: amurillo Date: 2013-08-16 04:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/580430d131cc Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 104743074675 Author: amurillo Date: 2013-08-16 04:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/104743074675 Added tag hs25-b46 for changeset 580430d131cc ! .hgtags Changeset: 37165c3618a3 Author: amurillo Date: 2013-08-16 04:24 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/37165c3618a3 8023152: new hotspot build - hs25-b47 Reviewed-by: jcoomes ! make/hotspot_version From goetz.lindenmaier at sap.com Fri Aug 16 14:28:05 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 16 Aug 2013 21:28:05 +0000 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <520E246F.1060704@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> <520D6EEE.1040906@oracle.com> <520DB6B7.2050901@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015CCA@DEWDFEMB12A.global.corp.sap> <520E246F.1060704@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D015DAB@DEWDFEMB12A.global.corp.sap> Hi Stefan, the problem is that globalDefinitions defines __STDC_FORMAT_MACROS. inttypes.hpp comes in through jni.hpp, which is in both, jvm.hpp and globalDefinitions.hpp through globalDefinitions_.hpp. If jvm.hpp comes first, inttype.hpp is added without the macro defined, and the print formats are missing. I could also define __STDC_FORMAT_MACROS in jni.hpp or the like. The name "globalDefinitions" somehow says that the definitions should be seen everywhere ... so it's basically bad that the file does not end up at the top of the include chain. Maybe I should include it in jni.hpp? or jvm.hpp? What do you think? Best regards, Goetz. From: Stefan Karlsson [mailto:stefan.karlsson at oracle.com] Sent: Friday, August 16, 2013 3:09 PM To: Lindenmaier, Goetz Cc: 'Vladimir Kozlov'; 'David Holmes'; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX Hi Goetz, On 8/16/13 2:21 PM, Lindenmaier, Goetz wrote: Hi, - I removed the throw() - I removed the #ifndef in port.hpp - I fixed the typeo. http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-2/ I always build without precompiled headers, the nightbuild with them. utilities/debug.hpp.udiff.html -#include "prims/jvm.h" #include "utilities/globalDefinitions.hpp" +#include "prims/jvm.h" I don't think your change to debug.hpp is the correct way to solve the problems you were seeing with metaspace.hpp. Swapping the files just means that someone else might hit the same problem adding prims/jvm.hpp to another file. You probably have a circular include dependency somewhere in the code. Could you revert the change to utilities/debug.hpp and try to figure out what the real problem is? thanks, StefanK Yes, there will be makefiles for aix, and the platform files. tTe prototype patches are here http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0014_aix_make_changes.patch http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0015_aix_ppc_files.patch But the make change contains mostly new files, except for --- a/make/defs.make Tue Jul 23 21:07:11 2013 +0200 +++ b/make/defs.make Tue Jul 23 22:13:05 2013 +0200 @@ -166,11 +166,15 @@ HOST := $(shell uname -n) endif -# If not SunOS, not Linux and not BSD, assume Windows +# If not SunOS, not Linux not BSD and not AIX, assume Windows ifneq ($(OS), Linux) ifneq ($(OS), SunOS) ifneq ($(OS), bsd) - OSNAME=windows + ifneq ($(OS), AIX) + OSNAME=windows + else + OSNAME=aix + endif else OSNAME=bsd endif Best regards, Goetz -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Friday, August 16, 2013 7:21 AM To: David Holmes Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX I thought trow() was added long time ago. But it was added, I think by accident, very recently: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a7fb14888912 I missed it when I did the review of those changes. We should remove throw. Vladimir On 8/15/13 5:14 PM, David Holmes wrote: On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: Hi Vladimir, throw is needed because it`s there in the implementation in nmethod.cpp. (So you are using it a bit at least :)) xlc says "nmethod.cpp", line 802.7: 1540-0400 (S) "nmethod::operator new(size_t, int)" has a conflicting declaration. "nmethod.hpp", line 268.9: 1540-0424 (I) "operator new" is declared on line 268 of "nmethod.hpp". Okay, it is just declaration. Why do we have throw here: void* nmethod::operator new(size_t size, int nmethod_size) throw () { // Not critical, may return null if there is too little continuous memory return CodeCache::allocate(nmethod_size); } Seems to me it should be removed if anything. David ----- int64 is defined correctly, uint64 is not defined, but never used in hotspot. I can not reproduce an error, but that's rather old coding from our VM. We also switched from xlc8 to xlc10 in the course of this project. I will test some more and talk to the person who implemented that tomorrow, and if possible remove the change. Okay, I will test it also. Vladimir Best regards & thanks for the review, Goetz. -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, August 15, 2013 5:52 PM To: Lindenmaier, Goetz Cc: 'hotspot-dev at openjdk.java.net'; ppc-aix-port-dev at openjdk.java.net; Albert Noll (albert.noll at oracle.com) Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX Goetz, I only see 2 problems which you did not explain: nmethod.hpp. Why the next change? we don't use C++ exceptions: - void* operator new(size_t size, int nmethod_size); + void* operator new(size_t size, int nmethod_size) throw (); port.hpp. Did AIX has the same definitions for jlong and julong?: +#ifndef _AIX +// These conflict with /usr/include/sys/inttypes.h on aix. typedef jlong int64; // Java long for my 64-bit type typedef julong uint64; // Java long for my 64-bit type +#endif And of cause we need to test these changes with compilers we use. Thanks, Vladimir On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: Hi, I prepared a webrev for 8023033: PPC64 (part 13): basic changes for AIX http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ This contains the basic shared changes needed for the AIX port, as there are - #includes - Fixes to get the code compiling with xlC/on AIX - Basic adaptions as in vm_version.cpp. It also determines the placement and naming of the aix files, which will go to os/aix and os_cpu/aix_ppc, as you can see in http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ Some details about the compilation problems: relocInfo.hpp: xlC wants initialization in inline implementation. vmreg.hpp: BAD is defined in AIX system header sys/param.h. Renamed. allocation.hpp xlC complains: runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" member "StackObj::operator delete(void *)" cannot be accessed. sharedRuntimeTrig.cpp Aix defines hz to be 100, see sys/m_param.h. Renamed. debug.hpp With other include order we get a lot of memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not declared. Please review and test this change. Comments are welcome. Thanks and best regards, Goetz. From stefan.karlsson at oracle.com Fri Aug 16 15:06:07 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Sat, 17 Aug 2013 00:06:07 +0200 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D015DAB@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> <520D6EEE.1040906@oracle.com> <520DB6B7.2050901@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015CCA@DEWDFEMB12A.global.corp.sap> <520E246F.1060704@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015DAB@DEWDFEMB12A.global.corp.sap> Message-ID: <520EA24F.5060304@oracle.com> On 8/16/13 11:28 PM, Lindenmaier, Goetz wrote: > > Hi Stefan, > > the problem is that globalDefinitions defines __STDC_FORMAT_MACROS. > > inttypes.hpp comes in through jni.hpp, which is in both, jvm.hpp and > > globalDefinitions.hpp through globalDefinitions_.hpp. > > If jvm.hpp comes first, inttype.hpp is added without the macro defined, > > and the print formats are missing. > > I could also define __STDC_FORMAT_MACROS in jni.hpp or the like. > > The name "globalDefinitions" somehow says that the definitions should > be seen > > everywhere ... so it's basically bad that the file does not end up at > the top of the include > > chain. Maybe I should include it in jni.hpp? or jvm.hpp? > > What do you think? > I see your problem. I think the most stable solution would be to add -D__STDC_FORMAT_MACROS to the compiler flags. But that seems out-of-scope for this change, so go ahead and use the reordering for now (unless someone else complains). thanks, StefanK > Best regards, > > Goetz. > > *From:*Stefan Karlsson [mailto:stefan.karlsson at oracle.com] > *Sent:* Friday, August 16, 2013 3:09 PM > *To:* Lindenmaier, Goetz > *Cc:* 'Vladimir Kozlov'; 'David Holmes'; > 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > *Subject:* Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX > > Hi Goetz, > > On 8/16/13 2:21 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > - I removed the throw() > > - I removed the #ifndef in port.hpp > > - I fixed the typeo. > > http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-2/ > > > > I always build without precompiled headers, the nightbuild with > > them. > > > utilities/debug.hpp.udiff.html > > -#include "prims/jvm.h" > #include "utilities/globalDefinitions.hpp" > +#include "prims/jvm.h" > > I don't think your change to debug.hpp is the correct way to solve the problems you were seeing with metaspace.hpp. Swapping the files just means that someone else might hit the same problem adding prims/jvm.hpp to another file. > > > You probably have a circular include dependency somewhere in the code. Could you revert the change to utilities/debug.hpp and try to figure out what the real problem is? > > thanks, > StefanK > > > > > > > Yes, there will be makefiles for aix, and the platform files. tTe prototype > > patches are here > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0014_aix_make_changes.patch > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0015_aix_ppc_files.patch > > > > But the make change contains mostly new files, except for > > > > --- a/make/defs.make Tue Jul 23 21:07:11 2013 +0200 > > +++ b/make/defs.make Tue Jul 23 22:13:05 2013 +0200 > > @@ -166,11 +166,15 @@ > > HOST := $(shell uname -n) > > endif > > > > -# If not SunOS, not Linux and not BSD, assume Windows > > +# If not SunOS, not Linux not BSD and not AIX, assume Windows > > ifneq ($(OS), Linux) > > ifneq ($(OS), SunOS) > > ifneq ($(OS), bsd) > > - OSNAME=windows > > + ifneq ($(OS), AIX) > > + OSNAME=windows > > + else > > + OSNAME=aix > > + endif > > else > > OSNAME=bsd > > endif > > > > > > Best regards, > > Goetz > > > > > > > > -----Original Message----- > > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > > Sent: Friday, August 16, 2013 7:21 AM > > To: David Holmes > > Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net ';'hotspot-dev at openjdk.java.net ' > > Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX > > > > I thought trow() was added long time ago. But it was added, I think by accident, very recently: > > > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a7fb14888912 > > > > I missed it when I did the review of those changes. > > > > We should remove throw. > > > > Vladimir > > > > On 8/15/13 5:14 PM, David Holmes wrote: > > On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: > > On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: > > Hi Vladimir, > > > > throw is needed because it`s there in the implementation in nmethod.cpp. > > (So you are using it a bit at least :)) > > xlc says > > "nmethod.cpp", line 802.7: 1540-0400 (S) "nmethod::operator > > new(size_t, int)" has a conflicting declaration. > > "nmethod.hpp", line 268.9: 1540-0424 (I) "operator new" is declared on > > line 268 of "nmethod.hpp". > > > > Okay, it is just declaration. > > > > Why do we have throw here: > > > > void* nmethod::operator new(size_t size, int nmethod_size) throw () { > > // Not critical, may return null if there is too little continuous memory > > return CodeCache::allocate(nmethod_size); > > } > > > > Seems to me it should be removed if anything. > > > > David > > ----- > > > > > > > > int64 is defined correctly, uint64 is not defined, but never used in > > hotspot. > > I can not reproduce an error, but that's rather old coding from our VM. > > We also switched from xlc8 to xlc10 in the course of this project. > > I will test some more and talk to the person who implemented that > > tomorrow, > > and if possible remove the change. > > > > Okay, I will test it also. > > > > Vladimir > > > > > > Best regards & thanks for the review, > > Goetz. > > > > > > > > > > > > -----Original Message----- > > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > > Sent: Thursday, August 15, 2013 5:52 PM > > To: Lindenmaier, Goetz > > Cc: 'hotspot-dev at openjdk.java.net ';ppc-aix-port-dev at openjdk.java.net ; > > Albert Noll (albert.noll at oracle.com ) > > Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX > > > > Goetz, > > > > I only see 2 problems which you did not explain: > > > > nmethod.hpp. Why the next change? we don't use C++ exceptions: > > > > - void* operator new(size_t size, int nmethod_size); > > + void* operator new(size_t size, int nmethod_size) throw (); > > > > port.hpp. Did AIX has the same definitions for jlong and julong?: > > > > +#ifndef _AIX > > +// These conflict with /usr/include/sys/inttypes.h on aix. > > typedef jlong int64; // Java long for my 64-bit type > > typedef julong uint64; // Java long for my 64-bit type > > +#endif > > > > > > And of cause we need to test these changes with compilers we use. > > > > Thanks, > > Vladimir > > > > On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > I prepared a webrev for > > 8023033: PPC64 (part 13): basic changes for AIX > > http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ > > > > This contains the basic shared changes needed for the AIX port, > > as there are > > - #includes > > - Fixes to get the code compiling with xlC/on AIX > > - Basic adaptions as in vm_version.cpp. > > > > It also determines the placement and naming of the aix files, > > which will go to os/aix and os_cpu/aix_ppc, as you can see in > > http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ > > > > > > Some details about the compilation problems: > > > > relocInfo.hpp: > > xlC wants initialization in inline implementation. > > > > vmreg.hpp: > > BAD is defined in AIX system header sys/param.h. Renamed. > > > > allocation.hpp > > xlC complains: > > runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" > > member "StackObj::operator delete(void *)" cannot be accessed. > > > > sharedRuntimeTrig.cpp > > Aix defines hz to be 100, see sys/m_param.h. Renamed. > > > > debug.hpp > > With other include order we get a lot of > > memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not > > declared. > > > > > > Please review and test this change. Comments are welcome. > > > > Thanks and best regards, > > Goetz. > > > From david.holmes at oracle.com Sun Aug 18 20:57:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 19 Aug 2013 13:57:53 +1000 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <520E5D68.3000202@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> <51F5D77B.6040009@oracle.com> <520E5D68.3000202@oracle.com> Message-ID: <521197C1.40705@oracle.com> On 17/08/2013 3:12 AM, Vladimir Kozlov wrote: > David, > > On 7/28/13 7:46 PM, David Holmes wrote: >> On 26/07/2013 9:11 AM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> we'd like to contribute our posix signal printing. >> >> This really isn't "posix signals" as it combines all the OS specific >> signal definitions into one chunk of code. > > Currently it is the only place in our sources where we can combine code > for all unix variations. But it isn't all common code, a lot of it is platform specific. I thought os_posix was supposed to be for factoring out common POSIX functionality. :( David ----- >> >> + // A number high enough to contain all possible signal numbers. >> + #define MAX_SIGNAL_NUMBER 70 >> >> Why do you need this when you use sigaddset to check validity anyway? >> What is this "maximum signal number" meant to represent anyway? The >> maximum signal number on the platform, or the maximum signal number for >> a signal that the JVM will install a handler for? >> >> The runtime team will need to take a good look at this. Personally I'd >> rather not see all the different OS stuff piled in together. I'd >> certainly like to see as little duplication as possible, but I'd rather >> platform specific stuff was dealt with in platform specific files. > > It is just printing unification to avoid a lot of duplication. > I agree that methods is_valid_signal() could stay in platform specific > files. But to have the rest, signals names and print methods, in one > place I think is good. > > Regards, > Vladimir > >> >> David >> ----- >> >>> We implemented some routines to print signal and sa_flags information >>> in the os/posix files, and call them from >>> os::print_siginfo and print_signal_handler() in the various unix >>> variant directories. >>> The output is a bit more verbose than the existing version. >>> >>> We contribute this here, as our aix code uses this too. >> >> >> >>> Please review this and test it if you think we should add this. >>> We'd appreciate it. >>> http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ >>> >>> Thanks and best regards, >>> Goetz. >>> From david.holmes at oracle.com Sun Aug 18 21:01:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 19 Aug 2013 14:01:14 +1000 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <520E65A8.1090803@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> <51F5D77B.6040009@oracle.com> <520E5D68.3000202@oracle.com> <520E65A8.1090803@oracle.com> Message-ID: <5211988A.7000403@oracle.com> On 17/08/2013 3:47 AM, Coleen Phillimore wrote: > On 8/16/2013 1:12 PM, Vladimir Kozlov wrote: >> David, >> >> On 7/28/13 7:46 PM, David Holmes wrote: >>> On 26/07/2013 9:11 AM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> we'd like to contribute our posix signal printing. >>> >>> This really isn't "posix signals" as it combines all the OS specific >>> signal definitions into one chunk of code. >> >> Currently it is the only place in our sources where we can combine >> code for all unix variations. > > Yes, we're renaming "posix" to "xnix", so it's good to not duplicate the > code in all the unix variations with this change, just because it's not > "posix". Even so I hate to see supposedly shared/platform-independent code full of platform specific stuff. :( But I'll shut up now. David > Coleen > >> >>> >>> + // A number high enough to contain all possible signal numbers. >>> + #define MAX_SIGNAL_NUMBER 70 >>> >>> Why do you need this when you use sigaddset to check validity anyway? >>> What is this "maximum signal number" meant to represent anyway? The >>> maximum signal number on the platform, or the maximum signal number for >>> a signal that the JVM will install a handler for? >>> >>> The runtime team will need to take a good look at this. Personally I'd >>> rather not see all the different OS stuff piled in together. I'd >>> certainly like to see as little duplication as possible, but I'd rather >>> platform specific stuff was dealt with in platform specific files. >> >> It is just printing unification to avoid a lot of duplication. >> I agree that methods is_valid_signal() could stay in platform specific >> files. But to have the rest, signals names and print methods, in one >> place I think is good. >> >> Regards, >> Vladimir >> >>> >>> David >>> ----- >>> >>>> We implemented some routines to print signal and sa_flags information >>>> in the os/posix files, and call them from >>>> os::print_siginfo and print_signal_handler() in the various unix >>>> variant directories. >>>> The output is a bit more verbose than the existing version. >>>> >>>> We contribute this here, as our aix code uses this too. >>> >>> >>> >>>> Please review this and test it if you think we should add this. >>>> We'd appreciate it. >>>> http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig/ >>>> >>>> Thanks and best regards, >>>> Goetz. >>>> > From goetz.lindenmaier at sap.com Mon Aug 19 00:23:25 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 19 Aug 2013 07:23:25 +0000 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <520E6BE6.70904@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> <51F2C9D1.60907@oracle.com> <4295855A5C1DE049A61835A1887419CC0D011426@DEWDFEMB12A.global.corp.sap> <520E6BE6.70904@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D015F25@DEWDFEMB12A.global.corp.sap> Hi Vladimir, I updated the webrev: http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig-2/ > const char* os::Posix::describe_signal_set_short(const sigset_t* set, > char* buffer, size_t buf_size) { I used your code. > The code in the loop in describe_sa_flags() is incorrect because > strlen(p) gives size of all stored sa names. It should be > strlen(flaginfo[idx].s). I also don't see why it is while() loop and not > simple for(). No, the code is correct. p points to the beginning of the recently printed string. Taking the size of p includes the '|' printed. I changed it to a for loop. >From your other mail: > It would be nice if you can produce the same alignment in output: > > SIGSEGV: [libjvm.so+0xc03f0d], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO The alignment of the signals would have to be done in print_signal_handler(), which I did not change yet. But this also looks like a candidate for moving to the posix file. Best regards, Goetz. From vladimir.kozlov at oracle.com Mon Aug 19 08:17:16 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 19 Aug 2013 08:17:16 -0700 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D015F25@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> <51F2C9D1.60907@oracle.com> <4295855A5C1DE049A61835A1887419CC0D011426@DEWDFEMB12A.global.corp.sap> <520E6BE6.70904@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015F25@DEWDFEMB12A.global.corp.sap> Message-ID: <521236FC.8070507@oracle.com> On 8/19/13 12:23 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > I updated the webrev: > http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig-2/ > >> const char* os::Posix::describe_signal_set_short(const sigset_t* set, >> char* buffer, size_t buf_size) { > I used your code. Thanks. > >> The code in the loop in describe_sa_flags() is incorrect because >> strlen(p) gives size of all stored sa names. It should be >> strlen(flaginfo[idx].s). I also don't see why it is while() loop and not >> simple for(). > No, the code is correct. p points to the beginning of the recently Yes, you are right. > printed string. Taking the size of p includes the '|' printed. > I changed it to a for loop. > > From your other mail: >> It would be nice if you can produce the same alignment in output: >> >> SIGSEGV: [libjvm.so+0xc03f0d], sa_mask[0]=1, sa_flags=SA_RESTART|SA_SIGINFO > > The alignment of the signals would have to be done in > print_signal_handler(), which I did not change yet. > But this also looks like a candidate for moving to > the posix file. It is not big deal, so we can leave it for now. I looked on print_signal_handler() and it would require several #ifdef in common code. Thanks, Vladimir > > Best regards, > Goetz. > > From vladimir.kozlov at oracle.com Mon Aug 19 09:32:23 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 19 Aug 2013 09:32:23 -0700 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <520EA24F.5060304@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> <520D6EEE.1040906@oracle.com> <520DB6B7.2050901@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015CCA@DEWDFEMB12A.global.corp.sap> <520E246F.1060704@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015DAB@DEWDFEMB12A.global.corp.sap> <520EA24F.5060304@oracle.com> Message-ID: <52124897.7030304@oracle.com> I tested 8023033-aixShared-2 in JPRT (including builds and tests on ppc + arm) and it passed without failures. Thanks, Vladimir On 8/16/13 3:06 PM, Stefan Karlsson wrote: > On 8/16/13 11:28 PM, Lindenmaier, Goetz wrote: >> >> Hi Stefan, >> >> the problem is that globalDefinitions defines __STDC_FORMAT_MACROS. >> >> inttypes.hpp comes in through jni.hpp, which is in both, jvm.hpp and >> >> globalDefinitions.hpp through globalDefinitions_.hpp. >> >> If jvm.hpp comes first, inttype.hpp is added without the macro defined, >> >> and the print formats are missing. >> >> I could also define __STDC_FORMAT_MACROS in jni.hpp or the like. >> >> The name ?globalDefinitions? somehow says that the definitions should >> be seen >> >> everywhere ? so it?s basically bad that the file does not end up at >> the top of the include >> >> chain. Maybe I should include it in jni.hpp? or jvm.hpp? >> >> What do you think? >> > > I see your problem. > > I think the most stable solution would be to add -D__STDC_FORMAT_MACROS > to the compiler flags. > > But that seems out-of-scope for this change, so go ahead and use the > reordering for now (unless someone else complains). > > thanks, > StefanK > >> Best regards, >> >> Goetz. >> >> *From:*Stefan Karlsson [mailto:stefan.karlsson at oracle.com] >> *Sent:* Friday, August 16, 2013 3:09 PM >> *To:* Lindenmaier, Goetz >> *Cc:* 'Vladimir Kozlov'; 'David Holmes'; >> 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> *Subject:* Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX >> >> Hi Goetz, >> >> On 8/16/13 2:21 PM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> >> >> - I removed the throw() >> >> - I removed the #ifndef in port.hpp >> >> - I fixed the typeo. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-2/ >> >> >> >> I always build without precompiled headers, the nightbuild with >> >> them. >> >> >> utilities/debug.hpp.udiff.html >> >> -#include "prims/jvm.h" >> #include "utilities/globalDefinitions.hpp" >> +#include "prims/jvm.h" >> >> I don't think your change to debug.hpp is the correct way to solve the problems you were seeing with metaspace.hpp. Swapping the files just means that someone else might hit the same problem adding prims/jvm.hpp to another file. >> >> >> You probably have a circular include dependency somewhere in the code. Could you revert the change to utilities/debug.hpp and try to figure out what the real problem is? >> >> thanks, >> StefanK >> >> >> >> >> >> >> Yes, there will be makefiles for aix, and the platform files. tTe prototype >> >> patches are here >> >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0014_aix_make_changes.patch >> >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0015_aix_ppc_files.patch >> >> >> >> But the make change contains mostly new files, except for >> >> >> >> --- a/make/defs.make Tue Jul 23 21:07:11 2013 +0200 >> >> +++ b/make/defs.make Tue Jul 23 22:13:05 2013 +0200 >> >> @@ -166,11 +166,15 @@ >> >> HOST := $(shell uname -n) >> >> endif >> >> >> >> -# If not SunOS, not Linux and not BSD, assume Windows >> >> +# If not SunOS, not Linux not BSD and not AIX, assume Windows >> >> ifneq ($(OS), Linux) >> >> ifneq ($(OS), SunOS) >> >> ifneq ($(OS), bsd) >> >> - OSNAME=windows >> >> + ifneq ($(OS), AIX) >> >> + OSNAME=windows >> >> + else >> >> + OSNAME=aix >> >> + endif >> >> else >> >> OSNAME=bsd >> >> endif >> >> >> >> >> >> Best regards, >> >> Goetz >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> >> Sent: Friday, August 16, 2013 7:21 AM >> >> To: David Holmes >> >> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net ';'hotspot-dev at openjdk.java.net ' >> >> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX >> >> >> >> I thought trow() was added long time ago. But it was added, I think by accident, very recently: >> >> >> >> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a7fb14888912 >> >> >> >> I missed it when I did the review of those changes. >> >> >> >> We should remove throw. >> >> >> >> Vladimir >> >> >> >> On 8/15/13 5:14 PM, David Holmes wrote: >> >> On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: >> >> On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: >> >> Hi Vladimir, >> >> >> >> throw is needed because it`s there in the implementation in nmethod.cpp. >> >> (So you are using it a bit at least :)) >> >> xlc says >> >> "nmethod.cpp", line 802.7: 1540-0400 (S) "nmethod::operator >> >> new(size_t, int)" has a conflicting declaration. >> >> "nmethod.hpp", line 268.9: 1540-0424 (I) "operator new" is declared on >> >> line 268 of "nmethod.hpp". >> >> >> >> Okay, it is just declaration. >> >> >> >> Why do we have throw here: >> >> >> >> void* nmethod::operator new(size_t size, int nmethod_size) throw () { >> >> // Not critical, may return null if there is too little continuous memory >> >> return CodeCache::allocate(nmethod_size); >> >> } >> >> >> >> Seems to me it should be removed if anything. >> >> >> >> David >> >> ----- >> >> >> >> >> >> >> >> int64 is defined correctly, uint64 is not defined, but never used in >> >> hotspot. >> >> I can not reproduce an error, but that's rather old coding from our VM. >> >> We also switched from xlc8 to xlc10 in the course of this project. >> >> I will test some more and talk to the person who implemented that >> >> tomorrow, >> >> and if possible remove the change. >> >> >> >> Okay, I will test it also. >> >> >> >> Vladimir >> >> >> >> >> >> Best regards & thanks for the review, >> >> Goetz. >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> >> Sent: Thursday, August 15, 2013 5:52 PM >> >> To: Lindenmaier, Goetz >> >> Cc: 'hotspot-dev at openjdk.java.net ';ppc-aix-port-dev at openjdk.java.net ; >> >> Albert Noll (albert.noll at oracle.com ) >> >> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX >> >> >> >> Goetz, >> >> >> >> I only see 2 problems which you did not explain: >> >> >> >> nmethod.hpp. Why the next change? we don't use C++ exceptions: >> >> >> >> - void* operator new(size_t size, int nmethod_size); >> >> + void* operator new(size_t size, int nmethod_size) throw (); >> >> >> >> port.hpp. Did AIX has the same definitions for jlong and julong?: >> >> >> >> +#ifndef _AIX >> >> +// These conflict with /usr/include/sys/inttypes.h on aix. >> >> typedef jlong int64; // Java long for my 64-bit type >> >> typedef julong uint64; // Java long for my 64-bit type >> >> +#endif >> >> >> >> >> >> And of cause we need to test these changes with compilers we use. >> >> >> >> Thanks, >> >> Vladimir >> >> >> >> On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> >> >> I prepared a webrev for >> >> 8023033: PPC64 (part 13): basic changes for AIX >> >> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >> >> >> >> This contains the basic shared changes needed for the AIX port, >> >> as there are >> >> - #includes >> >> - Fixes to get the code compiling with xlC/on AIX >> >> - Basic adaptions as in vm_version.cpp. >> >> >> >> It also determines the placement and naming of the aix files, >> >> which will go to os/aix and os_cpu/aix_ppc, as you can see in >> >> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >> >> >> >> >> >> Some details about the compilation problems: >> >> >> >> relocInfo.hpp: >> >> xlC wants initialization in inline implementation. >> >> >> >> vmreg.hpp: >> >> BAD is defined in AIX system header sys/param.h. Renamed. >> >> >> >> allocation.hpp >> >> xlC complains: >> >> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" >> >> member "StackObj::operator delete(void *)" cannot be accessed. >> >> >> >> sharedRuntimeTrig.cpp >> >> Aix defines hz to be 100, see sys/m_param.h. Renamed. >> >> >> >> debug.hpp >> >> With other include order we get a lot of >> >> memory/metaspace.hpp", line 281.66: 1540-0130 (S) "PRIuPTR" is not >> >> declared. >> >> >> >> >> >> Please review and test this change. Comments are welcome. >> >> >> >> Thanks and best regards, >> >> Goetz. >> >> >> > From bill.pittore at oracle.com Mon Aug 19 10:13:18 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Mon, 19 Aug 2013 13:13:18 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <52002372.2030302@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <52002372.2030302@oracle.com> Message-ID: <5212522E.6050902@oracle.com> On 8/5/2013 6:13 PM, Coleen Phillimore wrote: > > Hi Bill, I have some high level comments and other comments. This > wasn't as easy to review as Bob promised me! :-P > > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/src/share/classes/com/sun/tools/attach/VirtualMachine.java.udiff.html > paramter (typo - two instances) > > * @throws AgentInitializationException > - * If the Agent_OnAttach function returns an error > + * If the Agent_OnAttach[_L] function returns an error. > + * an error. > * Fixed. > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/os/posix/vm/os_posix.cpp.frames.html > > nameLen, prefixLen, suffixLen - the JVM coding convention (unlike > Java) is to have variable names lower case and separated by a _ (not > camelcase). Same for all the new code here buildAgentFunctionName. Fixed all names. Original code came from JDK which is why I had this scheme. > > Can you put a function above this function to say what it does? So > once it's code reviewed, we can quickly know what it does without > having to study this again - ie. Is name something like libxxx.so and > you're trying to extract lib and .so from it? There's no verification > of this at lines 286 and 287 but the code is handling the case of > other sorts of unexpected input (ie line 283). Why don't you strip > the lib and the .so if !is_absolute_path? Added a comment to the above function to describe what's going on. For absolute path case, the lib_name is something like /a/b/libL.so so we need to strip off the path, the 'lib' prefix and the '.so' suffix to get the base name. > 291 agentEntryName = NEW_C_HEAP_ARRAY(char, len, mtThread); > 292 if (agentEntryName == NULL) { > 293 return NULL; > 294 } > If NEW_C_HEAP_ARRAY fails it terminates the JVM. I think you might > want this function instead NEW_C_HEAP_ARRAY_RETURN_NULL if there's a > reasonable recovery possible. > Ok, changed it to the above. > os_windows.cpp > > Same comments as above. Also: > > 5432 strncat(agentEntryName, name, nameLen); > 5433 strcat(agentEntryName, p); > 5434 //agentEntryName == _Agent_OnLoad_libName at 12 > 5435 } else { > You could say why 12 but shouldn't it be the length of the resulting > symbol instead and not 12? Changed it to '@XX'. It's really the length of the arguments which could change in the future, so XX should be fine. > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/os.cpp.frames.html > > findAgentFunction - same comment about the coding conventions. > functions and variables are lower case with underscores. Class names > are CamelCase. It would be convenient if the jvm code used the java > coding convention but the rest of it doesn't so this new code is > inconsistent. This is hard to follow as it is! > Fixed. > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/thread.cpp.frames.html > > 3826 size_t num_symbol_entries = sizeof(on_unload_symbols) / sizeof(char*); > Why not use ARRAY_SIZE macro? > Fixed. > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/prims/jvmtiExport.cpp.frames.html > > 2208 // Check for builtin agent. If not then if the path is absolute we attempt > 2209 // to load the library. Otherwise we try to load it from the standard > 2210 // dll directory. > I think you are missing the word "found" in this sentence. You are > using builtin agent to mean agent defined in a statically linked > library, I believe. Can you say that instead? Builtin means that the > jvm knows about it and implements it but in this case it doesn't. Re-worded this to be more explicit about statically linked in > > Maybe find_statically_linked_agent() would be a better name for this > function? I think builtin came from when we did original JNI builitin libraries. It might be documented as such in the JEP or CCC. > > Is the is_valid() function really mean has_been_loaded()? > 2236 if (agentLib->valid()) { Yes, either it was found statically linked into the executable or it was successfully loaded as a shared lib. > > > Did you run the Internal NSK vm.quick.testlist tests on this to verify > that nothing breaks? There are a lot of tests with different agents > and combinations in that suite and it frequently holds some surprises > in this area so best to run it first. Let me know if you need help. Ran the vm/nsk tests using UTE. Also we have some new test code to test the statically linked agent functionality. Thanks so much for the excellent review. I'll update the webrev as soon as I rebuild and test. bill > > Coleen > > On 08/05/2013 10:41 AM, Bob Vandette wrote: >> On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: >> >>> On 8/2/2013 9:12 PM,serguei.spitsyn at oracle.com wrote: >>>> Hi Bill, >>>> >>>> A couple of more questions. >>>> >>>> webrev.01/jvmti.html >>>> >>>> An agent L whose image has been combined with the VM *is defined* as /statically linked/ >>>> if and only if the agent exports a function called Agent_OnLoad_L. >>>> >>>> A question to the above. >>>> Are we going to allow to link a library dynamically if it exports both >>>> the Agent_OnLoad and Agent_OnLoad_L functions? >>>> It can be convenient if a library exports both Agent_OnLoad and Agent_OnLoad_L >>>> as it can be linked statically or dynamically depending on the need without changes. >>>> >>> It would be nice but the problem is that you could only link one agent into the VM if it exported Agent_OnLoad. Otherwise there would be a symbol collision with the second agent you linked in that also had Agent_OnLoad. As an agent developer you will have to select one or the other at build time, either statically linked in or dynamic. >>>> You already added the following statement to the JVMTI spec: >>>> If a /statically linked/ agent L exports a function called Agent_OnLoad_L and >>>> a function called Agent_OnLoad, the Agent_OnLoad function will be ignored. >>>> >>>> Could we say it in a shorter form?: >>>> If a /statically linked/ agent L exports a function called Agent_OnLoad, >>>> the Agent_OnLoad function will be ignored. >>> I believe I copied this from JNI static linking JEP. If so, I'll probably leave it as is just for consistency with JNI static spec. JVM TI static linking spec is closely related to JNI static linking spec. >>>> In this context would it be reasonable to add another statement: >>>> If a /dynamically linked/ agent L exports a function called Agent_OnLoad_L, >>>> the Agent_OnLoad_L function will be ignored. >>>> >> I'd rather leave this undefined since the behavior is very platform specific. >> The way we determine if a library is statically linked is by the presence of the Agent_OnLoad_L function. >> If this function exists in a dynamically linked library, it will be treated as a static library if by some chance >> it's attempted to be loaded twice, since the symbol will may be visible in the running process. >> >> Bob. >> >> >>>> The same questions apply to the Agent_OnAttach and Agent_OnAttach_L entry points. >>>> >>> I'm out on vacation for a couple of weeks so I'll leave it up to Bob V. and yourself if you guys want to hash out better/different wording. >>> >>> bill >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 7/30/13 12:17 PM,bill.pittore at oracle.com wrote: >>>>> Thanks Serguei for the comments. Some comments inline. I updated the webrevs at >>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>>> >>>>> >>>>> On 7/26/2013 5:00 AM,serguei.spitsyn at oracle.com wrote: >>>>>> Hi Bill, >>>>>> >>>>>> Sorry for the big delay. >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>>> >>>>>> >>>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>>> >>>>>> >>>>>> I'm suggesting to use the reference *Agent_OnAttach[_L]**||* even more consistently. >>>>>> (If, in some cases, you prefer the longer form to underline the difference between >>>>>> dynamically and statically linked libraries then feel free to leave it as it is.) >>>>>> >>>>>> It would simplify the following fragments: >>>>>> >>>>>> 304 * It then causes the target VM to invoke the Agent_OnAttach function >>>>>> 305 * or, for a statically linked agent named 'L', the Agent_OnAttach_L function >>>>>> ==> >>>>>> >>>>>> 304 * It then causes the target VM to invoke the Agent_OnAttach[_L] function >>>>>> >>>>>> 409 * It then causes the target VM to invoke the Agent_OnAttach >>>>>> 410 * function or, for a statically linked agent named 'L', the >>>>>> 411 * Agent_OnAttach_L function as specified in the >>>>>> ==> >>>>>> 409 * It then causes the target VM to invoke the Agent_OnAttach[_L] >>>>>> 410 * function as specified in the >>>>>> >>>>> I left the above as is since it's part of the method description. The following fragments below I simplified as you suggested. >>>>> >>>>>> the following 4 identical fragments: >>>>>> >>>>>> 341 * If the Agent_OnAttach function returns an error >>>>>> 342 * or, for a statically linked agent named 'L', if the >>>>>> 343 * Agent_OnAttach_L function returns >>>>>> 344 * an error. >>>>>> 375 * If the Agent_OnAttach function returns an error >>>>>> 376 * or, for a statically linked agent named 'L', if the >>>>>> 377 * Agent_OnAttach_L function returns >>>>>> 378 * an error. >>>>>> 442 * If the Agent_OnAttach function returns an error >>>>>> 443 * or, for a statically linked agent named 'L', if the >>>>>> 444 * Agent_OnAttach_L function returns an error >>>>>> 475 * If the Agent_OnAttach function returns an error >>>>>> 476 * or, for a statically linked agent named 'L', if the >>>>>> 477 * Agent_OnAttach_L function returns >>>>>> 478 * an error. >>>>>> ==> >>>>>> >>>>>> 336 * If the Agent_OnAttach[_L] function returns an error. >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>> src/share/vm/prims/jvmti.xml >>>>>> >>>>>> Lines 442-462: many extra

's. The fragment does not look well. >>>>>> I'd suggest to remove most of them. >>>>>> Also, these lines are too long. Could you make them shorter, please? >>>>>> The same is applied to other long new lines in this file. >>>>> Cleaned this up a bit. >>>>>> Lines 490-491, 502-503, 505-506: >>>>>> The same sentence is repeated 3 times: "the agent library may be statically linked ..." >>>>>> >>>>>> 490 Note that the agent library may be statically linked into the executable >>>>>> 491 in which case no actual loading takes place. >>>>> Fixed. >>>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is specified, the VM will attempt to >>>>>> 502 load the shared library c:\myLibs\foo.dll. As mentioned above, the agent library may be statically linked into the executable >>>>>> 503 in which case no actual loading takes place >>>>>> >>>>>> 505 Note that the agent library may be statically linked into the executable >>>>>> 506 in which case no actual loading takes place. >>>>>> >>>>> Tweaked the above a bit to make it less wordy. >>>>> >>>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>>> >>>>>> 677 and enabled the event >>>>>> >>>>> Fixed. >>>>>> src/os/posix/vm/os_posix.cpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/os/windows/vm/os_windows.cpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/share/vm/prims/jvmtiExport.cpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/share/vm/runtime/arguments.hpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/share/vm/runtime/os.cpp >>>>>> >>>>>> Space is missed after the 'if': >>>>>> 471 if(entryName != NULL) { >>>>>> >>>>> Fixed. >>>>>> Extra space after the '*': >>>>>> 483 void * saveHandle; >>>>>> >>>>> Fixed. >>>>>> src/share/vm/runtime/os.hpp >>>>>> >>>>>> - no comments >>>>>> >>>>>> src/share/vm/runtime/thread.cpp >>>>>> >>>>>> The line has been removed: >>>>>> 3866 break; >>>>>> >>>>> Correct, the inner for loop was removed so no need for the break; >>>>>> I'm still in process of reading the code. >>>>>> Another pass is needed to make sure that nothing is missed. >>>>>> But in general, the code quality is pretty good. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 7/25/13 10:47 AM,bill.pittore at oracle.com wrote: >>>>>>> Still need an official reviewer for the hotspot changes for statically linked agents. >>>>>>> >>>>>>> thanks, >>>>>>> bill >>>>>>> >>>>>>>> These changes address bug 8014135 which adds support for statically linked agents in the VM. This is a followup to the recent JNI spec changes that addressed statically linked JNI libraries( 8005716). >>>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>>> http://openjdk.java.net/jeps/178 >>>>>>>> >>>>>>>> Webrevs are here: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>> >>>>>>>> The changes to jvmti.xml can also be seen in the output file that I placed here: >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>> >>>>>>>> Thanks, >>>>>>>> bill >>>>>>>> > From bill.pittore at oracle.com Mon Aug 19 12:11:15 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Mon, 19 Aug 2013 15:11:15 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <5200C643.9060902@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <51FC884C.20407@oracle.com> <690FEAD4-3147-4C8D-96EC-7B5C91AC27E4@oracle.com> <51FFF61E.1020509@oracle.com> <5200C643.9060902@oracle.com> Message-ID: <52126DD3.4070307@oracle.com> On 8/6/2013 5:47 AM, serguei.spitsyn at oracle.com wrote: > Bob, > > I've done another look and got a few more comments below. > > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ > > src/share/vm/runtime/os.cpp > > The comment before the function findAgentFunction() is inconsistent > with the implementation. > There is a mismatch in "lib name": lib_name and libName .vs. name > There is a mismatch in "check lib": check_lib .vs. checkLib > The following part is not accurate as it does not tell anything > about the condition is_static_lib(): > > + * If check_lib == true then we are looking for an > + * Agent_OnLoad_libname or Agent_OnAttach_libname function to > determine if > + * this library is statically linked into the image. > Fixed up the comment and variable names to make more sense. > > src/os/posix/vm/os_posix.cpp > src/os/windows/vm/os_windows.cpp > > The function buildAgentFunctionName(): > Minor: I'd suggest to change the argument name from "name" to > "libname" or "lib_name". > Otherwise, it takes time to figure out what the "name" > argument really means. > Fixed. > > src/share/vm/runtime/thread.cpp > > Minor: It is better to initialize the below with NULL: > 3699 void *library; > Fixed. > > I also agree with Coleen on the following: > - about using the hotspot coding convention for variables/functions > names > - a comment is needed before the function buildAgentFunctionName > - built-in agent => statically linked agent > > > One more thing to say is that I really like the implementation. > Thank you for adding this feature in such a non-intrusive fashion! > You're welcome! thanks for the review, I'm rebuilding/testing and then will send out a new webrev. bill > Thanks, > Serguei > > On 8/5/13 11:59 AM, serguei.spitsyn at oracle.com wrote: >> Bob, >> >> I'm not waiting for any changes from Bill at the moment but still >> reading the code. >> Sorry for the latency but it takes time as not everything is clear to >> me yet. >> >> Thanks, >> Serguei >> >> On 8/5/13 10:59 AM, Bob Vandette wrote: >>> Serguei, >>> >>> Are you ok with the webrev at this point or are you waiting for any >>> changes from Bill? >>> >>> I've asked Coleen to review the code since she's an official >>> Reviewer but she'd like to make >>> sure the serviceability team is ok with the changes. >>> >>> Bob. >>> >>> >>> On Aug 3, 2013, at 12:34 AM, serguei.spitsyn at oracle.com wrote: >>> >>>> On 8/2/13 8:11 PM, Bill Pittore wrote: >>>>> On 8/2/2013 9:12 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Bill, >>>>>> >>>>>> A couple of more questions. >>>>>> >>>>>> webrev.01/jvmti.html >>>>>> >>>>>> An agent L whose image has been combined with the VM *is defined* >>>>>> as /statically linked/ >>>>>> if and only if the agent exports a function called Agent_OnLoad_L. >>>>>> >>>>>> A question to the above. >>>>>> Are we going to allow to link a library dynamically if it exports >>>>>> both >>>>>> the Agent_OnLoad and Agent_OnLoad_L functions? >>>>>> It can be convenient if a library exports both Agent_OnLoad and >>>>>> Agent_OnLoad_L >>>>>> as it can be linked statically or dynamically depending on the >>>>>> need without changes. >>>>>> >>>>> It would be nice but the problem is that you could only link one >>>>> agent into the VM if it exported Agent_OnLoad. Otherwise there >>>>> would be a symbol collision with the second agent you linked in >>>>> that also had Agent_OnLoad. As an agent developer you will have to >>>>> select one or the other at build time, either statically linked in >>>>> or dynamic. >>>> I did not want to use the Agent_OnLoad for statically linked agent. >>>> Just wanted to say that the presence of the Agent_OnLoad_L must be >>>> ignored >>>> if the agent is linked dynamically. >>>> Maybe this rule needs to be clearly stated in the JVMTI spec. >>>> >>>>>> You already added the following statement to the JVMTI spec: >>>>>> If a /statically linked/ agent L exports a function called >>>>>> Agent_OnLoad_L and >>>>>> a function called Agent_OnLoad, the Agent_OnLoad function will >>>>>> be ignored. >>>>>> >>>>>> Could we say it in a shorter form?: >>>>>> If a /statically linked/ agent L exports a function called >>>>>> Agent_OnLoad, >>>>>> the Agent_OnLoad function will be ignored. >>>>> I believe I copied this from JNI static linking JEP. If so, I'll >>>>> probably leave it as is just for consistency with JNI static spec. >>>>> JVM TI static linking spec is closely related to JNI static >>>>> linking spec. >>>> I see. Then it is Ok with me. >>>> >>>>>> In this context would it be reasonable to add another statement: >>>>>> If a /dynamically linked/ agent L exports a function called >>>>>> Agent_OnLoad_L, >>>>>> the Agent_OnLoad_L function will be ignored. >>>>>> >>>>>> The same questions apply to the Agent_OnAttach and >>>>>> Agent_OnAttach_L entry points. >>>>>> >>>>> I'm out on vacation for a couple of weeks so I'll leave it up to >>>>> Bob V. and yourself if you guys want to hash out better/different >>>>> wording. >>>> Thank you for the quick reply, and have a nice vacation! >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> bill >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 7/30/13 12:17 PM, bill.pittore at oracle.com wrote: >>>>>>> Thanks Serguei for the comments. Some comments inline. I updated >>>>>>> the webrevs at >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7/26/2013 5:00 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Bill, >>>>>>>> >>>>>>>> Sorry for the big delay. >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>>>>> >>>>>>>> >>>>>>>> I'm suggesting to use the reference >>>>>>>> *Agent_OnAttach[_L]**||* even more consistently. >>>>>>>> (If, in some cases, you prefer the longer form to underline the >>>>>>>> difference between >>>>>>>> dynamically and statically linked libraries then feel free to >>>>>>>> leave it as it is.) >>>>>>>> >>>>>>>> It would simplify the following fragments: >>>>>>>> >>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>> Agent_OnAttach function >>>>>>>> 305 * or, for a statically linked agent named 'L', the >>>>>>>> Agent_OnAttach_L function >>>>>>>> ==> >>>>>>>> >>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>> Agent_OnAttach[_L] function >>>>>>>> >>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>> Agent_OnAttach >>>>>>>> 410 * function or, for a statically linked agent named >>>>>>>> 'L', the >>>>>>>> 411 * Agent_OnAttach_L function as specified >>>>>>>> in the >>>>>>>> ==> >>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>> Agent_OnAttach[_L] >>>>>>>> 410 * function as specified in the >>>>>>>> >>>>>>> I left the above as is since it's part of the method >>>>>>> description. The following fragments below I simplified as you >>>>>>> suggested. >>>>>>> >>>>>>>> the following 4 identical fragments: >>>>>>>> >>>>>>>> 341 * If the Agent_OnAttach >>>>>>>> function returns an error >>>>>>>> 342 * or, for a statically linked agent named >>>>>>>> 'L', if the >>>>>>>> 343 * Agent_OnAttach_L function returns >>>>>>>> 344 * an error. >>>>>>>> 375 * If the Agent_OnAttach >>>>>>>> function returns an error >>>>>>>> 376 * or, for a statically linked agent named >>>>>>>> 'L', if the >>>>>>>> 377 * Agent_OnAttach_L function returns >>>>>>>> 378 * an error. >>>>>>>> 442 * If the Agent_OnAttach >>>>>>>> function returns an error >>>>>>>> 443 * or, for a statically linked agent named >>>>>>>> 'L', if the >>>>>>>> 444 * Agent_OnAttach_L function returns an >>>>>>>> error >>>>>>>> 475 * If the Agent_OnAttach >>>>>>>> function returns an error >>>>>>>> 476 * or, for a statically linked agent named >>>>>>>> 'L', if the >>>>>>>> 477 * Agent_OnAttach_L function returns >>>>>>>> 478 * an error. >>>>>>>> ==> >>>>>>>> >>>>>>>> 336 * If the Agent_OnAttach[_L] >>>>>>>> function returns an error. >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>> >>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>> >>>>>>>> Lines 442-462: many extra

's. The fragment does not look >>>>>>>> well. >>>>>>>> I'd suggest to remove most of them. >>>>>>>> Also, these lines are too long. Could you make them shorter, >>>>>>>> please? >>>>>>>> The same is applied to other long new lines in this file. >>>>>>> Cleaned this up a bit. >>>>>>>> Lines 490-491, 502-503, 505-506: >>>>>>>> The same sentence is repeated 3 times: "the agent library >>>>>>>> may be statically linked ..." >>>>>>>> >>>>>>>> 490 Note that the agent library may be statically linked >>>>>>>> into the executable >>>>>>>> 491 in which case no actual loading takes place. >>>>>>> Fixed. >>>>>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is >>>>>>>> specified, the VM will attempt to >>>>>>>> 502 load the shared library >>>>>>>> c:\myLibs\foo.dll. As mentioned above, the agent >>>>>>>> library may be statically linked into the executable >>>>>>>> 503 in which case no actual loading takes place >>>>>>>> >>>>>>>> 505 Note that the agent library may be statically linked >>>>>>>> into the executable >>>>>>>> 506 in which case no actual loading takes place. >>>>>>>> >>>>>>> Tweaked the above a bit to make it less wordy. >>>>>>> >>>>>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>>>>> >>>>>>>> 677 and enabled the event >>>>>>>> >>>>>>> Fixed. >>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>> >>>>>>>> - no comments >>>>>>>> >>>>>>>> src/os/windows/vm/os_windows.cpp >>>>>>>> >>>>>>>> - no comments >>>>>>>> >>>>>>>> src/share/vm/prims/jvmtiExport.cpp >>>>>>>> >>>>>>>> - no comments >>>>>>>> >>>>>>>> src/share/vm/runtime/arguments.hpp >>>>>>>> >>>>>>>> - no comments >>>>>>>> >>>>>>>> src/share/vm/runtime/os.cpp >>>>>>>> >>>>>>>> Space is missed after the 'if': >>>>>>>> 471 if(entryName != NULL) { >>>>>>>> >>>>>>> Fixed. >>>>>>>> Extra space after the '*': >>>>>>>> 483 void * saveHandle; >>>>>>>> >>>>>>> Fixed. >>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>> >>>>>>>> - no comments >>>>>>>> >>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>> >>>>>>>> The line has been removed: >>>>>>>> 3866 break; >>>>>>>> >>>>>>> Correct, the inner for loop was removed so no need for the break; >>>>>>>> I'm still in process of reading the code. >>>>>>>> Another pass is needed to make sure that nothing is missed. >>>>>>>> But in general, the code quality is pretty good. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 7/25/13 10:47 AM, bill.pittore at oracle.com wrote: >>>>>>>>> Still need an official reviewer for the hotspot changes for >>>>>>>>> statically linked agents. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> bill >>>>>>>>> >>>>>>>>>> These changes address bug 8014135 which adds support for >>>>>>>>>> statically linked agents in the VM. This is a followup to the >>>>>>>>>> recent JNI spec changes that addressed statically linked JNI >>>>>>>>>> libraries( 8005716). >>>>>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>>>>> http://openjdk.java.net/jeps/178 >>>>>>>>>> >>>>>>>>>> Webrevs are here: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>>> >>>>>>>>>> The changes to jvmti.xml can also be seen in the output file >>>>>>>>>> that I placed here: >>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> bill >>>>>>>>>> >>>>>>> >> > From dawid.weiss at gmail.com Mon Aug 19 13:29:40 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 19 Aug 2013 22:29:40 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: <520DD9C1.1030303@oracle.com> References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> Message-ID: Thanks Vladimir, the tiered compilation hint was really very useful. I managed to reproduce this error on a 1.8 fastbuild and I can dump pretty much anything I want. But I still cannot figure out what's wrong -- it's beyond me. Here are the things I've tried per your suggestions - turning off -XX:-OptimizePtrCompare or -XX:-EliminateAutoBox doesn't help (error still present), - I do have a -Xbatch with a single compiler thread -- it was more difficult to hit an error seed (the tests are randomized) but it's still possible. I know it would be best to provide a stand-along reproduce package but it's not trivial given how complex Lucene tests and testing framework is. Can I provide you with anything that would be helpful except the above? :) Specifically I can: 1) dump an opto assembly from a failed and non-failed run 2) provide an opto assembly from a g1gc run vs. any other gc (which doesn't seem to exhibit the problem), 3) provide a -XX:+PrintCompilation -XX:+PrintCompilation2 or a verbose hotspot.log. Let me know if any of these (or anything else) would be useful. If not, I'll try to extract a stand-alone package that would reproduce the issue, although this is a real killer to pull off. Dawid On Fri, Aug 16, 2013 at 9:50 AM, Vladimir Kozlov wrote: > On 8/15/13 11:45 PM, Dawid Weiss wrote: >>> >>> It is with high probability Compiler problem. >> >> >> I believe so. I've re-run the tests with 1.8b102 and the problem is >> still there, although it's more difficult to show -- I ran a 100 full >> builds yesterday, five of them tripped on assertions that should be >> unreachable. > > > We switched on -XX:+TieredCompilation by default in b102. Switch it off to > use only C2 compiler which has the problem. > > >> >>> G1 has larger write-barrier code then other GCs. It can affect inlining >>> decisions. You can try to change -XX:InlineSmallCode=1000 value. It >>> controls >>> inlining of methods which were already compiled. >>> >>> You can also try -Xbatch -XX:CICompilerCount=1 to get serial >>> compilations. >> >> >> Thanks for these tips, Vladimir -- very helpful. I hope you don't mind >> me asking one more question - we had a discussion with another Lucene >> developer yesterday -- is -Xbatch deterministic in the sense that if >> you run a single thread/ deterministic piece of code it will always >> trigger compiles at the same time? What happens if there are two >> uncoordinated threads that hit a set of the same methods (and thus >> when the compiler kicks in the statistics will probably be different >> for each independent run)? > > > -Xbatch (equivalent to -XX:-BackgroubdCompilation) will block only thread > which first put compilation task on compile queue. Other threads check that > the task in the queue and resume execution without waiting. > You still can't get full determinism with several java threads, as you > notice. But it can reduce some variations in inlining decision because > compilation will be executed by one Compiler thread (instead of 2 by > default). So if compilation tasks are put on queue at the same order in > different runs you most likely will get the same code generation. Of cause > usually the order is slightly different (especially during startup when > there are a lot of compilation requests) so you can still get different > results. > > >> >> This question originated from a broader discussion where we were >> wondering how you, the compiler-guru guys approach the debugging in >> case something like this pops up -- a bug that is very hard to >> reproduce, that manifests itself rarely and for which pretty much any >> change at the Java level changes the compilation and thus generates >> completely different code. This seems to be a tough nut to crack. > > > We usually try to reproduce the problem with debug version of VM which have > a lot asserts and we may hit one which helps identify the problem. You are > lucky if you can reproduce a problem in debug VM in debugger. > We try to get assembler output of compiled method during run when it > crushes. hs_err file has address and offset in compiled code and small code > snippet which helps to find the code. After that we "look hard" on assembler > code and try to figure out what is wrong with it and which compiler part can > generate such code pattern. > There is debug flag -XX:AbortVMOnException==java.lang.NullPointerException > which allow to abort VM on exceptions. And with -XX:+ShowMessageBoxOnError > flag we allow to attach debugger to VM when it happened. > When we get only core file it is tough. We try to use Serviceability Agent > to extract information and compiled code from it and other data. > > An other suggestion for you. Since you can avoid problem with switched off > EA you can try to switch off only > > -XX:-OptimizePtrCompare "Use escape analysis to optimize pointers > compare" > -XX:-EliminateAutoBox "Control optimizations for autobox elimination" > > Vladimir > >> >> Dawid >> > From christian.thalinger at oracle.com Mon Aug 19 14:28:54 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 Aug 2013 14:28:54 -0700 Subject: RFR (L): 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment Message-ID: http://cr.openjdk.java.net/~twisti/8022853/webrev/ http://cr.openjdk.java.net/~twisti/8022853-jdk/webrev/ 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment Reviewed-by: In some native data structures of the VM oops are stored uncompressed when compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. From christian.thalinger at oracle.com Mon Aug 19 14:45:53 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 Aug 2013 14:45:53 -0700 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> Message-ID: <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> On Aug 19, 2013, at 1:29 PM, Dawid Weiss wrote: > Thanks Vladimir, the tiered compilation hint was really very useful. I > managed to reproduce this error on a 1.8 fastbuild and I can dump > pretty much anything I want. But I still cannot figure out what's > wrong -- it's beyond me. Here are the things I've tried per your > suggestions > > - turning off -XX:-OptimizePtrCompare or -XX:-EliminateAutoBox > doesn't help (error still present), > - I do have a -Xbatch with a single compiler thread -- it was more > difficult to hit an error seed (the tests are randomized) but it's > still possible. > > I know it would be best to provide a stand-along reproduce package but > it's not trivial given how complex Lucene tests and testing framework > is. Can I provide you with anything that would be helpful except the > above? :) Specifically I can: > > 1) dump an opto assembly from a failed and non-failed run > 2) provide an opto assembly from a g1gc run vs. any other gc (which > doesn't seem to exhibit the problem), > 3) provide a -XX:+PrintCompilation -XX:+PrintCompilation2 or a verbose > hotspot.log. > > Let me know if any of these (or anything else) would be useful. If > not, I'll try to extract a stand-alone package that would reproduce > the issue, although this is a real killer to pull off. How many total compiles are there? Maybe you can try to limit the methods being compiled with: -XX:CompileCommand=compileonly,foo::bar or -XX:CompileCommand=exclude,foo::bar One problem I see though is that using compileonly also prevents inlining which might hide the issue. -- Chris > > Dawid > > > On Fri, Aug 16, 2013 at 9:50 AM, Vladimir Kozlov > wrote: >> On 8/15/13 11:45 PM, Dawid Weiss wrote: >>>> >>>> It is with high probability Compiler problem. >>> >>> >>> I believe so. I've re-run the tests with 1.8b102 and the problem is >>> still there, although it's more difficult to show -- I ran a 100 full >>> builds yesterday, five of them tripped on assertions that should be >>> unreachable. >> >> >> We switched on -XX:+TieredCompilation by default in b102. Switch it off to >> use only C2 compiler which has the problem. >> >> >>> >>>> G1 has larger write-barrier code then other GCs. It can affect inlining >>>> decisions. You can try to change -XX:InlineSmallCode=1000 value. It >>>> controls >>>> inlining of methods which were already compiled. >>>> >>>> You can also try -Xbatch -XX:CICompilerCount=1 to get serial >>>> compilations. >>> >>> >>> Thanks for these tips, Vladimir -- very helpful. I hope you don't mind >>> me asking one more question - we had a discussion with another Lucene >>> developer yesterday -- is -Xbatch deterministic in the sense that if >>> you run a single thread/ deterministic piece of code it will always >>> trigger compiles at the same time? What happens if there are two >>> uncoordinated threads that hit a set of the same methods (and thus >>> when the compiler kicks in the statistics will probably be different >>> for each independent run)? >> >> >> -Xbatch (equivalent to -XX:-BackgroubdCompilation) will block only thread >> which first put compilation task on compile queue. Other threads check that >> the task in the queue and resume execution without waiting. >> You still can't get full determinism with several java threads, as you >> notice. But it can reduce some variations in inlining decision because >> compilation will be executed by one Compiler thread (instead of 2 by >> default). So if compilation tasks are put on queue at the same order in >> different runs you most likely will get the same code generation. Of cause >> usually the order is slightly different (especially during startup when >> there are a lot of compilation requests) so you can still get different >> results. >> >> >>> >>> This question originated from a broader discussion where we were >>> wondering how you, the compiler-guru guys approach the debugging in >>> case something like this pops up -- a bug that is very hard to >>> reproduce, that manifests itself rarely and for which pretty much any >>> change at the Java level changes the compilation and thus generates >>> completely different code. This seems to be a tough nut to crack. >> >> >> We usually try to reproduce the problem with debug version of VM which have >> a lot asserts and we may hit one which helps identify the problem. You are >> lucky if you can reproduce a problem in debug VM in debugger. >> We try to get assembler output of compiled method during run when it >> crushes. hs_err file has address and offset in compiled code and small code >> snippet which helps to find the code. After that we "look hard" on assembler >> code and try to figure out what is wrong with it and which compiler part can >> generate such code pattern. >> There is debug flag -XX:AbortVMOnException==java.lang.NullPointerException >> which allow to abort VM on exceptions. And with -XX:+ShowMessageBoxOnError >> flag we allow to attach debugger to VM when it happened. >> When we get only core file it is tough. We try to use Serviceability Agent >> to extract information and compiled code from it and other data. >> >> An other suggestion for you. Since you can avoid problem with switched off >> EA you can try to switch off only >> >> -XX:-OptimizePtrCompare "Use escape analysis to optimize pointers >> compare" >> -XX:-EliminateAutoBox "Control optimizations for autobox elimination" >> >> Vladimir >> >>> >>> Dawid >>> >> From kevin.walls at oracle.com Mon Aug 19 16:02:22 2013 From: kevin.walls at oracle.com (kevin.walls at oracle.com) Date: Mon, 19 Aug 2013 23:02:22 +0000 Subject: hg: hsx/hsx24/hotspot: 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() Message-ID: <20130819230234.30976489C7@hg.openjdk.java.net> Changeset: 84c2eb6a682b Author: kevinw Date: 2013-08-02 12:26 +0100 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/84c2eb6a682b 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() Reviewed-by: mgerdin, fparain, dcubed ! src/share/vm/services/gcNotifier.cpp From vladimir.kozlov at oracle.com Mon Aug 19 16:12:07 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 19 Aug 2013 16:12:07 -0700 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> Message-ID: <5212A647.10800@oracle.com> Christian, 'exclude' or 'compileonly' will not help because the failure reproduction depends on inlining. Dawid, It is great that you can build fastdebug VM. I assume that if I give you a patch to try you can also build with it. First, you can run with next options and then send zipped output (related part before the method compilation and optoassembler output, don't use hsdis for that) and hs_err file when test fails: -XX:CICompilerCount=1 -XX:+PrintInlining -XX:+TraceLoopOpts -XX:-BlockLayoutByFrequency -XX:-BlockLayoutRotateLoops -XX:CompileCommand=print,org.apache.lucene.index.FreqProxTermsWriterPerField::flush -XX:AbortVMOnException=java.lang.AssertionError Also, please, pull latest C2 Compiler changes from http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot Looking on java code in FreqProxTermsWriterPerField::flush() and based on LUCENE-5168 report generated code somehow missed EOF check. Am I right? This is why the Assert is thrown? And the failing code is next: } else { final int code = freq.readVInt(); if (!readTermFreq) { docID += code; termFreq = -1; } else { docID += code >>> 1; if ((code & 1) != 0) { termFreq = 1; } else { termFreq = freq.readVInt(); } } assert docID != postings.lastDocIDs[termID]; } Could you also send latest version of FreqProxTermsWriterPerField.java you are testing? Thanks, Vladimir On 8/19/13 2:45 PM, Christian Thalinger wrote: > > On Aug 19, 2013, at 1:29 PM, Dawid Weiss wrote: > >> Thanks Vladimir, the tiered compilation hint was really very useful. I >> managed to reproduce this error on a 1.8 fastbuild and I can dump >> pretty much anything I want. But I still cannot figure out what's >> wrong -- it's beyond me. Here are the things I've tried per your >> suggestions >> >> - turning off -XX:-OptimizePtrCompare or -XX:-EliminateAutoBox >> doesn't help (error still present), >> - I do have a -Xbatch with a single compiler thread -- it was more >> difficult to hit an error seed (the tests are randomized) but it's >> still possible. >> >> I know it would be best to provide a stand-along reproduce package but >> it's not trivial given how complex Lucene tests and testing framework >> is. Can I provide you with anything that would be helpful except the >> above? :) Specifically I can: >> >> 1) dump an opto assembly from a failed and non-failed run >> 2) provide an opto assembly from a g1gc run vs. any other gc (which >> doesn't seem to exhibit the problem), >> 3) provide a -XX:+PrintCompilation -XX:+PrintCompilation2 or a verbose >> hotspot.log. >> >> Let me know if any of these (or anything else) would be useful. If >> not, I'll try to extract a stand-alone package that would reproduce >> the issue, although this is a real killer to pull off. > > How many total compiles are there? Maybe you can try to limit the methods being compiled with: > > -XX:CompileCommand=compileonly,foo::bar > > or > > -XX:CompileCommand=exclude,foo::bar > > One problem I see though is that using compileonly also prevents inlining which might hide the issue. > > -- Chris > >> >> Dawid >> >> >> On Fri, Aug 16, 2013 at 9:50 AM, Vladimir Kozlov >> wrote: >>> On 8/15/13 11:45 PM, Dawid Weiss wrote: >>>>> >>>>> It is with high probability Compiler problem. >>>> >>>> >>>> I believe so. I've re-run the tests with 1.8b102 and the problem is >>>> still there, although it's more difficult to show -- I ran a 100 full >>>> builds yesterday, five of them tripped on assertions that should be >>>> unreachable. >>> >>> >>> We switched on -XX:+TieredCompilation by default in b102. Switch it off to >>> use only C2 compiler which has the problem. >>> >>> >>>> >>>>> G1 has larger write-barrier code then other GCs. It can affect inlining >>>>> decisions. You can try to change -XX:InlineSmallCode=1000 value. It >>>>> controls >>>>> inlining of methods which were already compiled. >>>>> >>>>> You can also try -Xbatch -XX:CICompilerCount=1 to get serial >>>>> compilations. >>>> >>>> >>>> Thanks for these tips, Vladimir -- very helpful. I hope you don't mind >>>> me asking one more question - we had a discussion with another Lucene >>>> developer yesterday -- is -Xbatch deterministic in the sense that if >>>> you run a single thread/ deterministic piece of code it will always >>>> trigger compiles at the same time? What happens if there are two >>>> uncoordinated threads that hit a set of the same methods (and thus >>>> when the compiler kicks in the statistics will probably be different >>>> for each independent run)? >>> >>> >>> -Xbatch (equivalent to -XX:-BackgroubdCompilation) will block only thread >>> which first put compilation task on compile queue. Other threads check that >>> the task in the queue and resume execution without waiting. >>> You still can't get full determinism with several java threads, as you >>> notice. But it can reduce some variations in inlining decision because >>> compilation will be executed by one Compiler thread (instead of 2 by >>> default). So if compilation tasks are put on queue at the same order in >>> different runs you most likely will get the same code generation. Of cause >>> usually the order is slightly different (especially during startup when >>> there are a lot of compilation requests) so you can still get different >>> results. >>> >>> >>>> >>>> This question originated from a broader discussion where we were >>>> wondering how you, the compiler-guru guys approach the debugging in >>>> case something like this pops up -- a bug that is very hard to >>>> reproduce, that manifests itself rarely and for which pretty much any >>>> change at the Java level changes the compilation and thus generates >>>> completely different code. This seems to be a tough nut to crack. >>> >>> >>> We usually try to reproduce the problem with debug version of VM which have >>> a lot asserts and we may hit one which helps identify the problem. You are >>> lucky if you can reproduce a problem in debug VM in debugger. >>> We try to get assembler output of compiled method during run when it >>> crushes. hs_err file has address and offset in compiled code and small code >>> snippet which helps to find the code. After that we "look hard" on assembler >>> code and try to figure out what is wrong with it and which compiler part can >>> generate such code pattern. >>> There is debug flag -XX:AbortVMOnException==java.lang.NullPointerException >>> which allow to abort VM on exceptions. And with -XX:+ShowMessageBoxOnError >>> flag we allow to attach debugger to VM when it happened. >>> When we get only core file it is tough. We try to use Serviceability Agent >>> to extract information and compiled code from it and other data. >>> >>> An other suggestion for you. Since you can avoid problem with switched off >>> EA you can try to switch off only >>> >>> -XX:-OptimizePtrCompare "Use escape analysis to optimize pointers >>> compare" >>> -XX:-EliminateAutoBox "Control optimizations for autobox elimination" >>> >>> Vladimir >>> >>>> >>>> Dawid >>>> >>> > From christian.thalinger at oracle.com Mon Aug 19 16:40:23 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 Aug 2013 16:40:23 -0700 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: <5212A647.10800@oracle.com> References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> <5212A647.10800@oracle.com> Message-ID: <39E8C09B-C15D-4B12-B339-C4D489499A9E@oracle.com> On Aug 19, 2013, at 4:12 PM, Vladimir Kozlov wrote: > Christian, > > 'exclude' or 'compileonly' will not help because the failure reproduction depends on inlining. Right. This brings me back to something we discussed a couple times already: compileonly should not disable inlining of callees. Someone should fix this. -- Chris > > Dawid, > > It is great that you can build fastdebug VM. I assume that if I give you a patch to try you can also build with it. > > First, you can run with next options and then send zipped output (related part before the method compilation and optoassembler output, don't use hsdis for that) and hs_err file when test fails: > > -XX:CICompilerCount=1 -XX:+PrintInlining -XX:+TraceLoopOpts -XX:-BlockLayoutByFrequency -XX:-BlockLayoutRotateLoops -XX:CompileCommand=print,org.apache.lucene.index.FreqProxTermsWriterPerField::flush -XX:AbortVMOnException=java.lang.AssertionError > > Also, please, pull latest C2 Compiler changes from http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot > > Looking on java code in FreqProxTermsWriterPerField::flush() and based on LUCENE-5168 report generated code somehow missed EOF check. Am I right? This is why the Assert is thrown? > > And the failing code is next: > > } else { > final int code = freq.readVInt(); > if (!readTermFreq) { > docID += code; > termFreq = -1; > } else { > docID += code >>> 1; > if ((code & 1) != 0) { > termFreq = 1; > } else { > termFreq = freq.readVInt(); > } > } > > assert docID != postings.lastDocIDs[termID]; > } > > Could you also send latest version of FreqProxTermsWriterPerField.java you are testing? > > Thanks, > Vladimir > > On 8/19/13 2:45 PM, Christian Thalinger wrote: >> >> On Aug 19, 2013, at 1:29 PM, Dawid Weiss wrote: >> >>> Thanks Vladimir, the tiered compilation hint was really very useful. I >>> managed to reproduce this error on a 1.8 fastbuild and I can dump >>> pretty much anything I want. But I still cannot figure out what's >>> wrong -- it's beyond me. Here are the things I've tried per your >>> suggestions >>> >>> - turning off -XX:-OptimizePtrCompare or -XX:-EliminateAutoBox >>> doesn't help (error still present), >>> - I do have a -Xbatch with a single compiler thread -- it was more >>> difficult to hit an error seed (the tests are randomized) but it's >>> still possible. >>> >>> I know it would be best to provide a stand-along reproduce package but >>> it's not trivial given how complex Lucene tests and testing framework >>> is. Can I provide you with anything that would be helpful except the >>> above? :) Specifically I can: >>> >>> 1) dump an opto assembly from a failed and non-failed run >>> 2) provide an opto assembly from a g1gc run vs. any other gc (which >>> doesn't seem to exhibit the problem), >>> 3) provide a -XX:+PrintCompilation -XX:+PrintCompilation2 or a verbose >>> hotspot.log. >>> >>> Let me know if any of these (or anything else) would be useful. If >>> not, I'll try to extract a stand-alone package that would reproduce >>> the issue, although this is a real killer to pull off. >> >> How many total compiles are there? Maybe you can try to limit the methods being compiled with: >> >> -XX:CompileCommand=compileonly,foo::bar >> >> or >> >> -XX:CompileCommand=exclude,foo::bar >> >> One problem I see though is that using compileonly also prevents inlining which might hide the issue. >> >> -- Chris >> >>> >>> Dawid >>> >>> >>> On Fri, Aug 16, 2013 at 9:50 AM, Vladimir Kozlov >>> wrote: >>>> On 8/15/13 11:45 PM, Dawid Weiss wrote: >>>>>> >>>>>> It is with high probability Compiler problem. >>>>> >>>>> >>>>> I believe so. I've re-run the tests with 1.8b102 and the problem is >>>>> still there, although it's more difficult to show -- I ran a 100 full >>>>> builds yesterday, five of them tripped on assertions that should be >>>>> unreachable. >>>> >>>> >>>> We switched on -XX:+TieredCompilation by default in b102. Switch it off to >>>> use only C2 compiler which has the problem. >>>> >>>> >>>>> >>>>>> G1 has larger write-barrier code then other GCs. It can affect inlining >>>>>> decisions. You can try to change -XX:InlineSmallCode=1000 value. It >>>>>> controls >>>>>> inlining of methods which were already compiled. >>>>>> >>>>>> You can also try -Xbatch -XX:CICompilerCount=1 to get serial >>>>>> compilations. >>>>> >>>>> >>>>> Thanks for these tips, Vladimir -- very helpful. I hope you don't mind >>>>> me asking one more question - we had a discussion with another Lucene >>>>> developer yesterday -- is -Xbatch deterministic in the sense that if >>>>> you run a single thread/ deterministic piece of code it will always >>>>> trigger compiles at the same time? What happens if there are two >>>>> uncoordinated threads that hit a set of the same methods (and thus >>>>> when the compiler kicks in the statistics will probably be different >>>>> for each independent run)? >>>> >>>> >>>> -Xbatch (equivalent to -XX:-BackgroubdCompilation) will block only thread >>>> which first put compilation task on compile queue. Other threads check that >>>> the task in the queue and resume execution without waiting. >>>> You still can't get full determinism with several java threads, as you >>>> notice. But it can reduce some variations in inlining decision because >>>> compilation will be executed by one Compiler thread (instead of 2 by >>>> default). So if compilation tasks are put on queue at the same order in >>>> different runs you most likely will get the same code generation. Of cause >>>> usually the order is slightly different (especially during startup when >>>> there are a lot of compilation requests) so you can still get different >>>> results. >>>> >>>> >>>>> >>>>> This question originated from a broader discussion where we were >>>>> wondering how you, the compiler-guru guys approach the debugging in >>>>> case something like this pops up -- a bug that is very hard to >>>>> reproduce, that manifests itself rarely and for which pretty much any >>>>> change at the Java level changes the compilation and thus generates >>>>> completely different code. This seems to be a tough nut to crack. >>>> >>>> >>>> We usually try to reproduce the problem with debug version of VM which have >>>> a lot asserts and we may hit one which helps identify the problem. You are >>>> lucky if you can reproduce a problem in debug VM in debugger. >>>> We try to get assembler output of compiled method during run when it >>>> crushes. hs_err file has address and offset in compiled code and small code >>>> snippet which helps to find the code. After that we "look hard" on assembler >>>> code and try to figure out what is wrong with it and which compiler part can >>>> generate such code pattern. >>>> There is debug flag -XX:AbortVMOnException==java.lang.NullPointerException >>>> which allow to abort VM on exceptions. And with -XX:+ShowMessageBoxOnError >>>> flag we allow to attach debugger to VM when it happened. >>>> When we get only core file it is tough. We try to use Serviceability Agent >>>> to extract information and compiled code from it and other data. >>>> >>>> An other suggestion for you. Since you can avoid problem with switched off >>>> EA you can try to switch off only >>>> >>>> -XX:-OptimizePtrCompare "Use escape analysis to optimize pointers >>>> compare" >>>> -XX:-EliminateAutoBox "Control optimizations for autobox elimination" >>>> >>>> Vladimir >>>> >>>>> >>>>> Dawid >>>>> >>>> >> From vladimir.kozlov at oracle.com Mon Aug 19 16:52:43 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 19 Aug 2013 16:52:43 -0700 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: <39E8C09B-C15D-4B12-B339-C4D489499A9E@oracle.com> References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> <5212A647.10800@oracle.com> <39E8C09B-C15D-4B12-B339-C4D489499A9E@oracle.com> Message-ID: <5212AFCB.7020205@oracle.com> On 8/19/13 4:40 PM, Christian Thalinger wrote: > > On Aug 19, 2013, at 4:12 PM, Vladimir Kozlov wrote: > >> Christian, >> >> 'exclude' or 'compileonly' will not help because the failure reproduction depends on inlining. > > Right. This brings me back to something we discussed a couple times already: compileonly should not disable inlining of callees. Someone should fix this. It may still not help because of InlineSmallCode - if other methods are not compiled they will be inlined. So it is different behavior. What we need is ReplayCompile which should not depend on state of java classes and be like PrintOptoAssembly when we dump initial MDOs of main and inlined methods, inlining decisions and results of all calls into VM during compilation to reproduce compilation exactly. Vladimir > > -- Chris > >> >> Dawid, >> >> It is great that you can build fastdebug VM. I assume that if I give you a patch to try you can also build with it. >> >> First, you can run with next options and then send zipped output (related part before the method compilation and optoassembler output, don't use hsdis for that) and hs_err file when test fails: >> >> -XX:CICompilerCount=1 -XX:+PrintInlining -XX:+TraceLoopOpts -XX:-BlockLayoutByFrequency -XX:-BlockLayoutRotateLoops -XX:CompileCommand=print,org.apache.lucene.index.FreqProxTermsWriterPerField::flush -XX:AbortVMOnException=java.lang.AssertionError >> >> Also, please, pull latest C2 Compiler changes from http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot >> >> Looking on java code in FreqProxTermsWriterPerField::flush() and based on LUCENE-5168 report generated code somehow missed EOF check. Am I right? This is why the Assert is thrown? >> >> And the failing code is next: >> >> } else { >> final int code = freq.readVInt(); >> if (!readTermFreq) { >> docID += code; >> termFreq = -1; >> } else { >> docID += code >>> 1; >> if ((code & 1) != 0) { >> termFreq = 1; >> } else { >> termFreq = freq.readVInt(); >> } >> } >> >> assert docID != postings.lastDocIDs[termID]; >> } >> >> Could you also send latest version of FreqProxTermsWriterPerField.java you are testing? >> >> Thanks, >> Vladimir >> >> On 8/19/13 2:45 PM, Christian Thalinger wrote: >>> >>> On Aug 19, 2013, at 1:29 PM, Dawid Weiss wrote: >>> >>>> Thanks Vladimir, the tiered compilation hint was really very useful. I >>>> managed to reproduce this error on a 1.8 fastbuild and I can dump >>>> pretty much anything I want. But I still cannot figure out what's >>>> wrong -- it's beyond me. Here are the things I've tried per your >>>> suggestions >>>> >>>> - turning off -XX:-OptimizePtrCompare or -XX:-EliminateAutoBox >>>> doesn't help (error still present), >>>> - I do have a -Xbatch with a single compiler thread -- it was more >>>> difficult to hit an error seed (the tests are randomized) but it's >>>> still possible. >>>> >>>> I know it would be best to provide a stand-along reproduce package but >>>> it's not trivial given how complex Lucene tests and testing framework >>>> is. Can I provide you with anything that would be helpful except the >>>> above? :) Specifically I can: >>>> >>>> 1) dump an opto assembly from a failed and non-failed run >>>> 2) provide an opto assembly from a g1gc run vs. any other gc (which >>>> doesn't seem to exhibit the problem), >>>> 3) provide a -XX:+PrintCompilation -XX:+PrintCompilation2 or a verbose >>>> hotspot.log. >>>> >>>> Let me know if any of these (or anything else) would be useful. If >>>> not, I'll try to extract a stand-alone package that would reproduce >>>> the issue, although this is a real killer to pull off. >>> >>> How many total compiles are there? Maybe you can try to limit the methods being compiled with: >>> >>> -XX:CompileCommand=compileonly,foo::bar >>> >>> or >>> >>> -XX:CompileCommand=exclude,foo::bar >>> >>> One problem I see though is that using compileonly also prevents inlining which might hide the issue. >>> >>> -- Chris >>> >>>> >>>> Dawid >>>> >>>> >>>> On Fri, Aug 16, 2013 at 9:50 AM, Vladimir Kozlov >>>> wrote: >>>>> On 8/15/13 11:45 PM, Dawid Weiss wrote: >>>>>>> >>>>>>> It is with high probability Compiler problem. >>>>>> >>>>>> >>>>>> I believe so. I've re-run the tests with 1.8b102 and the problem is >>>>>> still there, although it's more difficult to show -- I ran a 100 full >>>>>> builds yesterday, five of them tripped on assertions that should be >>>>>> unreachable. >>>>> >>>>> >>>>> We switched on -XX:+TieredCompilation by default in b102. Switch it off to >>>>> use only C2 compiler which has the problem. >>>>> >>>>> >>>>>> >>>>>>> G1 has larger write-barrier code then other GCs. It can affect inlining >>>>>>> decisions. You can try to change -XX:InlineSmallCode=1000 value. It >>>>>>> controls >>>>>>> inlining of methods which were already compiled. >>>>>>> >>>>>>> You can also try -Xbatch -XX:CICompilerCount=1 to get serial >>>>>>> compilations. >>>>>> >>>>>> >>>>>> Thanks for these tips, Vladimir -- very helpful. I hope you don't mind >>>>>> me asking one more question - we had a discussion with another Lucene >>>>>> developer yesterday -- is -Xbatch deterministic in the sense that if >>>>>> you run a single thread/ deterministic piece of code it will always >>>>>> trigger compiles at the same time? What happens if there are two >>>>>> uncoordinated threads that hit a set of the same methods (and thus >>>>>> when the compiler kicks in the statistics will probably be different >>>>>> for each independent run)? >>>>> >>>>> >>>>> -Xbatch (equivalent to -XX:-BackgroubdCompilation) will block only thread >>>>> which first put compilation task on compile queue. Other threads check that >>>>> the task in the queue and resume execution without waiting. >>>>> You still can't get full determinism with several java threads, as you >>>>> notice. But it can reduce some variations in inlining decision because >>>>> compilation will be executed by one Compiler thread (instead of 2 by >>>>> default). So if compilation tasks are put on queue at the same order in >>>>> different runs you most likely will get the same code generation. Of cause >>>>> usually the order is slightly different (especially during startup when >>>>> there are a lot of compilation requests) so you can still get different >>>>> results. >>>>> >>>>> >>>>>> >>>>>> This question originated from a broader discussion where we were >>>>>> wondering how you, the compiler-guru guys approach the debugging in >>>>>> case something like this pops up -- a bug that is very hard to >>>>>> reproduce, that manifests itself rarely and for which pretty much any >>>>>> change at the Java level changes the compilation and thus generates >>>>>> completely different code. This seems to be a tough nut to crack. >>>>> >>>>> >>>>> We usually try to reproduce the problem with debug version of VM which have >>>>> a lot asserts and we may hit one which helps identify the problem. You are >>>>> lucky if you can reproduce a problem in debug VM in debugger. >>>>> We try to get assembler output of compiled method during run when it >>>>> crushes. hs_err file has address and offset in compiled code and small code >>>>> snippet which helps to find the code. After that we "look hard" on assembler >>>>> code and try to figure out what is wrong with it and which compiler part can >>>>> generate such code pattern. >>>>> There is debug flag -XX:AbortVMOnException==java.lang.NullPointerException >>>>> which allow to abort VM on exceptions. And with -XX:+ShowMessageBoxOnError >>>>> flag we allow to attach debugger to VM when it happened. >>>>> When we get only core file it is tough. We try to use Serviceability Agent >>>>> to extract information and compiled code from it and other data. >>>>> >>>>> An other suggestion for you. Since you can avoid problem with switched off >>>>> EA you can try to switch off only >>>>> >>>>> -XX:-OptimizePtrCompare "Use escape analysis to optimize pointers >>>>> compare" >>>>> -XX:-EliminateAutoBox "Control optimizations for autobox elimination" >>>>> >>>>> Vladimir >>>>> >>>>>> >>>>>> Dawid >>>>>> >>>>> >>> > From christian.thalinger at oracle.com Mon Aug 19 17:30:34 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 Aug 2013 17:30:34 -0700 Subject: RFR (S): 8022956: Clang: enable return type warnings on BSD Message-ID: <78A98D94-FADF-44D4-9072-6E63265D108C@oracle.com> http://cr.openjdk.java.net/~twisti/8022956/webrev/ 8022956: Clang: enable return type warnings on BSD Reviewed-by: While implementing a new feature I noticed that Clang isn't complaining about wrong return types while Sun Studio does. The reason is that we turned it off. Turning it on only needs one small code change (plus a bunch of fixes for Zero). We probably should do the same on Linux but I don't have a Linux machine with Clang installed available. make/bsd/makefiles/gcc.make src/cpu/zero/vm/assembler_zero.cpp src/cpu/zero/vm/cppInterpreter_zero.cpp src/cpu/zero/vm/frame_zero.cpp src/cpu/zero/vm/frame_zero.inline.hpp src/cpu/zero/vm/icBuffer_zero.cpp src/cpu/zero/vm/interp_masm_zero.hpp src/cpu/zero/vm/interpreter_zero.cpp src/cpu/zero/vm/nativeInst_zero.hpp src/cpu/zero/vm/register_zero.cpp src/cpu/zero/vm/relocInfo_zero.cpp src/cpu/zero/vm/sharedRuntime_zero.cpp src/cpu/zero/vm/vtableStubs_zero.cpp src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp From dawid.weiss at gmail.com Tue Aug 20 02:11:14 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Tue, 20 Aug 2013 11:11:14 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: <5212A647.10800@oracle.com> References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> <5212A647.10800@oracle.com> Message-ID: Thanks for comments guys. > It is great that you can build fastdebug VM. I assume that if I give you a > patch to try you can also build with it. Yes, absolutely. > First, you can run with next options and then send zipped output (related > part before the method compilation and optoassembler output, don't use hsdis > for that) and hs_err file when test fails: I did that. Used the options you requested -- a full log of all I did is included in the ZIP file here: http://www.cs.put.poznan.pl/dweiss/tmp/debug-files.zip Cat debug-files\debug-log.txt. There are several runs included in that ZIP file, in short: - jdk18-fastdebug, b102, full run (no abort on assertion, explained in debug-log.txt): 001-no-abort-on-assertion 002-no-abort-on-assertion - jdk18-fastdebug, b102, abort on assertion (includes mem dumps) 003-with-abort-on-assertion 004-with-abort-on-assertion - jdk18-fastdebug, hsx tip, abort on assertion (includes mem dumps) 005-hsx-tip 006-hsx-tip - jdk18-fastdebug, hsx tip, excluded readvint method inlining (passed build, so only compilation logs available). 007-excluded-readvint > Looking on java code in FreqProxTermsWriterPerField::flush() and based on > LUCENE-5168 report generated code somehow missed EOF check. Am I right? This > is why the Assert is thrown? It's not the only method it trips on. Depending on the seed the problem shows up in different places. For the dumps I included the issue seems to be here: > } else { > final int code = freq.readVInt(); > if (!readTermFreq) { > docID += code; > termFreq = -1; If I add sysouts as in: Index: core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java =================================================================== --- core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java (revision 1512807) +++ core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java (working copy) @@ -427,6 +427,7 @@ //System.out.println(" cycle"); final int termFreq; if (freq.eof()) { + System.err.print("# (eof)"); if (postings.lastDocCodes[termID] != -1) { // Return last doc docID = postings.lastDocIDs[termID]; @@ -442,6 +443,7 @@ } } else { final int code = freq.readVInt(); + System.err.print("# (code): " + code + " "); if (!readTermFreq) { docID += code; termFreq = -1; then for a constant seed you'll get an identical sequence of values. Once the assertion hits though, the sequence deviates. Comparing a passing run (excluding readvint) and a failing run I get a lot of initial aligned outputs and then a deviation: (correct run): # (eof) # (eof) # (eof) # (code): 0 # (code): 3 # (code): 4 # (code): 3 (incorrect run): # (eof) # (eof) # (eof) # (code): 0 # (code): 4 <- wtf? # (code): 2 # (code): 2 How can a variable encoded integer be misinterpreted from 3 to 4 is beyond me, sorry. But it's not an EOF condition I think, at least the deviation happens where the original run had was entering (code) branch. > Could you also send latest version of FreqProxTermsWriterPerField.java you > are testing? I'm testing against a fixed branch (the info is included in debug-log.txt). If there's anything else I can do, let me know. I'm also curious how you approach debugging this thing. It may be time-based so I don't think it'll reproduce on your machine out of the box, but who knows. All I know is that, for example, if you add one more sysout before the while loop it suddenly stops reproducing so probably something gets compiled differently... Wild :) Dawid From dawid.weiss at gmail.com Tue Aug 20 02:32:24 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Tue, 20 Aug 2013 11:32:24 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> <5212A647.10800@oracle.com> Message-ID: One follow-up with respect to those encoded integers -- I swapped the correct and incorrect sequence in my last e-mail, sorry. I then also added a sysout here: @@ -451,6 +453,7 @@ termFreq = 1; } else { termFreq = freq.readVInt(); + System.err.print("# (tf): " + termFreq + " "); } } With this the assertion is no longer hit but it shows where the difference in numbers comes from: Correct sequence is: # (eof) # (code): 0 # (tf): 3 # (code): 4 # (tf): 3 # (code): 2 # (tf): 5 # (code): 2 # (tf): 2 # (code): 3 # (code): 5 # (code): 2 And the incorrect, assertion-hit run shows: # (eof) # (code): 0 # (code): 3 # (code): 4 # (code): 3 # (code): 2 # (code): 5 # (code): 2 # (code): 2 # (code): 3 So there's something odd happening after the first readvint which returns 0 -- the next number that should be read by: termFreq = freq.readVInt(); is re-read as the next code. Dawid On Tue, Aug 20, 2013 at 11:11 AM, Dawid Weiss wrote: > Thanks for comments guys. > >> It is great that you can build fastdebug VM. I assume that if I give you a >> patch to try you can also build with it. > > Yes, absolutely. > >> First, you can run with next options and then send zipped output (related >> part before the method compilation and optoassembler output, don't use hsdis >> for that) and hs_err file when test fails: > > I did that. Used the options you requested -- a full log of all I did > is included in the ZIP file here: > http://www.cs.put.poznan.pl/dweiss/tmp/debug-files.zip > > Cat debug-files\debug-log.txt. There are several runs included in that > ZIP file, in short: > > - jdk18-fastdebug, b102, full run (no abort on assertion, explained in > debug-log.txt): > 001-no-abort-on-assertion > 002-no-abort-on-assertion > > - jdk18-fastdebug, b102, abort on assertion (includes mem dumps) > 003-with-abort-on-assertion > 004-with-abort-on-assertion > > - jdk18-fastdebug, hsx tip, abort on assertion (includes mem dumps) > 005-hsx-tip > 006-hsx-tip > > - jdk18-fastdebug, hsx tip, excluded readvint method inlining (passed > build, so only compilation logs available). > 007-excluded-readvint > >> Looking on java code in FreqProxTermsWriterPerField::flush() and based on >> LUCENE-5168 report generated code somehow missed EOF check. Am I right? This >> is why the Assert is thrown? > > It's not the only method it trips on. Depending on the seed the > problem shows up in different places. For the dumps I included the > issue seems to be here: > >> } else { >> final int code = freq.readVInt(); >> if (!readTermFreq) { >> docID += code; >> termFreq = -1; > > If I add sysouts as in: > > Index: core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java > =================================================================== > --- core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java > (revision 1512807) > +++ core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java > (working copy) > @@ -427,6 +427,7 @@ > //System.out.println(" cycle"); > final int termFreq; > if (freq.eof()) { > + System.err.print("# (eof)"); > if (postings.lastDocCodes[termID] != -1) { > // Return last doc > docID = postings.lastDocIDs[termID]; > @@ -442,6 +443,7 @@ > } > } else { > final int code = freq.readVInt(); > + System.err.print("# (code): " + code + " "); > if (!readTermFreq) { > docID += code; > termFreq = -1; > > then for a constant seed you'll get an identical sequence of values. > Once the assertion hits though, the sequence deviates. Comparing a > passing run (excluding readvint) and a failing run I get a lot of > initial aligned outputs and then a deviation: > > (correct run): > # (eof) > # (eof) > # (eof) > # (code): 0 > # (code): 3 > # (code): 4 > # (code): 3 > > (incorrect run): > # (eof) > # (eof) > # (eof) > # (code): 0 > # (code): 4 <- wtf? > # (code): 2 > # (code): 2 > > How can a variable encoded integer be misinterpreted from 3 to 4 is > beyond me, sorry. But it's not an EOF condition I think, at least the > deviation happens where the original run had was entering (code) > branch. > >> Could you also send latest version of FreqProxTermsWriterPerField.java you >> are testing? > > I'm testing against a fixed branch (the info is included in debug-log.txt). > > If there's anything else I can do, let me know. I'm also curious how > you approach debugging this thing. It may be time-based so I don't > think it'll reproduce on your machine out of the box, but who knows. > All I know is that, for example, if you add one more sysout before the > while loop it suddenly stops reproducing so probably something gets > compiled differently... Wild :) > > Dawid From vladimir.kempik at oracle.com Tue Aug 20 04:44:33 2013 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Tue, 20 Aug 2013 15:44:33 +0400 Subject: Request for review: 8020530 Non heap memory size calculated incorrectly Message-ID: <521356A1.9010507@oracle.com> Hi all, Could I have a couple of reviews for this change? http://cr.openjdk.java.net/~vkempik/8020530/webrev.00/ Running WebLogic server with 1.8.0 encounters this error: Caused by: java.lang.IllegalArgumentException: committed = 86482944 should be < max = 50331648 at java.lang.management.MemoryUsage.(MemoryUsage.java:162) at sun.management.MemoryImpl.getMemoryUsage0(Native Method) at sun.management.MemoryImpl.getNonHeapMemoryUsage(MemoryImpl.java:75) ... 37 more There is a bug in jmm_GetMemoryUsage here -- if a memory region does not define a maximum size, then the total_max is not updated: if (u.max_size() == (size_t)-1) { has_undefined_max_size = true; } if (!has_undefined_max_size) { total_max += u.max_size(); } It started with JDK version 1.8.0-ea-b97. In src/share/vm/services/management.cpp: jmm_GetMemoryUsage() there is next comment // if any one of the memory pool has undefined init_size or max_size, // set it to -1 But code doing this is missing, so I've added the code to do exactly what comment says. Thanks, Vladimir From dmitry.samersoff at oracle.com Tue Aug 20 05:00:21 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 20 Aug 2013 16:00:21 +0400 Subject: Request for review: 8020530 Non heap memory size calculated incorrectly In-Reply-To: <521356A1.9010507@oracle.com> References: <521356A1.9010507@oracle.com> Message-ID: <52135A55.9010608@oracle.com> Vladimir, Explicit cast of -1 to size_t is required. -Dmitry On 2013-08-20 15:44, Vladimir Kempik wrote: > Hi all, > > Could I have a couple of reviews for this change? > > http://cr.openjdk.java.net/~vkempik/8020530/webrev.00/ > > Running WebLogic server with 1.8.0 encounters this error: > > Caused by: java.lang.IllegalArgumentException: committed = 86482944 > should be < max = 50331648 > > at java.lang.management.MemoryUsage.(MemoryUsage.java:162) > > at sun.management.MemoryImpl.getMemoryUsage0(Native Method) > > at > sun.management.MemoryImpl.getNonHeapMemoryUsage(MemoryImpl.java:75) > > ... 37 more > > There is a bug in jmm_GetMemoryUsage here -- if a memory region does not > define a maximum size, then the total_max is not updated: > if (u.max_size() == (size_t)-1) { > has_undefined_max_size = true; > } > if (!has_undefined_max_size) { > total_max += u.max_size(); > } > > It started with JDK version 1.8.0-ea-b97. > > In src/share/vm/services/management.cpp: jmm_GetMemoryUsage() there is > next comment > > // if any one of the memory pool has undefined init_size or max_size, > // set it to -1 > > But code doing this is missing, so I've added the code to do exactly > what comment says. > > Thanks, > Vladimir > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Tue Aug 20 05:14:26 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Aug 2013 22:14:26 +1000 Subject: Request for review: 8020530 Non heap memory size calculated incorrectly In-Reply-To: <521356A1.9010507@oracle.com> References: <521356A1.9010507@oracle.com> Message-ID: <52135DA2.4070403@oracle.com> On 20/08/2013 9:44 PM, Vladimir Kempik wrote: > Hi all, > > Could I have a couple of reviews for this change? > > http://cr.openjdk.java.net/~vkempik/8020530/webrev.00/ > > Running WebLogic server with 1.8.0 encounters this error: > > Caused by: java.lang.IllegalArgumentException: committed = 86482944 > should be < max = 50331648 > > at java.lang.management.MemoryUsage.(MemoryUsage.java:162) > > at sun.management.MemoryImpl.getMemoryUsage0(Native Method) > > at > sun.management.MemoryImpl.getNonHeapMemoryUsage(MemoryImpl.java:75) > > ... 37 more > > There is a bug in jmm_GetMemoryUsage here -- if a memory region does not > define a maximum size, then the total_max is not updated: > if (u.max_size() == (size_t)-1) { > has_undefined_max_size = true; > } > if (!has_undefined_max_size) { > total_max += u.max_size(); > } > > It started with JDK version 1.8.0-ea-b97. > > In src/share/vm/services/management.cpp: jmm_GetMemoryUsage() there is > next comment > > // if any one of the memory pool has undefined init_size or max_size, > // set it to -1 > > But code doing this is missing, so I've added the code to do exactly > what comment says. That doesn't make a lot of sense to me. Why would a pool have undefined values? If a subset of pools have undefined values why report completely fallacious values of -1? It also isn't clear how this relates to the "committed" value in the failure. What gets reported now? Thanks, David > Thanks, > Vladimir > From staffan.larsen at oracle.com Tue Aug 20 05:19:35 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 20 Aug 2013 14:19:35 +0200 Subject: Request for review: 8020530 Non heap memory size calculated incorrectly In-Reply-To: <521356A1.9010507@oracle.com> References: <521356A1.9010507@oracle.com> Message-ID: Looks good. Metaspace is the first memory pool with an undefined maximum size. /Staffan On 20 aug 2013, at 13:44, Vladimir Kempik wrote: > Hi all, > > Could I have a couple of reviews for this change? > > http://cr.openjdk.java.net/~vkempik/8020530/webrev.00/ > > Running WebLogic server with 1.8.0 encounters this error: > > Caused by: java.lang.IllegalArgumentException: committed = 86482944 should be < max = 50331648 > > at java.lang.management.MemoryUsage.(MemoryUsage.java:162) > > at sun.management.MemoryImpl.getMemoryUsage0(Native Method) > > at sun.management.MemoryImpl.getNonHeapMemoryUsage(MemoryImpl.java:75) > > ... 37 more > > There is a bug in jmm_GetMemoryUsage here -- if a memory region does not define a maximum size, then the total_max is not updated: > if (u.max_size() == (size_t)-1) { > has_undefined_max_size = true; > } > if (!has_undefined_max_size) { > total_max += u.max_size(); > } > > It started with JDK version 1.8.0-ea-b97. > > In src/share/vm/services/management.cpp: jmm_GetMemoryUsage() there is next comment > > // if any one of the memory pool has undefined init_size or max_size, > // set it to -1 > > But code doing this is missing, so I've added the code to do exactly what comment says. > > Thanks, > Vladimir > From jesper.wilhelmsson at oracle.com Tue Aug 20 05:33:21 2013 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 20 Aug 2013 14:33:21 +0200 Subject: CFV: New HSX Committer: Niclas Adlertz In-Reply-To: <8738qj99om.fsf@oracle.com> References: <8738qj99om.fsf@oracle.com> Message-ID: <52136211.5030806@oracle.com> Vote: yes /Jesper Roland Westrelin skrev 8/8/13 11:03 PM: > > I hereby nominate Niclas Adlertz (OpenJDK user name: adlertz) to HSX Committer. > > Niclas is a member of the Hotspot Compiler group. He contributed 15 > changesets to HSX project and he is qualified to be committer [1]. See > the end of this email for a list of 8 significant changes. > > Votes are due by Aug. 22, 2013. > > Only current HSX Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Roland Westrelin. > > [1] http://openjdk.java.net/projects/#project-committer > [2] http://openjdk.java.net/census#hsx > [3] http://openjdk.java.net/projects#committer-vote > > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/08d35fd1b599 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/7fa25f5575c9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b274ac1dbe11 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/be4d5c6c1f79 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/8373c19be854 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/705ef39fcaa9 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/573cf206e381 > http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d1034bd8cefc > From staffan.larsen at oracle.com Tue Aug 20 05:38:50 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 20 Aug 2013 14:38:50 +0200 Subject: Request for review: 8020530 Non heap memory size calculated incorrectly In-Reply-To: <52135DA2.4070403@oracle.com> References: <521356A1.9010507@oracle.com> <52135DA2.4070403@oracle.com> Message-ID: <8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com> On 20 aug 2013, at 14:14, David Holmes wrote: > On 20/08/2013 9:44 PM, Vladimir Kempik wrote: >> Hi all, >> >> Could I have a couple of reviews for this change? >> >> http://cr.openjdk.java.net/~vkempik/8020530/webrev.00/ >> >> Running WebLogic server with 1.8.0 encounters this error: >> >> Caused by: java.lang.IllegalArgumentException: committed = 86482944 >> should be < max = 50331648 >> >> at java.lang.management.MemoryUsage.(MemoryUsage.java:162) >> >> at sun.management.MemoryImpl.getMemoryUsage0(Native Method) >> >> at >> sun.management.MemoryImpl.getNonHeapMemoryUsage(MemoryImpl.java:75) >> >> ... 37 more >> >> There is a bug in jmm_GetMemoryUsage here -- if a memory region does not >> define a maximum size, then the total_max is not updated: >> if (u.max_size() == (size_t)-1) { >> has_undefined_max_size = true; >> } >> if (!has_undefined_max_size) { >> total_max += u.max_size(); >> } >> >> It started with JDK version 1.8.0-ea-b97. >> >> In src/share/vm/services/management.cpp: jmm_GetMemoryUsage() there is >> next comment >> >> // if any one of the memory pool has undefined init_size or max_size, >> // set it to -1 >> >> But code doing this is missing, so I've added the code to do exactly >> what comment says. > > That doesn't make a lot of sense to me. Why would a pool have undefined values? The Metaspace pool has no max value (unless you specify -XX:MaxMetaspaceSize=), thus undefined. > If a subset of pools have undefined values why report completely fallacious values of -1? The javadoc for MemoryUsage says getMax() returns -1 if the maximum memory size is undefined. > It also isn't clear how this relates to the "committed" value in the failure. What gets reported now? I guess there can still be a committed value even if we don't have a max value for how much we might commit in the future: used <= committed <= max. /Staffan > > Thanks, > David > >> Thanks, >> Vladimir >> From coleen.phillimore at oracle.com Tue Aug 20 07:43:55 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 20 Aug 2013 10:43:55 -0400 Subject: RFR (S): 8022956: Clang: enable return type warnings on BSD In-Reply-To: <78A98D94-FADF-44D4-9072-6E63265D108C@oracle.com> References: <78A98D94-FADF-44D4-9072-6E63265D108C@oracle.com> Message-ID: <521380AB.2070108@oracle.com> Looks good. Coleen On 08/19/2013 08:30 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8022956/webrev/ > > 8022956: Clang: enable return type warnings on BSD > Reviewed-by: > > While implementing a new feature I noticed that Clang isn't complaining about wrong return types while Sun Studio does. The reason is that we turned it off. Turning it on only needs one small code change (plus a bunch of fixes for Zero). We probably should do the same on Linux but I don't have a Linux machine with Clang installed available. > > make/bsd/makefiles/gcc.make > src/cpu/zero/vm/assembler_zero.cpp > src/cpu/zero/vm/cppInterpreter_zero.cpp > src/cpu/zero/vm/frame_zero.cpp > src/cpu/zero/vm/frame_zero.inline.hpp > src/cpu/zero/vm/icBuffer_zero.cpp > src/cpu/zero/vm/interp_masm_zero.hpp > src/cpu/zero/vm/interpreter_zero.cpp > src/cpu/zero/vm/nativeInst_zero.hpp > src/cpu/zero/vm/register_zero.cpp > src/cpu/zero/vm/relocInfo_zero.cpp > src/cpu/zero/vm/sharedRuntime_zero.cpp > src/cpu/zero/vm/vtableStubs_zero.cpp > src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp > src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp > From staffan.larsen at oracle.com Tue Aug 20 09:44:45 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 20 Aug 2013 18:44:45 +0200 Subject: RFR (S): 8022956: Clang: enable return type warnings on BSD In-Reply-To: <78A98D94-FADF-44D4-9072-6E63265D108C@oracle.com> References: <78A98D94-FADF-44D4-9072-6E63265D108C@oracle.com> Message-ID: <1CBBFDD4-4A77-42F6-AD1F-FA921AB3BB79@oracle.com> Looks good! /Staffan On 20 aug 2013, at 02:30, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8022956/webrev/ > > 8022956: Clang: enable return type warnings on BSD > Reviewed-by: > > While implementing a new feature I noticed that Clang isn't complaining about wrong return types while Sun Studio does. The reason is that we turned it off. Turning it on only needs one small code change (plus a bunch of fixes for Zero). We probably should do the same on Linux but I don't have a Linux machine with Clang installed available. > > make/bsd/makefiles/gcc.make > src/cpu/zero/vm/assembler_zero.cpp > src/cpu/zero/vm/cppInterpreter_zero.cpp > src/cpu/zero/vm/frame_zero.cpp > src/cpu/zero/vm/frame_zero.inline.hpp > src/cpu/zero/vm/icBuffer_zero.cpp > src/cpu/zero/vm/interp_masm_zero.hpp > src/cpu/zero/vm/interpreter_zero.cpp > src/cpu/zero/vm/nativeInst_zero.hpp > src/cpu/zero/vm/register_zero.cpp > src/cpu/zero/vm/relocInfo_zero.cpp > src/cpu/zero/vm/sharedRuntime_zero.cpp > src/cpu/zero/vm/vtableStubs_zero.cpp > src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp > src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp > From christian.thalinger at oracle.com Tue Aug 20 09:46:58 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Aug 2013 09:46:58 -0700 Subject: RFR (S): 8022956: Clang: enable return type warnings on BSD In-Reply-To: <521380AB.2070108@oracle.com> References: <78A98D94-FADF-44D4-9072-6E63265D108C@oracle.com> <521380AB.2070108@oracle.com> Message-ID: <084591C0-B070-48F0-8B04-88676431C13E@oracle.com> Thank you, Coleen. -- Chris On Aug 20, 2013, at 7:43 AM, Coleen Phillimore wrote: > > Looks good. > Coleen > > On 08/19/2013 08:30 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8022956/webrev/ >> >> 8022956: Clang: enable return type warnings on BSD >> Reviewed-by: >> >> While implementing a new feature I noticed that Clang isn't complaining about wrong return types while Sun Studio does. The reason is that we turned it off. Turning it on only needs one small code change (plus a bunch of fixes for Zero). We probably should do the same on Linux but I don't have a Linux machine with Clang installed available. >> >> make/bsd/makefiles/gcc.make >> src/cpu/zero/vm/assembler_zero.cpp >> src/cpu/zero/vm/cppInterpreter_zero.cpp >> src/cpu/zero/vm/frame_zero.cpp >> src/cpu/zero/vm/frame_zero.inline.hpp >> src/cpu/zero/vm/icBuffer_zero.cpp >> src/cpu/zero/vm/interp_masm_zero.hpp >> src/cpu/zero/vm/interpreter_zero.cpp >> src/cpu/zero/vm/nativeInst_zero.hpp >> src/cpu/zero/vm/register_zero.cpp >> src/cpu/zero/vm/relocInfo_zero.cpp >> src/cpu/zero/vm/sharedRuntime_zero.cpp >> src/cpu/zero/vm/vtableStubs_zero.cpp >> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >> src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp >> src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp >> > From bill.pittore at oracle.com Tue Aug 20 09:55:00 2013 From: bill.pittore at oracle.com (bill.pittore at oracle.com) Date: Tue, 20 Aug 2013 12:55:00 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <52002372.2030302@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <52002372.2030302@oracle.com> Message-ID: <52139F64.2050906@oracle.com> I've updated the hotspot and jdk webrevs based on Coleen's and Serguei's comments. http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.03/ http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.02/ thanks, bill On 8/19/2013 1:13 PM, BILL PITTORE wrote: > On 8/5/2013 6:13 PM, Coleen Phillimore wrote: >> >> Hi Bill, I have some high level comments and other comments. This >> wasn't as easy to review as Bob promised me! > :-P >> >> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/src/share/classes/com/sun/tools/attach/VirtualMachine.java.udiff.html >> >> paramter (typo - two instances) >> >> * @throws AgentInitializationException >> - * If the Agent_OnAttach function returns >> an error >> + * If the Agent_OnAttach[_L] function >> returns an error. >> + * an error. >> * > Fixed. >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/os/posix/vm/os_posix.cpp.frames.html >> >> >> nameLen, prefixLen, suffixLen - the JVM coding convention (unlike >> Java) is to have variable names lower case and separated by a _ (not >> camelcase). Same for all the new code here buildAgentFunctionName. > Fixed all names. Original code came from JDK which is why I had this > scheme. >> >> Can you put a function above this function to say what it does? So >> once it's code reviewed, we can quickly know what it does without >> having to study this again - ie. Is name something like libxxx.so >> and you're trying to extract lib and .so from it? There's no >> verification of this at lines 286 and 287 but the code is handling >> the case of other sorts of unexpected input (ie line 283). Why >> don't you strip the lib and the .so if !is_absolute_path? > Added a comment to the above function to describe what's going on. For > absolute path case, the lib_name is something like /a/b/libL.so so we > need to strip off the path, the 'lib' prefix and the '.so' suffix to > get the base name. >> 291 agentEntryName = NEW_C_HEAP_ARRAY(char, len, mtThread); >> 292 if (agentEntryName == NULL) { >> 293 return NULL; >> 294 } >> If NEW_C_HEAP_ARRAY fails it terminates the JVM. I think you might >> want this function instead NEW_C_HEAP_ARRAY_RETURN_NULL if there's a >> reasonable recovery possible. >> > Ok, changed it to the above. >> os_windows.cpp >> >> Same comments as above. Also: >> >> 5432 strncat(agentEntryName, name, nameLen); >> 5433 strcat(agentEntryName, p); >> 5434 //agentEntryName == _Agent_OnLoad_libName at 12 >> 5435 } else { >> You could say why 12 but shouldn't it be the length of the resulting >> symbol instead and not 12? > Changed it to '@XX'. It's really the length of the arguments which > could change in the future, so XX should be fine. >> >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/os.cpp.frames.html >> >> >> findAgentFunction - same comment about the coding conventions. >> functions and variables are lower case with underscores. Class names >> are CamelCase. It would be convenient if the jvm code used the java >> coding convention but the rest of it doesn't so this new code is >> inconsistent. This is hard to follow as it is! >> > Fixed. >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/thread.cpp.frames.html >> >> >> 3826 size_t num_symbol_entries = sizeof(on_unload_symbols) / >> sizeof(char*); >> Why not use ARRAY_SIZE macro? >> > Fixed. >> >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/prims/jvmtiExport.cpp.frames.html >> >> >> 2208 // Check for builtin agent. If not then if the path is >> absolute we attempt >> 2209 // to load the library. Otherwise we try to load it from the >> standard >> 2210 // dll directory. >> I think you are missing the word "found" in this sentence. You are >> using builtin agent to mean agent defined in a statically linked >> library, I believe. Can you say that instead? Builtin means that >> the jvm knows about it and implements it but in this case it doesn't. > Re-worded this to be more explicit about statically linked in >> >> Maybe find_statically_linked_agent() would be a better name for this >> function? > I think builtin came from when we did original JNI builitin libraries. > It might be documented as such in the JEP or CCC. >> >> Is the is_valid() function really mean has_been_loaded()? >> 2236 if (agentLib->valid()) { > Yes, either it was found statically linked into the executable or it > was successfully loaded as a shared lib. >> >> >> Did you run the Internal NSK vm.quick.testlist tests on this to >> verify that nothing breaks? There are a lot of tests with different >> agents and combinations in that suite and it frequently holds some >> surprises in this area so best to run it first. Let me know if you >> need help. > Ran the vm/nsk tests using UTE. Also we have some new test code to > test the statically linked agent functionality. > > Thanks so much for the excellent review. > I'll update the webrev as soon as I rebuild and test. > > bill > >> >> Coleen >> >> On 08/05/2013 10:41 AM, Bob Vandette wrote: >>> On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: >>> >>>> On 8/2/2013 9:12 PM,serguei.spitsyn at oracle.com wrote: >>>>> Hi Bill, >>>>> >>>>> A couple of more questions. >>>>> >>>>> webrev.01/jvmti.html >>>>> >>>>> An agent L whose image has been combined with the VM *is defined* >>>>> as /statically linked/ >>>>> if and only if the agent exports a function called Agent_OnLoad_L. >>>>> >>>>> A question to the above. >>>>> Are we going to allow to link a library dynamically if it exports >>>>> both >>>>> the Agent_OnLoad and Agent_OnLoad_L functions? >>>>> It can be convenient if a library exports both Agent_OnLoad and >>>>> Agent_OnLoad_L >>>>> as it can be linked statically or dynamically depending on the >>>>> need without changes. >>>>> >>>> It would be nice but the problem is that you could only link one >>>> agent into the VM if it exported Agent_OnLoad. Otherwise there >>>> would be a symbol collision with the second agent you linked in >>>> that also had Agent_OnLoad. As an agent developer you will have to >>>> select one or the other at build time, either statically linked in >>>> or dynamic. >>>>> You already added the following statement to the JVMTI spec: >>>>> If a /statically linked/ agent L exports a function called >>>>> Agent_OnLoad_L and >>>>> a function called Agent_OnLoad, the Agent_OnLoad function will >>>>> be ignored. >>>>> >>>>> Could we say it in a shorter form?: >>>>> If a /statically linked/ agent L exports a function called >>>>> Agent_OnLoad, >>>>> the Agent_OnLoad function will be ignored. >>>> I believe I copied this from JNI static linking JEP. If so, I'll >>>> probably leave it as is just for consistency with JNI static spec. >>>> JVM TI static linking spec is closely related to JNI static linking >>>> spec. >>>>> In this context would it be reasonable to add another statement: >>>>> If a /dynamically linked/ agent L exports a function called >>>>> Agent_OnLoad_L, >>>>> the Agent_OnLoad_L function will be ignored. >>>>> >>> I'd rather leave this undefined since the behavior is very platform >>> specific. >>> The way we determine if a library is statically linked is by the >>> presence of the Agent_OnLoad_L function. >>> If this function exists in a dynamically linked library, it will be >>> treated as a static library if by some chance >>> it's attempted to be loaded twice, since the symbol will may be >>> visible in the running process. >>> >>> Bob. >>> >>> >>>>> The same questions apply to the Agent_OnAttach and >>>>> Agent_OnAttach_L entry points. >>>>> >>>> I'm out on vacation for a couple of weeks so I'll leave it up to >>>> Bob V. and yourself if you guys want to hash out better/different >>>> wording. >>>> >>>> bill >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 7/30/13 12:17 PM,bill.pittore at oracle.com wrote: >>>>>> Thanks Serguei for the comments. Some comments inline. I updated >>>>>> the webrevs at >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>>>> >>>>>> >>>>>> >>>>>> On 7/26/2013 5:00 AM,serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Bill, >>>>>>> >>>>>>> Sorry for the big delay. >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>>>> >>>>>>> >>>>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>>>> >>>>>>> >>>>>>> I'm suggesting to use the reference >>>>>>> *Agent_OnAttach[_L]**||* even more consistently. >>>>>>> (If, in some cases, you prefer the longer form to underline the >>>>>>> difference between >>>>>>> dynamically and statically linked libraries then feel free to >>>>>>> leave it as it is.) >>>>>>> >>>>>>> It would simplify the following fragments: >>>>>>> >>>>>>> 304 * It then causes the target VM to invoke the >>>>>>> Agent_OnAttach function >>>>>>> 305 * or, for a statically linked agent named 'L', the >>>>>>> Agent_OnAttach_L function >>>>>>> ==> >>>>>>> >>>>>>> 304 * It then causes the target VM to invoke the >>>>>>> Agent_OnAttach[_L] function >>>>>>> >>>>>>> 409 * It then causes the target VM to invoke the >>>>>>> Agent_OnAttach >>>>>>> 410 * function or, for a statically linked agent named 'L', >>>>>>> the >>>>>>> 411 * Agent_OnAttach_L function as specified >>>>>>> in the >>>>>>> ==> >>>>>>> 409 * It then causes the target VM to invoke the >>>>>>> Agent_OnAttach[_L] >>>>>>> 410 * function as specified in the >>>>>>> >>>>>> I left the above as is since it's part of the method description. >>>>>> The following fragments below I simplified as you suggested. >>>>>> >>>>>>> the following 4 identical fragments: >>>>>>> >>>>>>> 341 * If the Agent_OnAttach >>>>>>> function returns an error >>>>>>> 342 * or, for a statically linked agent named >>>>>>> 'L', if the >>>>>>> 343 * Agent_OnAttach_L function returns >>>>>>> 344 * an error. >>>>>>> 375 * If the Agent_OnAttach >>>>>>> function returns an error >>>>>>> 376 * or, for a statically linked agent named >>>>>>> 'L', if the >>>>>>> 377 * Agent_OnAttach_L function returns >>>>>>> 378 * an error. >>>>>>> 442 * If the Agent_OnAttach >>>>>>> function returns an error >>>>>>> 443 * or, for a statically linked agent named >>>>>>> 'L', if the >>>>>>> 444 * Agent_OnAttach_L function returns an >>>>>>> error >>>>>>> 475 * If the Agent_OnAttach >>>>>>> function returns an error >>>>>>> 476 * or, for a statically linked agent named >>>>>>> 'L', if the >>>>>>> 477 * Agent_OnAttach_L function returns >>>>>>> 478 * an error. >>>>>>> ==> >>>>>>> >>>>>>> 336 * If the Agent_OnAttach[_L] >>>>>>> function returns an error. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>> >>>>>>> src/share/vm/prims/jvmti.xml >>>>>>> >>>>>>> Lines 442-462: many extra

's. The fragment does not look well. >>>>>>> I'd suggest to remove most of them. >>>>>>> Also, these lines are too long. Could you make them shorter, >>>>>>> please? >>>>>>> The same is applied to other long new lines in this file. >>>>>> Cleaned this up a bit. >>>>>>> Lines 490-491, 502-503, 505-506: >>>>>>> The same sentence is repeated 3 times: "the agent library >>>>>>> may be statically linked ..." >>>>>>> >>>>>>> 490 Note that the agent library may be statically linked >>>>>>> into the executable >>>>>>> 491 in which case no actual loading takes place. >>>>>> Fixed. >>>>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is >>>>>>> specified, the VM will attempt to >>>>>>> 502 load the shared library >>>>>>> c:\myLibs\foo.dll. As mentioned above, the agent >>>>>>> library may be statically linked into the executable >>>>>>> 503 in which case no actual loading takes place >>>>>>> >>>>>>> 505 Note that the agent library may be statically linked >>>>>>> into the executable >>>>>>> 506 in which case no actual loading takes place. >>>>>>> >>>>>> Tweaked the above a bit to make it less wordy. >>>>>> >>>>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>>>> >>>>>>> 677 and enabled the event >>>>>>> >>>>>> Fixed. >>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/os/windows/vm/os_windows.cpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/share/vm/prims/jvmtiExport.cpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/share/vm/runtime/arguments.hpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/share/vm/runtime/os.cpp >>>>>>> >>>>>>> Space is missed after the 'if': >>>>>>> 471 if(entryName != NULL) { >>>>>>> >>>>>> Fixed. >>>>>>> Extra space after the '*': >>>>>>> 483 void * saveHandle; >>>>>>> >>>>>> Fixed. >>>>>>> src/share/vm/runtime/os.hpp >>>>>>> >>>>>>> - no comments >>>>>>> >>>>>>> src/share/vm/runtime/thread.cpp >>>>>>> >>>>>>> The line has been removed: >>>>>>> 3866 break; >>>>>>> >>>>>> Correct, the inner for loop was removed so no need for the break; >>>>>>> I'm still in process of reading the code. >>>>>>> Another pass is needed to make sure that nothing is missed. >>>>>>> But in general, the code quality is pretty good. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7/25/13 10:47 AM,bill.pittore at oracle.com wrote: >>>>>>>> Still need an official reviewer for the hotspot changes for >>>>>>>> statically linked agents. >>>>>>>> >>>>>>>> thanks, >>>>>>>> bill >>>>>>>> >>>>>>>>> These changes address bug 8014135 which adds support for >>>>>>>>> statically linked agents in the VM. This is a followup to the >>>>>>>>> recent JNI spec changes that addressed statically linked JNI >>>>>>>>> libraries( 8005716). >>>>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>>>> http://openjdk.java.net/jeps/178 >>>>>>>>> >>>>>>>>> Webrevs are here: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>> >>>>>>>>> The changes to jvmti.xml can also be seen in the output file >>>>>>>>> that I placed here: >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> bill >>>>>>>>> >> > From christian.thalinger at oracle.com Tue Aug 20 10:48:52 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Aug 2013 10:48:52 -0700 Subject: RFR (S): 8022956: Clang: enable return type warnings on BSD In-Reply-To: <1CBBFDD4-4A77-42F6-AD1F-FA921AB3BB79@oracle.com> References: <78A98D94-FADF-44D4-9072-6E63265D108C@oracle.com> <1CBBFDD4-4A77-42F6-AD1F-FA921AB3BB79@oracle.com> Message-ID: <17DC4371-8750-40C9-AA2A-7ACCB791FDCD@oracle.com> Thank you, Staffan. -- Chris On Aug 20, 2013, at 9:44 AM, Staffan Larsen wrote: > Looks good! > > /Staffan > > On 20 aug 2013, at 02:30, Christian Thalinger wrote: > >> http://cr.openjdk.java.net/~twisti/8022956/webrev/ >> >> 8022956: Clang: enable return type warnings on BSD >> Reviewed-by: >> >> While implementing a new feature I noticed that Clang isn't complaining about wrong return types while Sun Studio does. The reason is that we turned it off. Turning it on only needs one small code change (plus a bunch of fixes for Zero). We probably should do the same on Linux but I don't have a Linux machine with Clang installed available. >> >> make/bsd/makefiles/gcc.make >> src/cpu/zero/vm/assembler_zero.cpp >> src/cpu/zero/vm/cppInterpreter_zero.cpp >> src/cpu/zero/vm/frame_zero.cpp >> src/cpu/zero/vm/frame_zero.inline.hpp >> src/cpu/zero/vm/icBuffer_zero.cpp >> src/cpu/zero/vm/interp_masm_zero.hpp >> src/cpu/zero/vm/interpreter_zero.cpp >> src/cpu/zero/vm/nativeInst_zero.hpp >> src/cpu/zero/vm/register_zero.cpp >> src/cpu/zero/vm/relocInfo_zero.cpp >> src/cpu/zero/vm/sharedRuntime_zero.cpp >> src/cpu/zero/vm/vtableStubs_zero.cpp >> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >> src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp >> src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp >> > From vladimir.kozlov at oracle.com Tue Aug 20 11:03:44 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Aug 2013 11:03:44 -0700 Subject: RFR (S): 8022956: Clang: enable return type warnings on BSD In-Reply-To: <78A98D94-FADF-44D4-9072-6E63265D108C@oracle.com> References: <78A98D94-FADF-44D4-9072-6E63265D108C@oracle.com> Message-ID: <5213AF80.7070204@oracle.com> Christian, Can you explain removal of SafeFetch methods in os_bsd_zero.cpp? zero does not generate stubs. Right? Thanks, Vladimir On 8/19/13 5:30 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8022956/webrev/ > > 8022956: Clang: enable return type warnings on BSD > Reviewed-by: > > While implementing a new feature I noticed that Clang isn't complaining about wrong return types while Sun Studio does. The reason is that we turned it off. Turning it on only needs one small code change (plus a bunch of fixes for Zero). We probably should do the same on Linux but I don't have a Linux machine with Clang installed available. > > make/bsd/makefiles/gcc.make > src/cpu/zero/vm/assembler_zero.cpp > src/cpu/zero/vm/cppInterpreter_zero.cpp > src/cpu/zero/vm/frame_zero.cpp > src/cpu/zero/vm/frame_zero.inline.hpp > src/cpu/zero/vm/icBuffer_zero.cpp > src/cpu/zero/vm/interp_masm_zero.hpp > src/cpu/zero/vm/interpreter_zero.cpp > src/cpu/zero/vm/nativeInst_zero.hpp > src/cpu/zero/vm/register_zero.cpp > src/cpu/zero/vm/relocInfo_zero.cpp > src/cpu/zero/vm/sharedRuntime_zero.cpp > src/cpu/zero/vm/vtableStubs_zero.cpp > src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp > src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp > From dmitry.samersoff at oracle.com Tue Aug 20 11:30:25 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 20 Aug 2013 22:30:25 +0400 Subject: Fwd: RR(S): 8009062 poor performance of JNI AttachCurrentThread after fix for 7017193 Message-ID: <5213B5C1.3000705@oracle.com> Hi Everybody, Here is webrev of changes I'm about to integrate: http://cr.openjdk.java.net/~dsamersoff/8009062/webrev.13/ The problem: Under Linux stack of main thread is growable, so we have to make sure that address we plan to put a guard pages to and below is not mapped. Historically we find bounds of the stack of main thread by seeking /proc/self/maps for "[stack]" and parsing this line. But after intensive testing we figured out that it's not required to re-read stack bounds after create_attached_thread() because we are manually grow stack up to the bounds in create_attached_thread() Solution: I use mincore(2) to check whether the page is mapped or not. Typically mincore(2) is used to check whether the page is resides in physical memory or not, but this function returns -1 and set errno to ENOMEM if a region we are asking about contains not mapped memory. Testing: Passed jprt, jck and and couple of ute tests. Wrote special regression test. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From coleen.phillimore at oracle.com Tue Aug 20 11:43:12 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 20 Aug 2013 14:43:12 -0400 Subject: Request for review: 8020530 Non heap memory size calculated incorrectly In-Reply-To: <521356A1.9010507@oracle.com> References: <521356A1.9010507@oracle.com> Message-ID: <5213B8C0.9080403@oracle.com> This looks good. Thanks, Coleen On 08/20/2013 07:44 AM, Vladimir Kempik wrote: > Hi all, > > Could I have a couple of reviews for this change? > > http://cr.openjdk.java.net/~vkempik/8020530/webrev.00/ > > Running WebLogic server with 1.8.0 encounters this error: > > Caused by: java.lang.IllegalArgumentException: committed = 86482944 > should be < max = 50331648 > > at java.lang.management.MemoryUsage.(MemoryUsage.java:162) > > at sun.management.MemoryImpl.getMemoryUsage0(Native Method) > > at > sun.management.MemoryImpl.getNonHeapMemoryUsage(MemoryImpl.java:75) > > ... 37 more > > There is a bug in jmm_GetMemoryUsage here -- if a memory region does > not define a maximum size, then the total_max is not updated: > if (u.max_size() == (size_t)-1) { > has_undefined_max_size = true; > } > if (!has_undefined_max_size) { > total_max += u.max_size(); > } > > It started with JDK version 1.8.0-ea-b97. > > In src/share/vm/services/management.cpp: jmm_GetMemoryUsage() there is > next comment > > // if any one of the memory pool has undefined init_size or max_size, > // set it to -1 > > But code doing this is missing, so I've added the code to do exactly > what comment says. > > Thanks, > Vladimir > From coleen.phillimore at oracle.com Tue Aug 20 11:44:23 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 20 Aug 2013 14:44:23 -0400 Subject: Request for review: 8020530 Non heap memory size calculated incorrectly In-Reply-To: <521356A1.9010507@oracle.com> References: <521356A1.9010507@oracle.com> Message-ID: <5213B907.1060608@oracle.com> Wait... Can you put the comment // if any one of the memory pool has undefined init_size or max_size, // set it to -1 above the lines that you added. They don't make much sense there without it. Coleen On 08/20/2013 07:44 AM, Vladimir Kempik wrote: > Hi all, > > Could I have a couple of reviews for this change? > > http://cr.openjdk.java.net/~vkempik/8020530/webrev.00/ > > Running WebLogic server with 1.8.0 encounters this error: > > Caused by: java.lang.IllegalArgumentException: committed = 86482944 > should be < max = 50331648 > > at java.lang.management.MemoryUsage.(MemoryUsage.java:162) > > at sun.management.MemoryImpl.getMemoryUsage0(Native Method) > > at > sun.management.MemoryImpl.getNonHeapMemoryUsage(MemoryImpl.java:75) > > ... 37 more > > There is a bug in jmm_GetMemoryUsage here -- if a memory region does > not define a maximum size, then the total_max is not updated: > if (u.max_size() == (size_t)-1) { > has_undefined_max_size = true; > } > if (!has_undefined_max_size) { > total_max += u.max_size(); > } > > It started with JDK version 1.8.0-ea-b97. > > In src/share/vm/services/management.cpp: jmm_GetMemoryUsage() there is > next comment > > // if any one of the memory pool has undefined init_size or max_size, > // set it to -1 > > But code doing this is missing, so I've added the code to do exactly > what comment says. > > Thanks, > Vladimir > From christian.thalinger at oracle.com Tue Aug 20 12:01:50 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Aug 2013 12:01:50 -0700 Subject: RFR (S): 8022956: Clang: enable return type warnings on BSD In-Reply-To: <5213AF80.7070204@oracle.com> References: <78A98D94-FADF-44D4-9072-6E63265D108C@oracle.com> <5213AF80.7070204@oracle.com> Message-ID: <49AF463B-5FDE-48B3-AFC8-64FF4338615B@oracle.com> On Aug 20, 2013, at 11:03 AM, Vladimir Kozlov wrote: > Christian, > > Can you explain removal of SafeFetch methods in os_bsd_zero.cpp? zero does not generate stubs. Right? Not in the classic way. SafeFetch32 and SafeFetchN are defined in stubGenerator_zero.cpp and the addresses are assigned to the entries: // Safefetch stubs. StubRoutines::_safefetch32_entry = CAST_FROM_FN_PTR(address, StubGenerator::SafeFetch32); StubRoutines::_safefetch32_fault_pc = NULL; StubRoutines::_safefetch32_continuation_pc = NULL; StubRoutines::_safefetchN_entry = CAST_FROM_FN_PTR(address, StubGenerator::SafeFetchN); StubRoutines::_safefetchN_fault_pc = NULL; StubRoutines::_safefetchN_continuation_pc = NULL; -- Chris > > Thanks, > Vladimir > > On 8/19/13 5:30 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8022956/webrev/ >> >> 8022956: Clang: enable return type warnings on BSD >> Reviewed-by: >> >> While implementing a new feature I noticed that Clang isn't complaining about wrong return types while Sun Studio does. The reason is that we turned it off. Turning it on only needs one small code change (plus a bunch of fixes for Zero). We probably should do the same on Linux but I don't have a Linux machine with Clang installed available. >> >> make/bsd/makefiles/gcc.make >> src/cpu/zero/vm/assembler_zero.cpp >> src/cpu/zero/vm/cppInterpreter_zero.cpp >> src/cpu/zero/vm/frame_zero.cpp >> src/cpu/zero/vm/frame_zero.inline.hpp >> src/cpu/zero/vm/icBuffer_zero.cpp >> src/cpu/zero/vm/interp_masm_zero.hpp >> src/cpu/zero/vm/interpreter_zero.cpp >> src/cpu/zero/vm/nativeInst_zero.hpp >> src/cpu/zero/vm/register_zero.cpp >> src/cpu/zero/vm/relocInfo_zero.cpp >> src/cpu/zero/vm/sharedRuntime_zero.cpp >> src/cpu/zero/vm/vtableStubs_zero.cpp >> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >> src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp >> src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp >> From serguei.spitsyn at oracle.com Tue Aug 20 12:16:58 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 20 Aug 2013 12:16:58 -0700 Subject: Review Request (M) 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments In-Reply-To: References: <51F1BF6E.1080801@oracle.com> <51F5EB62.4050002@oracle.com> <51F70A00.7010505@oracle.com> <51F7317C.5030400@oracle.com> <51F74985.6070905@oracle.com> <51F74AE9.3050603@oracle.com> <51F7F13E.8040104@oracle.com> Message-ID: <5213C0AA.5030706@oracle.com> John, Thank you for the comments! In fact, I was very reluctant to implement it the way as it is in the webrev. I'm in favor of the choice #3, and think, it is much better from the stability point of view. Restoring the MemberName slot at deoptimization is not going to cause a performance degradation. If you and Christian are Ok with it I can file a new compiler bug to cover this issue. Thanks, Serguei On 8/12/13 3:30 PM, John Rose wrote: > This fix will be delicate and may have regressions if the exact code shape (of the PopFrame-ed invokestatic call) changes. > > Note that member_name_arg_or_null assumes that the value in Local#0 is a DMH; there will be asserts thrown if this fails. It also assumes that the member name held by the DMH in fact corresponds to the linker call (linkToStatic, linkToVirtual, etc.) being PopFrame-ed. > > In fact, the linker call might in some cases be run from another source than "aload0; getfield member". Requiring that this correspondence exist always is a new internal interface that is hard to document and verify; it may also inhibit present or future optimizations. > > There are other approaches that might be more robust: > 1. Do not allow PopFrame to linker calls, since they (by definition) throw away their trailing MemberName argument. > 2. Do not make such frames visible to the user. > 3. Modify the linker primitives to store a copy of their trailing MemberName argument to a new slot in the interpreter frame and compiled frame. Be sure to populate this new slot on deoptimization. > > ? John > > P.S. Sorry about the delay in commenting; I am just digging out from under JVMLS business! > > On Jul 30, 2013, at 10:00 AM, serguei.spitsyn at oracle.com wrote: > >> The updated webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.3/ >> >> Thanks, >> Serguei >> >> On 7/29/13 10:11 PM, David Holmes wrote: >>> Hi Serguei, >>> >>> I'm fine with restoring to what was in the first webrev. >>> >>> Further trimming of the JVMTI code is something the embedded folk could look at. It may not be worthwhile. >>> >>> Thanks, >>> David >>> >>> On 30/07/2013 3:05 PM, serguei.spitsyn at oracle.com wrote: >>>> On 7/29/13 8:22 PM, David Holmes wrote: >>>>> On 30/07/2013 10:34 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Christian and David, >>>>>> >>>>>> Thank you for the quick review and comments! >>>>>> >>>>>> This is a new version of webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.2 >>>>>> >>>>> Sorry. You need that guard after all - at least you do if you continue >>>>> to use it in interpreterRuntime - otherwise member_name_arg_or_null >>>>> will not exist: >>>>> >>>>> __ call_VM(rax, CAST_FROM_FN_PTR(address, >>>>> InterpreterRuntime::member_name_arg_or_null), rax, rdx, rsi); >>>>> >>>> You are right, nice catch again. >>>> Probably, it was the reason, I did not remove the #if/#endif in the >>>> first place. :) >>>> >>>>> I'm a little surprised that the assembly code does not have that whole >>>>> section guarded with INCLUDE_JVMTI - perhaps it should? >>>> It should. >>>> But it can be non-trivial because of other dependencies like the above. >>>> To make it right, both _remove_activation_preserving_args_entry and >>>> generate_earlyret_entry_for >>>> must be isolated with #if INCLUDE_JVMTI. >>>> Then more files have to be involved in this chain of changes: >>>> interpreter/templateInterpreter.hpp >>>> interpreter/templateInterpreter.hpp >>>> memory/universe.hpp >>>> memory/universe.cpp >>>> code/codeCache.hpp >>>> code/codeCache.cpp >>>> . . . etc .. >>>> >>>> Please, note, that the HOTSWAP macro is used in many places as well. >>>> I'm not sure we still need it, so that another decision is needed for it. >>>> >>>> So, it seems that this kind of clean up is going far beyond my fix. >>>> My suggestion is to restore the "#if INCLUDE_JVMTI" in 3 >>>> platform-dependent files as it was in the webrev v1. >>>> I'm a little bit reluctant to open another clean-up bug for this issue >>>> but maybe it is needed. >>>> Please, let me know if you are comfortable with this solution. >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> Run this through a JPRT test build for productEmb to check that the >>>>> minimal VM builds ok. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 7/28/13 9:11 PM, David Holmes wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> On 26/07/2013 10:14 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review the fix for: >>>>>>>> bug: http://bugs.sun.com/view_bug.do?bug_id=7187554 >>>>>>>> jbs: https://jbs.oracle.com/bugs/browse/JDK-7187554 >>>>>>>> >>>>>>>> Open webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/7187554-JVMTI-JSR292.1 >>>>>>>> >>>>>>>> >>>>>>> In the templateInterpreter code why did you put this guard on your new >>>>>>> code (from x86_32 version): >>>>>>> >>>>>>> 1923 #if INCLUDE_JVMTI >>>>>>> >>>>>>> when the whole chunk of code this is situated in is specifically for >>>>>>> JVMTI support >>>>>>> >>>>>>> 1824 // >>>>>>> 1825 // JVMTI PopFrame support >>>>>>> 1826 // >>>>>>> >>>>>>> ??? >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Summary: >>>>>>>> Restore the appendix argument of a polymorphic intrinsic call >>>>>>>> needed for a invokestatic re-execution after JVMTI PopFrame(). >>>>>>>> >>>>>>>> Description >>>>>>>> When JVMTI's PopFrame removes a frame that was called via a call >>>>>>>> site >>>>>>>> that >>>>>>>> takes an appendix and that call site is reexecuted the appendix is >>>>>>>> not on >>>>>>>> the stack anymore because it got removed by the adapter. >>>>>>>> This fix is to detect such a case and push the appendix on the >>>>>>>> stack >>>>>>>> again before reexecution. >>>>>>>> >>>>>>>> >>>>>>>> Testing: >>>>>>>> UTE tests - in progress: vm.mlvm.testlist, nsk.jvmti.testlist, >>>>>>>> nsk.jdi.testlist >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei From vladimir.kozlov at oracle.com Tue Aug 20 12:20:00 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Aug 2013 12:20:00 -0700 Subject: RFR (S): 8022956: Clang: enable return type warnings on BSD In-Reply-To: <49AF463B-5FDE-48B3-AFC8-64FF4338615B@oracle.com> References: <78A98D94-FADF-44D4-9072-6E63265D108C@oracle.com> <5213AF80.7070204@oracle.com> <49AF463B-5FDE-48B3-AFC8-64FF4338615B@oracle.com> Message-ID: <5213C160.60006@oracle.com> On 8/20/13 12:01 PM, Christian Thalinger wrote: > > On Aug 20, 2013, at 11:03 AM, Vladimir Kozlov wrote: > >> Christian, >> >> Can you explain removal of SafeFetch methods in os_bsd_zero.cpp? zero does not generate stubs. Right? > > Not in the classic way. SafeFetch32 and SafeFetchN are defined in stubGenerator_zero.cpp and the addresses are assigned to the entries: Okay. thanks, Vladimir > > // Safefetch stubs. > StubRoutines::_safefetch32_entry = CAST_FROM_FN_PTR(address, StubGenerator::SafeFetch32); > StubRoutines::_safefetch32_fault_pc = NULL; > StubRoutines::_safefetch32_continuation_pc = NULL; > > StubRoutines::_safefetchN_entry = CAST_FROM_FN_PTR(address, StubGenerator::SafeFetchN); > StubRoutines::_safefetchN_fault_pc = NULL; > StubRoutines::_safefetchN_continuation_pc = NULL; > > -- Chris > >> >> Thanks, >> Vladimir >> >> On 8/19/13 5:30 PM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/8022956/webrev/ >>> >>> 8022956: Clang: enable return type warnings on BSD >>> Reviewed-by: >>> >>> While implementing a new feature I noticed that Clang isn't complaining about wrong return types while Sun Studio does. The reason is that we turned it off. Turning it on only needs one small code change (plus a bunch of fixes for Zero). We probably should do the same on Linux but I don't have a Linux machine with Clang installed available. >>> >>> make/bsd/makefiles/gcc.make >>> src/cpu/zero/vm/assembler_zero.cpp >>> src/cpu/zero/vm/cppInterpreter_zero.cpp >>> src/cpu/zero/vm/frame_zero.cpp >>> src/cpu/zero/vm/frame_zero.inline.hpp >>> src/cpu/zero/vm/icBuffer_zero.cpp >>> src/cpu/zero/vm/interp_masm_zero.hpp >>> src/cpu/zero/vm/interpreter_zero.cpp >>> src/cpu/zero/vm/nativeInst_zero.hpp >>> src/cpu/zero/vm/register_zero.cpp >>> src/cpu/zero/vm/relocInfo_zero.cpp >>> src/cpu/zero/vm/sharedRuntime_zero.cpp >>> src/cpu/zero/vm/vtableStubs_zero.cpp >>> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp >>> src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp >>> src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp >>> > From vladimir.kozlov at oracle.com Tue Aug 20 14:39:29 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Aug 2013 14:39:29 -0700 Subject: RFR(M): 8020775: PPC64 (part 12): posix signal printing In-Reply-To: <521236FC.8070507@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0CFF7F4F@DEWDFEMB12A.global.corp.sap> <51F2C9D1.60907@oracle.com> <4295855A5C1DE049A61835A1887419CC0D011426@DEWDFEMB12A.global.corp.sap> <520E6BE6.70904@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015F25@DEWDFEMB12A.global.corp.sap> <521236FC.8070507@oracle.com> Message-ID: <5213E211.2030609@oracle.com> Since we have consensus I'm pushing these changes into ppc64/stage repo using JPRT. Thanks, Vladimir On 8/19/13 8:17 AM, Vladimir Kozlov wrote: > On 8/19/13 12:23 AM, Lindenmaier, Goetz wrote: >> Hi Vladimir, >> >> I updated the webrev: >> http://cr.openjdk.java.net/~goetz/webrevs/8020775-print_sig-2/ >> >>> const char* os::Posix::describe_signal_set_short(const sigset_t* set, >>> char* buffer, size_t buf_size) { >> I used your code. > > Thanks. > >> >>> The code in the loop in describe_sa_flags() is incorrect because >>> strlen(p) gives size of all stored sa names. It should be >>> strlen(flaginfo[idx].s). I also don't see why it is while() loop and not >>> simple for(). >> No, the code is correct. p points to the beginning of the recently > > Yes, you are right. > >> printed string. Taking the size of p includes the '|' printed. >> I changed it to a for loop. >> >> From your other mail: >>> It would be nice if you can produce the same alignment in output: >>> >>> SIGSEGV: [libjvm.so+0xc03f0d], sa_mask[0]=1, >>> sa_flags=SA_RESTART|SA_SIGINFO >> >> The alignment of the signals would have to be done in >> print_signal_handler(), which I did not change yet. >> But this also looks like a candidate for moving to >> the posix file. > > It is not big deal, so we can leave it for now. I looked on > print_signal_handler() and it would require several #ifdef in common code. > > Thanks, > Vladimir > >> >> Best regards, >> Goetz. >> >> From mandy.chung at oracle.com Tue Aug 20 14:52:23 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 20 Aug 2013 14:52:23 -0700 Subject: Request for review: 8020530 Non heap memory size calculated incorrectly In-Reply-To: <8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com> References: <521356A1.9010507@oracle.com> <52135DA2.4070403@oracle.com> <8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com> Message-ID: <5213E517.5000106@oracle.com> On 8/20/2013 5:38 AM, Staffan Larsen wrote: > That doesn't make a lot of sense to me. Why would a pool have undefined values? > The Metaspace pool has no max value (unless you specify -XX:MaxMetaspaceSize=), thus undefined. > >> If a subset of pools have undefined values why report completely fallacious values of -1? > The javadoc for MemoryUsage says getMax() returns -1 if the maximum memory size is undefined. Yes the spec allows implementation of memory pools with undefined max. "used" and "committed" must have a value and the "committed" memory is guaranteed to be available for the VM to use. "max" will give an idea of the upper bound how much memory can be allocated from it; however, there is no guarantee that amount of memory is available for the VM. >> It also isn't clear how this relates to the "committed" value in the failure. What gets reported now? > I guess there can still be a committed value even if we don't have a max value for how much we might commit in the future: used <= committed <= max. The MemoryUsage constructor throws IAE if committed > max if max is defined. Perhaps it would be better if max should be Long.MAX_VALUE if undefined (a different issue than this bug). Mandy > /Staffan > >> Thanks, >> David >> >>> Thanks, >>> Vladimir >>> From pbiswal at palantir.com Tue Aug 20 15:05:41 2013 From: pbiswal at palantir.com (Punya Biswal) Date: Tue, 20 Aug 2013 22:05:41 +0000 Subject: JDK7 SIGSEGV with G1 garbage collector Message-ID: [Apologies if this message is delivered twice; I sent it once before I realized this was a members-only list.] We're running into a JVM segfault when using a third-party library (Elasticsearch) alongside the G1 garbage collector. This issue has been reported elsewhere (for example, https://jira.terracotta.org/jira/browse/CDV-1651) and might already be on the OpenJDK roadmap. It's usually associated with the use of GNU Trove. We've been able to reduce the amount of code required to reproduce the crash to a short program that reliably crashes on my computer (a MacBook Pro) using only JDK core classes. I've also included the hs_err_* diagnostic file; both are at https://gist.github.com/punya/6287943 . Does this reduced repro help understand what's going on? A few points of interest: * running with -XX:+UseG1GC -Dcount=100000 always crashes * running with -XX:+UseG1GC -Xint -Dcount=100000 never crashes * running with -Xint -Dcount=100000 never crashes Using -ea and/or -server don't any effect these results. With regard to JVM versions, * it never crashes on JDK 6u51 * it crashes on JDK 7u25 and JDK 7u43 (prerelease) * it never crashes on JDK 8 (prerelease) I'm happy to provide a link to a core dump if that helps. -- Punya Biswal Palantir | Engineer pbiswal at palantir.com | 206 605 2397 From vladimir.kozlov at oracle.com Tue Aug 20 15:06:03 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Aug 2013 15:06:03 -0700 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <52124897.7030304@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> <520D6EEE.1040906@oracle.com> <520DB6B7.2050901@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015CCA@DEWDFEMB12A.global.corp.sap> <520E246F.1060704@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015DAB@DEWDFEMB12A.global.corp.sap> <520EA24F.5060304@oracle.com> <52124897.7030304@oracle.com> Message-ID: <5213E84B.8000101@oracle.com> I looked throw reviews and fount only one not answered question: On 8/15/13 5:14 PM, David Holmes wrote: >> allocation.hpp >> xlC complains: >> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" >> member "StackObj::operator delete(void *)" cannot be accessed. > > Hmmm. So the whole point of these being private was so that they could > not be called but we had to override the use of the global operators. > The concrete implementations then give fatal errors if you do manage to > use them (impossible?). So making them public is undesirable. > > Is there some other way to resolve this? A pragma to tell xlC to ignore > the perceived problem? thanks, Vladimir On 8/19/13 9:32 AM, Vladimir Kozlov wrote: > I tested 8023033-aixShared-2 in JPRT (including builds and tests on ppc > + arm) and it passed without failures. > > Thanks, > Vladimir > > On 8/16/13 3:06 PM, Stefan Karlsson wrote: >> On 8/16/13 11:28 PM, Lindenmaier, Goetz wrote: >>> >>> Hi Stefan, >>> >>> the problem is that globalDefinitions defines __STDC_FORMAT_MACROS. >>> >>> inttypes.hpp comes in through jni.hpp, which is in both, jvm.hpp and >>> >>> globalDefinitions.hpp through globalDefinitions_.hpp. >>> >>> If jvm.hpp comes first, inttype.hpp is added without the macro defined, >>> >>> and the print formats are missing. >>> >>> I could also define __STDC_FORMAT_MACROS in jni.hpp or the like. >>> >>> The name ?globalDefinitions? somehow says that the definitions should >>> be seen >>> >>> everywhere ? so it?s basically bad that the file does not end up at >>> the top of the include >>> >>> chain. Maybe I should include it in jni.hpp? or jvm.hpp? >>> >>> What do you think? >>> >> >> I see your problem. >> >> I think the most stable solution would be to add -D__STDC_FORMAT_MACROS >> to the compiler flags. >> >> But that seems out-of-scope for this change, so go ahead and use the >> reordering for now (unless someone else complains). >> >> thanks, >> StefanK >> >>> Best regards, >>> >>> Goetz. >>> >>> *From:*Stefan Karlsson [mailto:stefan.karlsson at oracle.com] >>> *Sent:* Friday, August 16, 2013 3:09 PM >>> *To:* Lindenmaier, Goetz >>> *Cc:* 'Vladimir Kozlov'; 'David Holmes'; >>> 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> *Subject:* Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX >>> >>> Hi Goetz, >>> >>> On 8/16/13 2:21 PM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> >>> >>> - I removed the throw() >>> >>> - I removed the #ifndef in port.hpp >>> >>> - I fixed the typeo. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-2/ >>> >>> >>> >>> >>> I always build without precompiled headers, the nightbuild with >>> >>> them. >>> >>> >>> utilities/debug.hpp.udiff.html >>> >>> -#include "prims/jvm.h" >>> #include "utilities/globalDefinitions.hpp" >>> +#include "prims/jvm.h" >>> >>> I don't think your change to debug.hpp is the correct way to solve >>> the problems you were seeing with metaspace.hpp. Swapping the files >>> just means that someone else might hit the same problem adding >>> prims/jvm.hpp to another file. >>> >>> >>> You probably have a circular include dependency somewhere in the >>> code. Could you revert the change to utilities/debug.hpp and try to >>> figure out what the real problem is? >>> >>> thanks, >>> StefanK >>> >>> >>> >>> >>> >>> >>> Yes, there will be makefiles for aix, and the platform files. >>> tTe prototype >>> >>> patches are here >>> >>> >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0014_aix_make_changes.patch >>> >>> >>> >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0015_aix_ppc_files.patch >>> >>> >>> >>> >>> But the make change contains mostly new files, except for >>> >>> >>> >>> --- a/make/defs.make Tue Jul 23 21:07:11 2013 +0200 >>> >>> +++ b/make/defs.make Tue Jul 23 22:13:05 2013 +0200 >>> >>> @@ -166,11 +166,15 @@ >>> >>> HOST := $(shell uname -n) >>> >>> endif >>> >>> >>> >>> -# If not SunOS, not Linux and not BSD, assume Windows >>> >>> +# If not SunOS, not Linux not BSD and not AIX, assume Windows >>> >>> ifneq ($(OS), Linux) >>> >>> ifneq ($(OS), SunOS) >>> >>> ifneq ($(OS), bsd) >>> >>> - OSNAME=windows >>> >>> + ifneq ($(OS), AIX) >>> >>> + OSNAME=windows >>> >>> + else >>> >>> + OSNAME=aix >>> >>> + endif >>> >>> else >>> >>> OSNAME=bsd >>> >>> endif >>> >>> >>> >>> >>> >>> Best regards, >>> >>> Goetz >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> >>> Sent: Friday, August 16, 2013 7:21 AM >>> >>> To: David Holmes >>> >>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net >>> ';'hotspot-dev at openjdk.java.net >>> ' >>> >>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for >>> AIX >>> >>> >>> >>> I thought trow() was added long time ago. But it was added, I >>> think by accident, very recently: >>> >>> >>> >>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a7fb14888912 >>> >>> >>> >>> I missed it when I did the review of those changes. >>> >>> >>> >>> We should remove throw. >>> >>> >>> >>> Vladimir >>> >>> >>> >>> On 8/15/13 5:14 PM, David Holmes wrote: >>> >>> On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: >>> >>> On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: >>> >>> Hi Vladimir, >>> >>> >>> >>> throw is needed because it`s there in the >>> implementation in nmethod.cpp. >>> >>> (So you are using it a bit at least :)) >>> >>> xlc says >>> >>> "nmethod.cpp", line 802.7: 1540-0400 (S) >>> "nmethod::operator >>> >>> new(size_t, int)" has a conflicting declaration. >>> >>> "nmethod.hpp", line 268.9: 1540-0424 (I) "operator >>> new" is declared on >>> >>> line 268 of "nmethod.hpp". >>> >>> >>> >>> Okay, it is just declaration. >>> >>> >>> >>> Why do we have throw here: >>> >>> >>> >>> void* nmethod::operator new(size_t size, int nmethod_size) >>> throw () { >>> >>> // Not critical, may return null if there is too little >>> continuous memory >>> >>> return CodeCache::allocate(nmethod_size); >>> >>> } >>> >>> >>> >>> Seems to me it should be removed if anything. >>> >>> >>> >>> David >>> >>> ----- >>> >>> >>> >>> >>> >>> >>> >>> int64 is defined correctly, uint64 is not defined, >>> but never used in >>> >>> hotspot. >>> >>> I can not reproduce an error, but that's rather old >>> coding from our VM. >>> >>> We also switched from xlc8 to xlc10 in the course of >>> this project. >>> >>> I will test some more and talk to the person who >>> implemented that >>> >>> tomorrow, >>> >>> and if possible remove the change. >>> >>> >>> >>> Okay, I will test it also. >>> >>> >>> >>> Vladimir >>> >>> >>> >>> >>> >>> Best regards & thanks for the review, >>> >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: Vladimir Kozlov >>> [mailto:vladimir.kozlov at oracle.com] >>> >>> Sent: Thursday, August 15, 2013 5:52 PM >>> >>> To: Lindenmaier, Goetz >>> >>> Cc: 'hotspot-dev at openjdk.java.net >>> ';ppc-aix-port-dev at openjdk.java.net >>> ; >>> >>> Albert Noll (albert.noll at oracle.com >>> ) >>> >>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic >>> changes for AIX >>> >>> >>> >>> Goetz, >>> >>> >>> >>> I only see 2 problems which you did not explain: >>> >>> >>> >>> nmethod.hpp. Why the next change? we don't use C++ >>> exceptions: >>> >>> >>> >>> - void* operator new(size_t size, int nmethod_size); >>> >>> + void* operator new(size_t size, int nmethod_size) >>> throw (); >>> >>> >>> >>> port.hpp. Did AIX has the same definitions for jlong >>> and julong?: >>> >>> >>> >>> +#ifndef _AIX >>> >>> +// These conflict with /usr/include/sys/inttypes.h >>> on aix. >>> >>> typedef jlong int64; // Java long for >>> my 64-bit type >>> >>> typedef julong uint64; // Java long for >>> my 64-bit type >>> >>> +#endif >>> >>> >>> >>> >>> >>> And of cause we need to test these changes with >>> compilers we use. >>> >>> >>> >>> Thanks, >>> >>> Vladimir >>> >>> >>> >>> On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> >>> >>> I prepared a webrev for >>> >>> 8023033: PPC64 (part 13): basic changes for AIX >>> >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >>> >>> >>> >>> >>> This contains the basic shared changes needed for >>> the AIX port, >>> >>> as there are >>> >>> - #includes >>> >>> - Fixes to get the code compiling with xlC/on AIX >>> >>> - Basic adaptions as in vm_version.cpp. >>> >>> >>> >>> It also determines the placement and naming of >>> the aix files, >>> >>> which will go to os/aix and os_cpu/aix_ppc, as >>> you can see in >>> >>> >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >>> >>> >>> >>> >>> >>> >>> Some details about the compilation problems: >>> >>> >>> >>> relocInfo.hpp: >>> >>> xlC wants initialization in inline implementation. >>> >>> >>> >>> vmreg.hpp: >>> >>> BAD is defined in AIX system header sys/param.h. >>> Renamed. >>> >>> >>> >>> allocation.hpp >>> >>> xlC complains: >>> >>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 >>> (S) The "private" >>> >>> member "StackObj::operator delete(void *)" cannot >>> be accessed. >>> >>> >>> >>> sharedRuntimeTrig.cpp >>> >>> Aix defines hz to be 100, see sys/m_param.h. >>> Renamed. >>> >>> >>> >>> debug.hpp >>> >>> With other include order we get a lot of >>> >>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) >>> "PRIuPTR" is not >>> >>> declared. >>> >>> >>> >>> >>> >>> Please review and test this change. Comments are >>> welcome. >>> >>> >>> >>> Thanks and best regards, >>> >>> Goetz. >>> >>> >>> >> From vladimir.kozlov at oracle.com Tue Aug 20 15:10:35 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Aug 2013 15:10:35 -0700 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <5213E84B.8000101@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> <520D6EEE.1040906@oracle.com> <520DB6B7.2050901@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015CCA@DEWDFEMB12A.global.corp.sap> <520E246F.1060704@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015DAB@DEWDFEMB12A.global.corp.sap> <520EA24F.5060304@oracle.com> <52124897.7030304@oracle.com> <5213E84B.8000101@oracle.com> Message-ID: <5213E95B.2090805@oracle.com> On 8/20/13 3:06 PM, Vladimir Kozlov wrote: > I looked throw reviews and fount only one not answered question: ^ through :) > > On 8/15/13 5:14 PM, David Holmes wrote: > >> allocation.hpp > >> xlC complains: > >> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" > >> member "StackObj::operator delete(void *)" cannot be accessed. > > > > Hmmm. So the whole point of these being private was so that they could > > not be called but we had to override the use of the global operators. > > The concrete implementations then give fatal errors if you do manage to > > use them (impossible?). So making them public is undesirable. > > > > Is there some other way to resolve this? A pragma to tell xlC to ignore > > the perceived problem? > > thanks, > Vladimir > > On 8/19/13 9:32 AM, Vladimir Kozlov wrote: >> I tested 8023033-aixShared-2 in JPRT (including builds and tests on ppc >> + arm) and it passed without failures. >> >> Thanks, >> Vladimir >> >> On 8/16/13 3:06 PM, Stefan Karlsson wrote: >>> On 8/16/13 11:28 PM, Lindenmaier, Goetz wrote: >>>> >>>> Hi Stefan, >>>> >>>> the problem is that globalDefinitions defines __STDC_FORMAT_MACROS. >>>> >>>> inttypes.hpp comes in through jni.hpp, which is in both, jvm.hpp and >>>> >>>> globalDefinitions.hpp through globalDefinitions_.hpp. >>>> >>>> If jvm.hpp comes first, inttype.hpp is added without the macro defined, >>>> >>>> and the print formats are missing. >>>> >>>> I could also define __STDC_FORMAT_MACROS in jni.hpp or the like. >>>> >>>> The name ?globalDefinitions? somehow says that the definitions should >>>> be seen >>>> >>>> everywhere ? so it?s basically bad that the file does not end up at >>>> the top of the include >>>> >>>> chain. Maybe I should include it in jni.hpp? or jvm.hpp? >>>> >>>> What do you think? >>>> >>> >>> I see your problem. >>> >>> I think the most stable solution would be to add -D__STDC_FORMAT_MACROS >>> to the compiler flags. >>> >>> But that seems out-of-scope for this change, so go ahead and use the >>> reordering for now (unless someone else complains). >>> >>> thanks, >>> StefanK >>> >>>> Best regards, >>>> >>>> Goetz. >>>> >>>> *From:*Stefan Karlsson [mailto:stefan.karlsson at oracle.com] >>>> *Sent:* Friday, August 16, 2013 3:09 PM >>>> *To:* Lindenmaier, Goetz >>>> *Cc:* 'Vladimir Kozlov'; 'David Holmes'; >>>> 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>>> *Subject:* Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX >>>> >>>> Hi Goetz, >>>> >>>> On 8/16/13 2:21 PM, Lindenmaier, Goetz wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> - I removed the throw() >>>> >>>> - I removed the #ifndef in port.hpp >>>> >>>> - I fixed the typeo. >>>> >>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-2/ >>>> >>>> >>>> >>>> >>>> I always build without precompiled headers, the nightbuild with >>>> >>>> them. >>>> >>>> >>>> utilities/debug.hpp.udiff.html >>>> >>>> -#include "prims/jvm.h" >>>> #include "utilities/globalDefinitions.hpp" >>>> +#include "prims/jvm.h" >>>> >>>> I don't think your change to debug.hpp is the correct way to solve >>>> the problems you were seeing with metaspace.hpp. Swapping the files >>>> just means that someone else might hit the same problem adding >>>> prims/jvm.hpp to another file. >>>> >>>> >>>> You probably have a circular include dependency somewhere in the >>>> code. Could you revert the change to utilities/debug.hpp and try to >>>> figure out what the real problem is? >>>> >>>> thanks, >>>> StefanK >>>> >>>> >>>> >>>> >>>> >>>> >>>> Yes, there will be makefiles for aix, and the platform files. >>>> tTe prototype >>>> >>>> patches are here >>>> >>>> >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0014_aix_make_changes.patch >>>> >>>> >>>> >>>> >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0015_aix_ppc_files.patch >>>> >>>> >>>> >>>> >>>> >>>> But the make change contains mostly new files, except for >>>> >>>> >>>> >>>> --- a/make/defs.make Tue Jul 23 21:07:11 2013 +0200 >>>> >>>> +++ b/make/defs.make Tue Jul 23 22:13:05 2013 +0200 >>>> >>>> @@ -166,11 +166,15 @@ >>>> >>>> HOST := $(shell uname -n) >>>> >>>> endif >>>> >>>> >>>> >>>> -# If not SunOS, not Linux and not BSD, assume Windows >>>> >>>> +# If not SunOS, not Linux not BSD and not AIX, assume Windows >>>> >>>> ifneq ($(OS), Linux) >>>> >>>> ifneq ($(OS), SunOS) >>>> >>>> ifneq ($(OS), bsd) >>>> >>>> - OSNAME=windows >>>> >>>> + ifneq ($(OS), AIX) >>>> >>>> + OSNAME=windows >>>> >>>> + else >>>> >>>> + OSNAME=aix >>>> >>>> + endif >>>> >>>> else >>>> >>>> OSNAME=bsd >>>> >>>> endif >>>> >>>> >>>> >>>> >>>> >>>> Best regards, >>>> >>>> Goetz >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> >>>> Sent: Friday, August 16, 2013 7:21 AM >>>> >>>> To: David Holmes >>>> >>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net >>>> ';'hotspot-dev at openjdk.java.net >>>> >>>> ' >>>> >>>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for >>>> AIX >>>> >>>> >>>> >>>> I thought trow() was added long time ago. But it was added, I >>>> think by accident, very recently: >>>> >>>> >>>> >>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a7fb14888912 >>>> >>>> >>>> >>>> I missed it when I did the review of those changes. >>>> >>>> >>>> >>>> We should remove throw. >>>> >>>> >>>> >>>> Vladimir >>>> >>>> >>>> >>>> On 8/15/13 5:14 PM, David Holmes wrote: >>>> >>>> On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: >>>> >>>> On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: >>>> >>>> Hi Vladimir, >>>> >>>> >>>> >>>> throw is needed because it`s there in the >>>> implementation in nmethod.cpp. >>>> >>>> (So you are using it a bit at least :)) >>>> >>>> xlc says >>>> >>>> "nmethod.cpp", line 802.7: 1540-0400 (S) >>>> "nmethod::operator >>>> >>>> new(size_t, int)" has a conflicting declaration. >>>> >>>> "nmethod.hpp", line 268.9: 1540-0424 (I) "operator >>>> new" is declared on >>>> >>>> line 268 of "nmethod.hpp". >>>> >>>> >>>> >>>> Okay, it is just declaration. >>>> >>>> >>>> >>>> Why do we have throw here: >>>> >>>> >>>> >>>> void* nmethod::operator new(size_t size, int nmethod_size) >>>> throw () { >>>> >>>> // Not critical, may return null if there is too little >>>> continuous memory >>>> >>>> return CodeCache::allocate(nmethod_size); >>>> >>>> } >>>> >>>> >>>> >>>> Seems to me it should be removed if anything. >>>> >>>> >>>> >>>> David >>>> >>>> ----- >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> int64 is defined correctly, uint64 is not defined, >>>> but never used in >>>> >>>> hotspot. >>>> >>>> I can not reproduce an error, but that's rather old >>>> coding from our VM. >>>> >>>> We also switched from xlc8 to xlc10 in the course of >>>> this project. >>>> >>>> I will test some more and talk to the person who >>>> implemented that >>>> >>>> tomorrow, >>>> >>>> and if possible remove the change. >>>> >>>> >>>> >>>> Okay, I will test it also. >>>> >>>> >>>> >>>> Vladimir >>>> >>>> >>>> >>>> >>>> >>>> Best regards & thanks for the review, >>>> >>>> Goetz. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> From: Vladimir Kozlov >>>> [mailto:vladimir.kozlov at oracle.com] >>>> >>>> Sent: Thursday, August 15, 2013 5:52 PM >>>> >>>> To: Lindenmaier, Goetz >>>> >>>> Cc: 'hotspot-dev at openjdk.java.net >>>> ';ppc-aix-port-dev at openjdk.java.net >>>> >>>> ; >>>> >>>> Albert Noll (albert.noll at oracle.com >>>> ) >>>> >>>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic >>>> changes for AIX >>>> >>>> >>>> >>>> Goetz, >>>> >>>> >>>> >>>> I only see 2 problems which you did not explain: >>>> >>>> >>>> >>>> nmethod.hpp. Why the next change? we don't use C++ >>>> exceptions: >>>> >>>> >>>> >>>> - void* operator new(size_t size, int nmethod_size); >>>> >>>> + void* operator new(size_t size, int nmethod_size) >>>> throw (); >>>> >>>> >>>> >>>> port.hpp. Did AIX has the same definitions for jlong >>>> and julong?: >>>> >>>> >>>> >>>> +#ifndef _AIX >>>> >>>> +// These conflict with /usr/include/sys/inttypes.h >>>> on aix. >>>> >>>> typedef jlong int64; // Java long for >>>> my 64-bit type >>>> >>>> typedef julong uint64; // Java long for >>>> my 64-bit type >>>> >>>> +#endif >>>> >>>> >>>> >>>> >>>> >>>> And of cause we need to test these changes with >>>> compilers we use. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Vladimir >>>> >>>> >>>> >>>> On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> I prepared a webrev for >>>> >>>> 8023033: PPC64 (part 13): basic changes for AIX >>>> >>>> >>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >>>> >>>> >>>> >>>> >>>> This contains the basic shared changes needed for >>>> the AIX port, >>>> >>>> as there are >>>> >>>> - #includes >>>> >>>> - Fixes to get the code compiling with xlC/on AIX >>>> >>>> - Basic adaptions as in vm_version.cpp. >>>> >>>> >>>> >>>> It also determines the placement and naming of >>>> the aix files, >>>> >>>> which will go to os/aix and os_cpu/aix_ppc, as >>>> you can see in >>>> >>>> >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Some details about the compilation problems: >>>> >>>> >>>> >>>> relocInfo.hpp: >>>> >>>> xlC wants initialization in inline implementation. >>>> >>>> >>>> >>>> vmreg.hpp: >>>> >>>> BAD is defined in AIX system header sys/param.h. >>>> Renamed. >>>> >>>> >>>> >>>> allocation.hpp >>>> >>>> xlC complains: >>>> >>>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 >>>> (S) The "private" >>>> >>>> member "StackObj::operator delete(void *)" cannot >>>> be accessed. >>>> >>>> >>>> >>>> sharedRuntimeTrig.cpp >>>> >>>> Aix defines hz to be 100, see sys/m_param.h. >>>> Renamed. >>>> >>>> >>>> >>>> debug.hpp >>>> >>>> With other include order we get a lot of >>>> >>>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) >>>> "PRIuPTR" is not >>>> >>>> declared. >>>> >>>> >>>> >>>> >>>> >>>> Please review and test this change. Comments are >>>> welcome. >>>> >>>> >>>> >>>> Thanks and best regards, >>>> >>>> Goetz. >>>> >>>> >>>> >>> From serguei.spitsyn at oracle.com Tue Aug 20 15:42:57 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 20 Aug 2013 15:42:57 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <52139F64.2050906@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <52002372.2030302@oracle.com> <52139F64.2050906@oracle.com> Message-ID: <5213F0F1.4020800@oracle.com> Hi Bill, It looks good in general. Some minor comments. src/share/classes/com/sun/tools/attach/VirtualMachine.java The copyright comment is out-of-date || src/os/posix/vm/os_posix.cpp symName => sym_name src/os/windows/vm/os_windows.cpp 5454 //agent_entry_name == _Agent_OnLoad_libName at XX Need a space after // ||src/share/vm/prims/jvmti.xml The copyright comment is out-of-date. The lines are too long: 520-523, 584, 593, 623, 654, 660, 679, 689. src/share/vm/prims/jvmtiExport.cpp src/share/vm/runtime/arguments.hpp No comments ||src/share/vm/runtime/os.cpp The indentation is incorrect: 456 const char *syms[], size_t syms_len) { The comments are cross-inconsistent (lib_name vs libname): 447 * Support for finding Agent_On(Un)Load/Attach<_lib_name> if it exists. . . . 449 * Agent_OnLoad_lib_name or Agent_OnAttach_lib_name function to determine if . . . 491 // Check for Agent_OnLoad/Attach_libname function . . . 498 // Found an entry point like Agent_OnLoad_libname so we have a static agent ||src/share/vm/runtime/os.hpp 542 // return the handle of this process 543 static void* get_default_process_handle(); 544 545 // Check for static linked agent library 546 static bool find_builtin_agent(AgentLibrary *agent_lib, const char *syms[], 547 size_t syms_len); 548 549 // Find agent entry point 550 static void *find_agent_function(AgentLibrary *agent_lib, bool check_lib, 551 const char *syms[], size_t syms_len); The comment at the line #542 should start from capital letter. Wrong indentation at the lines: #547, #551. ||src/share/vm/runtime/thread.cpp Wrong indentation: 3748 on_load_entry = CAST_TO_FN_PTR(OnLoadEntry_t, os::find_agent_function(agent, 3749 false, 3750 on_load_symbols, 3751 num_symbol_entries)); Thanks, Serguei On 8/20/13 9:55 AM, bill.pittore at oracle.com wrote: > I've updated the hotspot and jdk webrevs based on Coleen's and > Serguei's comments. > > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.03/ > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.02/ > > thanks, > bill > > > On 8/19/2013 1:13 PM, BILL PITTORE wrote: >> On 8/5/2013 6:13 PM, Coleen Phillimore wrote: >>> >>> Hi Bill, I have some high level comments and other comments. This >>> wasn't as easy to review as Bob promised me! >> :-P >>> >>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/src/share/classes/com/sun/tools/attach/VirtualMachine.java.udiff.html >>> >>> paramter (typo - two instances) >>> >>> * @throws AgentInitializationException >>> - * If the Agent_OnAttach function returns >>> an error >>> + * If the Agent_OnAttach[_L] function >>> returns an error. >>> + * an error. >>> * >> Fixed. >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/os/posix/vm/os_posix.cpp.frames.html >>> >>> >>> nameLen, prefixLen, suffixLen - the JVM coding convention (unlike >>> Java) is to have variable names lower case and separated by a _ (not >>> camelcase). Same for all the new code here buildAgentFunctionName. >> Fixed all names. Original code came from JDK which is why I had this >> scheme. >>> >>> Can you put a function above this function to say what it does? So >>> once it's code reviewed, we can quickly know what it does without >>> having to study this again - ie. Is name something like libxxx.so >>> and you're trying to extract lib and .so from it? There's no >>> verification of this at lines 286 and 287 but the code is handling >>> the case of other sorts of unexpected input (ie line 283). Why >>> don't you strip the lib and the .so if !is_absolute_path? >> Added a comment to the above function to describe what's going on. >> For absolute path case, the lib_name is something like /a/b/libL.so >> so we need to strip off the path, the 'lib' prefix and the '.so' >> suffix to get the base name. >>> 291 agentEntryName = NEW_C_HEAP_ARRAY(char, len, mtThread); >>> 292 if (agentEntryName == NULL) { >>> 293 return NULL; >>> 294 } >>> If NEW_C_HEAP_ARRAY fails it terminates the JVM. I think you might >>> want this function instead NEW_C_HEAP_ARRAY_RETURN_NULL if there's a >>> reasonable recovery possible. >>> >> Ok, changed it to the above. >>> os_windows.cpp >>> >>> Same comments as above. Also: >>> >>> 5432 strncat(agentEntryName, name, nameLen); >>> 5433 strcat(agentEntryName, p); >>> 5434 //agentEntryName == _Agent_OnLoad_libName at 12 >>> 5435 } else { >>> You could say why 12 but shouldn't it be the length of the resulting >>> symbol instead and not 12? >> Changed it to '@XX'. It's really the length of the arguments which >> could change in the future, so XX should be fine. >>> >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/os.cpp.frames.html >>> >>> >>> findAgentFunction - same comment about the coding conventions. >>> functions and variables are lower case with underscores. Class names >>> are CamelCase. It would be convenient if the jvm code used the java >>> coding convention but the rest of it doesn't so this new code is >>> inconsistent. This is hard to follow as it is! >>> >> Fixed. >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/thread.cpp.frames.html >>> >>> >>> 3826 size_t num_symbol_entries = sizeof(on_unload_symbols) / >>> sizeof(char*); >>> Why not use ARRAY_SIZE macro? >>> >> Fixed. >>> >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/prims/jvmtiExport.cpp.frames.html >>> >>> >>> 2208 // Check for builtin agent. If not then if the path is >>> absolute we attempt >>> 2209 // to load the library. Otherwise we try to load it from the >>> standard >>> 2210 // dll directory. >>> I think you are missing the word "found" in this sentence. You are >>> using builtin agent to mean agent defined in a statically linked >>> library, I believe. Can you say that instead? Builtin means that >>> the jvm knows about it and implements it but in this case it doesn't. >> Re-worded this to be more explicit about statically linked in >>> >>> Maybe find_statically_linked_agent() would be a better name for this >>> function? >> I think builtin came from when we did original JNI builitin >> libraries. It might be documented as such in the JEP or CCC. >>> >>> Is the is_valid() function really mean has_been_loaded()? >>> 2236 if (agentLib->valid()) { >> Yes, either it was found statically linked into the executable or it >> was successfully loaded as a shared lib. >>> >>> >>> Did you run the Internal NSK vm.quick.testlist tests on this to >>> verify that nothing breaks? There are a lot of tests with different >>> agents and combinations in that suite and it frequently holds some >>> surprises in this area so best to run it first. Let me know if you >>> need help. >> Ran the vm/nsk tests using UTE. Also we have some new test code to >> test the statically linked agent functionality. >> >> Thanks so much for the excellent review. >> I'll update the webrev as soon as I rebuild and test. >> >> bill >> >>> >>> Coleen >>> >>> On 08/05/2013 10:41 AM, Bob Vandette wrote: >>>> On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: >>>> >>>>> On 8/2/2013 9:12 PM,serguei.spitsyn at oracle.com wrote: >>>>>> Hi Bill, >>>>>> >>>>>> A couple of more questions. >>>>>> >>>>>> webrev.01/jvmti.html >>>>>> >>>>>> An agent L whose image has been combined with the VM *is defined* >>>>>> as /statically linked/ >>>>>> if and only if the agent exports a function called Agent_OnLoad_L. >>>>>> >>>>>> A question to the above. >>>>>> Are we going to allow to link a library dynamically if it exports >>>>>> both >>>>>> the Agent_OnLoad and Agent_OnLoad_L functions? >>>>>> It can be convenient if a library exports both Agent_OnLoad and >>>>>> Agent_OnLoad_L >>>>>> as it can be linked statically or dynamically depending on the >>>>>> need without changes. >>>>>> >>>>> It would be nice but the problem is that you could only link one >>>>> agent into the VM if it exported Agent_OnLoad. Otherwise there >>>>> would be a symbol collision with the second agent you linked in >>>>> that also had Agent_OnLoad. As an agent developer you will have to >>>>> select one or the other at build time, either statically linked in >>>>> or dynamic. >>>>>> You already added the following statement to the JVMTI spec: >>>>>> If a /statically linked/ agent L exports a function called >>>>>> Agent_OnLoad_L and >>>>>> a function called Agent_OnLoad, the Agent_OnLoad function will >>>>>> be ignored. >>>>>> >>>>>> Could we say it in a shorter form?: >>>>>> If a /statically linked/ agent L exports a function called >>>>>> Agent_OnLoad, >>>>>> the Agent_OnLoad function will be ignored. >>>>> I believe I copied this from JNI static linking JEP. If so, I'll >>>>> probably leave it as is just for consistency with JNI static spec. >>>>> JVM TI static linking spec is closely related to JNI static >>>>> linking spec. >>>>>> In this context would it be reasonable to add another statement: >>>>>> If a /dynamically linked/ agent L exports a function called >>>>>> Agent_OnLoad_L, >>>>>> the Agent_OnLoad_L function will be ignored. >>>>>> >>>> I'd rather leave this undefined since the behavior is very platform >>>> specific. >>>> The way we determine if a library is statically linked is by the >>>> presence of the Agent_OnLoad_L function. >>>> If this function exists in a dynamically linked library, it will be >>>> treated as a static library if by some chance >>>> it's attempted to be loaded twice, since the symbol will may be >>>> visible in the running process. >>>> >>>> Bob. >>>> >>>> >>>>>> The same questions apply to the Agent_OnAttach and >>>>>> Agent_OnAttach_L entry points. >>>>>> >>>>> I'm out on vacation for a couple of weeks so I'll leave it up to >>>>> Bob V. and yourself if you guys want to hash out better/different >>>>> wording. >>>>> >>>>> bill >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 7/30/13 12:17 PM,bill.pittore at oracle.com wrote: >>>>>>> Thanks Serguei for the comments. Some comments inline. I updated >>>>>>> the webrevs at >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7/26/2013 5:00 AM,serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Bill, >>>>>>>> >>>>>>>> Sorry for the big delay. >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>>>>> >>>>>>>> >>>>>>>> I'm suggesting to use the reference >>>>>>>> *Agent_OnAttach[_L]**||* even more consistently. >>>>>>>> (If, in some cases, you prefer the longer form to underline the >>>>>>>> difference between >>>>>>>> dynamically and statically linked libraries then feel free to >>>>>>>> leave it as it is.) >>>>>>>> >>>>>>>> It would simplify the following fragments: >>>>>>>> >>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>> Agent_OnAttach function >>>>>>>> 305 * or, for a statically linked agent named 'L', the >>>>>>>> Agent_OnAttach_L function >>>>>>>> ==> >>>>>>>> >>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>> Agent_OnAttach[_L] function >>>>>>>> >>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>> Agent_OnAttach >>>>>>>> 410 * function or, for a statically linked agent named >>>>>>>> 'L', the >>>>>>>> 411 * Agent_OnAttach_L function as specified >>>>>>>> in the >>>>>>>> ==> >>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>> Agent_OnAttach[_L] >>>>>>>> 410 * function as specified in the >>>>>>>> >>>>>>> I left the above as is since it's part of the method >>>>>>> description. The following fragments below I simplified as you >>>>>>> suggested. >>>>>>> >>>>>>>> the following 4 identical fragments: >>>>>>>> >>>>>>>> 341 * If the Agent_OnAttach >>>>>>>> function returns an error >>>>>>>> 342 * or, for a statically linked agent named >>>>>>>> 'L', if the >>>>>>>> 343 * Agent_OnAttach_L function returns >>>>>>>> 344 * an error. >>>>>>>> 375 * If the Agent_OnAttach >>>>>>>> function returns an error >>>>>>>> 376 * or, for a statically linked agent named >>>>>>>> 'L', if the >>>>>>>> 377 * Agent_OnAttach_L function returns >>>>>>>> 378 * an error. >>>>>>>> 442 * If the Agent_OnAttach >>>>>>>> function returns an error >>>>>>>> 443 * or, for a statically linked agent named >>>>>>>> 'L', if the >>>>>>>> 444 * Agent_OnAttach_L function returns an >>>>>>>> error >>>>>>>> 475 * If the Agent_OnAttach >>>>>>>> function returns an error >>>>>>>> 476 * or, for a statically linked agent named >>>>>>>> 'L', if the >>>>>>>> 477 * Agent_OnAttach_L function returns >>>>>>>> 478 * an error. >>>>>>>> ==> >>>>>>>> >>>>>>>> 336 * If the Agent_OnAttach[_L] >>>>>>>> function returns an error. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>> >>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>> >>>>>>>> Lines 442-462: many extra

's. The fragment does not look >>>>>>>> well. >>>>>>>> I'd suggest to remove most of them. >>>>>>>> Also, these lines are too long. Could you make them shorter, >>>>>>>> please? >>>>>>>> The same is applied to other long new lines in this file. >>>>>>> Cleaned this up a bit. >>>>>>>> Lines 490-491, 502-503, 505-506: >>>>>>>> The same sentence is repeated 3 times: "the agent library >>>>>>>> may be statically linked ..." >>>>>>>> >>>>>>>> 490 Note that the agent library may be statically linked >>>>>>>> into the executable >>>>>>>> 491 in which case no actual loading takes place. >>>>>>> Fixed. >>>>>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is >>>>>>>> specified, the VM will attempt to >>>>>>>> 502 load the shared library >>>>>>>> c:\myLibs\foo.dll. As mentioned above, the agent >>>>>>>> library may be statically linked into the executable >>>>>>>> 503 in which case no actual loading takes place >>>>>>>> >>>>>>>> 505 Note that the agent library may be statically linked >>>>>>>> into the executable >>>>>>>> 506 in which case no actual loading takes place. >>>>>>>> >>>>>>> Tweaked the above a bit to make it less wordy. >>>>>>> >>>>>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>>>>> >>>>>>>> 677 and enabled the event >>>>>>>> >>>>>>> Fixed. >>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>> >>>>>>>> - no comments >>>>>>>> >>>>>>>> src/os/windows/vm/os_windows.cpp >>>>>>>> >>>>>>>> - no comments >>>>>>>> >>>>>>>> src/share/vm/prims/jvmtiExport.cpp >>>>>>>> >>>>>>>> - no comments >>>>>>>> >>>>>>>> src/share/vm/runtime/arguments.hpp >>>>>>>> >>>>>>>> - no comments >>>>>>>> >>>>>>>> src/share/vm/runtime/os.cpp >>>>>>>> >>>>>>>> Space is missed after the 'if': >>>>>>>> 471 if(entryName != NULL) { >>>>>>>> >>>>>>> Fixed. >>>>>>>> Extra space after the '*': >>>>>>>> 483 void * saveHandle; >>>>>>>> >>>>>>> Fixed. >>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>> >>>>>>>> - no comments >>>>>>>> >>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>> >>>>>>>> The line has been removed: >>>>>>>> 3866 break; >>>>>>>> >>>>>>> Correct, the inner for loop was removed so no need for the break; >>>>>>>> I'm still in process of reading the code. >>>>>>>> Another pass is needed to make sure that nothing is missed. >>>>>>>> But in general, the code quality is pretty good. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 7/25/13 10:47 AM,bill.pittore at oracle.com wrote: >>>>>>>>> Still need an official reviewer for the hotspot changes for >>>>>>>>> statically linked agents. >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> bill >>>>>>>>> >>>>>>>>>> These changes address bug 8014135 which adds support for >>>>>>>>>> statically linked agents in the VM. This is a followup to the >>>>>>>>>> recent JNI spec changes that addressed statically linked JNI >>>>>>>>>> libraries( 8005716). >>>>>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>>>>> http://openjdk.java.net/jeps/178 >>>>>>>>>> >>>>>>>>>> Webrevs are here: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>>> >>>>>>>>>> The changes to jvmti.xml can also be seen in the output file >>>>>>>>>> that I placed here: >>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> bill >>>>>>>>>> >>> >> > > From bill.pittore at oracle.com Tue Aug 20 18:18:15 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Tue, 20 Aug 2013 21:18:15 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <5213F0F1.4020800@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <52002372.2030302@oracle.com> <52139F64.2050906@oracle.com> <5213F0F1.4020800@oracle.com> Message-ID: <52141557.3020300@oracle.com> Thanks Serguei for the detailed review. I think I captured all the tweaks you mentioned and have new webrevs at: http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.03/ http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.04/ also you can find the jvmti.html output file at http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.03/jvmti.html and the javadoc from VirtualMachine.java at: http://cr.openjdk.java.net/~bpittore/8014135/javadoc/ bill On 8/20/2013 6:42 PM, serguei.spitsyn at oracle.com wrote: > Hi Bill, > > It looks good in general. > > Some minor comments. > > src/share/classes/com/sun/tools/attach/VirtualMachine.java > > The copyright comment is out-of-date > > > || src/os/posix/vm/os_posix.cpp > > symName => sym_name > > src/os/windows/vm/os_windows.cpp > > 5454 //agent_entry_name == _Agent_OnLoad_libName at XX > > Need a space after // > > ||src/share/vm/prims/jvmti.xml > > The copyright comment is out-of-date. > The lines are too long: 520-523, 584, 593, 623, 654, 660, 679, 689. > > src/share/vm/prims/jvmtiExport.cpp > src/share/vm/runtime/arguments.hpp > > No comments > > ||src/share/vm/runtime/os.cpp > > The indentation is incorrect: > 456 const char *syms[], size_t syms_len) { > > The comments are cross-inconsistent (lib_name vs libname): > > 447 * Support for finding Agent_On(Un)Load/Attach<_lib_name> if it exists. > . . . > 449 * Agent_OnLoad_lib_name or Agent_OnAttach_lib_name function to determine if > . . . > 491 // Check for Agent_OnLoad/Attach_libname function > . . . > 498 // Found an entry point like Agent_OnLoad_libname so we have a static agent > > ||src/share/vm/runtime/os.hpp > > 542 // return the handle of this process > 543 static void* get_default_process_handle(); > 544 > 545 // Check for static linked agent library > 546 static bool find_builtin_agent(AgentLibrary *agent_lib, const char *syms[], > 547 size_t syms_len); > 548 > 549 // Find agent entry point > 550 static void *find_agent_function(AgentLibrary *agent_lib, bool check_lib, > 551 const char *syms[], size_t syms_len); The comment at the line #542 should start from capital letter. > Wrong indentation at the lines: #547, #551. > > ||src/share/vm/runtime/thread.cpp > > Wrong indentation: > 3748 on_load_entry = CAST_TO_FN_PTR(OnLoadEntry_t, os::find_agent_function(agent, > 3749 false, > 3750 on_load_symbols, > 3751 num_symbol_entries)); > > > Thanks, > Serguei > > On 8/20/13 9:55 AM, bill.pittore at oracle.com wrote: >> I've updated the hotspot and jdk webrevs based on Coleen's and >> Serguei's comments. >> >> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.03/ >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.02/ >> >> thanks, >> bill >> >> >> On 8/19/2013 1:13 PM, BILL PITTORE wrote: >>> On 8/5/2013 6:13 PM, Coleen Phillimore wrote: >>>> >>>> Hi Bill, I have some high level comments and other comments. This >>>> wasn't as easy to review as Bob promised me! >>> :-P >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/src/share/classes/com/sun/tools/attach/VirtualMachine.java.udiff.html >>>> >>>> paramter (typo - two instances) >>>> >>>> * @throws AgentInitializationException >>>> - * If the Agent_OnAttach function >>>> returns an error >>>> + * If the Agent_OnAttach[_L] function >>>> returns an error. >>>> + * an error. >>>> * >>> Fixed. >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/os/posix/vm/os_posix.cpp.frames.html >>>> >>>> >>>> nameLen, prefixLen, suffixLen - the JVM coding convention (unlike >>>> Java) is to have variable names lower case and separated by a _ >>>> (not camelcase). Same for all the new code here >>>> buildAgentFunctionName. >>> Fixed all names. Original code came from JDK which is why I had this >>> scheme. >>>> >>>> Can you put a function above this function to say what it does? So >>>> once it's code reviewed, we can quickly know what it does without >>>> having to study this again - ie. Is name something like libxxx.so >>>> and you're trying to extract lib and .so from it? There's no >>>> verification of this at lines 286 and 287 but the code is handling >>>> the case of other sorts of unexpected input (ie line 283). Why >>>> don't you strip the lib and the .so if !is_absolute_path? >>> Added a comment to the above function to describe what's going on. >>> For absolute path case, the lib_name is something like /a/b/libL.so >>> so we need to strip off the path, the 'lib' prefix and the '.so' >>> suffix to get the base name. >>>> 291 agentEntryName = NEW_C_HEAP_ARRAY(char, len, mtThread); >>>> 292 if (agentEntryName == NULL) { >>>> 293 return NULL; >>>> 294 } >>>> If NEW_C_HEAP_ARRAY fails it terminates the JVM. I think you >>>> might want this function instead NEW_C_HEAP_ARRAY_RETURN_NULL if >>>> there's a reasonable recovery possible. >>>> >>> Ok, changed it to the above. >>>> os_windows.cpp >>>> >>>> Same comments as above. Also: >>>> >>>> 5432 strncat(agentEntryName, name, nameLen); >>>> 5433 strcat(agentEntryName, p); >>>> 5434 //agentEntryName == _Agent_OnLoad_libName at 12 >>>> 5435 } else { >>>> You could say why 12 but shouldn't it be the length of the >>>> resulting symbol instead and not 12? >>> Changed it to '@XX'. It's really the length of the arguments which >>> could change in the future, so XX should be fine. >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/os.cpp.frames.html >>>> >>>> >>>> findAgentFunction - same comment about the coding conventions. >>>> functions and variables are lower case with underscores. Class >>>> names are CamelCase. It would be convenient if the jvm code used >>>> the java coding convention but the rest of it doesn't so this new >>>> code is inconsistent. This is hard to follow as it is! >>>> >>> Fixed. >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/thread.cpp.frames.html >>>> >>>> >>>> 3826 size_t num_symbol_entries = sizeof(on_unload_symbols) / >>>> sizeof(char*); >>>> Why not use ARRAY_SIZE macro? >>>> >>> Fixed. >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/prims/jvmtiExport.cpp.frames.html >>>> >>>> >>>> 2208 // Check for builtin agent. If not then if the path is >>>> absolute we attempt >>>> 2209 // to load the library. Otherwise we try to load it from the >>>> standard >>>> 2210 // dll directory. >>>> I think you are missing the word "found" in this sentence. You are >>>> using builtin agent to mean agent defined in a statically linked >>>> library, I believe. Can you say that instead? Builtin means that >>>> the jvm knows about it and implements it but in this case it doesn't. >>> Re-worded this to be more explicit about statically linked in >>>> >>>> Maybe find_statically_linked_agent() would be a better name for >>>> this function? >>> I think builtin came from when we did original JNI builitin >>> libraries. It might be documented as such in the JEP or CCC. >>>> >>>> Is the is_valid() function really mean has_been_loaded()? >>>> 2236 if (agentLib->valid()) { >>> Yes, either it was found statically linked into the executable or it >>> was successfully loaded as a shared lib. >>>> >>>> >>>> Did you run the Internal NSK vm.quick.testlist tests on this to >>>> verify that nothing breaks? There are a lot of tests with >>>> different agents and combinations in that suite and it frequently >>>> holds some surprises in this area so best to run it first. Let me >>>> know if you need help. >>> Ran the vm/nsk tests using UTE. Also we have some new test code to >>> test the statically linked agent functionality. >>> >>> Thanks so much for the excellent review. >>> I'll update the webrev as soon as I rebuild and test. >>> >>> bill >>> >>>> >>>> Coleen >>>> >>>> On 08/05/2013 10:41 AM, Bob Vandette wrote: >>>>> On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: >>>>> >>>>>> On 8/2/2013 9:12 PM,serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Bill, >>>>>>> >>>>>>> A couple of more questions. >>>>>>> >>>>>>> webrev.01/jvmti.html >>>>>>> >>>>>>> An agent L whose image has been combined with the VM *is >>>>>>> defined* as /statically linked/ >>>>>>> if and only if the agent exports a function called Agent_OnLoad_L. >>>>>>> >>>>>>> A question to the above. >>>>>>> Are we going to allow to link a library dynamically if it >>>>>>> exports both >>>>>>> the Agent_OnLoad and Agent_OnLoad_L functions? >>>>>>> It can be convenient if a library exports both Agent_OnLoad and >>>>>>> Agent_OnLoad_L >>>>>>> as it can be linked statically or dynamically depending on the >>>>>>> need without changes. >>>>>>> >>>>>> It would be nice but the problem is that you could only link one >>>>>> agent into the VM if it exported Agent_OnLoad. Otherwise there >>>>>> would be a symbol collision with the second agent you linked in >>>>>> that also had Agent_OnLoad. As an agent developer you will have >>>>>> to select one or the other at build time, either statically >>>>>> linked in or dynamic. >>>>>>> You already added the following statement to the JVMTI spec: >>>>>>> If a /statically linked/ agent L exports a function called >>>>>>> Agent_OnLoad_L and >>>>>>> a function called Agent_OnLoad, the Agent_OnLoad function will >>>>>>> be ignored. >>>>>>> >>>>>>> Could we say it in a shorter form?: >>>>>>> If a /statically linked/ agent L exports a function called >>>>>>> Agent_OnLoad, >>>>>>> the Agent_OnLoad function will be ignored. >>>>>> I believe I copied this from JNI static linking JEP. If so, I'll >>>>>> probably leave it as is just for consistency with JNI static >>>>>> spec. JVM TI static linking spec is closely related to JNI static >>>>>> linking spec. >>>>>>> In this context would it be reasonable to add another statement: >>>>>>> If a /dynamically linked/ agent L exports a function called >>>>>>> Agent_OnLoad_L, >>>>>>> the Agent_OnLoad_L function will be ignored. >>>>>>> >>>>> I'd rather leave this undefined since the behavior is very >>>>> platform specific. >>>>> The way we determine if a library is statically linked is by the >>>>> presence of the Agent_OnLoad_L function. >>>>> If this function exists in a dynamically linked library, it will >>>>> be treated as a static library if by some chance >>>>> it's attempted to be loaded twice, since the symbol will may be >>>>> visible in the running process. >>>>> >>>>> Bob. >>>>> >>>>> >>>>>>> The same questions apply to the Agent_OnAttach and >>>>>>> Agent_OnAttach_L entry points. >>>>>>> >>>>>> I'm out on vacation for a couple of weeks so I'll leave it up to >>>>>> Bob V. and yourself if you guys want to hash out better/different >>>>>> wording. >>>>>> >>>>>> bill >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 7/30/13 12:17 PM,bill.pittore at oracle.com wrote: >>>>>>>> Thanks Serguei for the comments. Some comments inline. I >>>>>>>> updated the webrevs at >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 7/26/2013 5:00 AM,serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Bill, >>>>>>>>> >>>>>>>>> Sorry for the big delay. >>>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm suggesting to use the reference >>>>>>>>> *Agent_OnAttach[_L]**||* even more consistently. >>>>>>>>> (If, in some cases, you prefer the longer form to underline >>>>>>>>> the difference between >>>>>>>>> dynamically and statically linked libraries then feel free to >>>>>>>>> leave it as it is.) >>>>>>>>> >>>>>>>>> It would simplify the following fragments: >>>>>>>>> >>>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>>> Agent_OnAttach function >>>>>>>>> 305 * or, for a statically linked agent named 'L', the >>>>>>>>> Agent_OnAttach_L function >>>>>>>>> ==> >>>>>>>>> >>>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>>> Agent_OnAttach[_L] function >>>>>>>>> >>>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>>> Agent_OnAttach >>>>>>>>> 410 * function or, for a statically linked agent named >>>>>>>>> 'L', the >>>>>>>>> 411 * Agent_OnAttach_L function as specified >>>>>>>>> in the >>>>>>>>> ==> >>>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>>> Agent_OnAttach[_L] >>>>>>>>> 410 * function as specified in the >>>>>>>>> >>>>>>>> I left the above as is since it's part of the method >>>>>>>> description. The following fragments below I simplified as you >>>>>>>> suggested. >>>>>>>> >>>>>>>>> the following 4 identical fragments: >>>>>>>>> >>>>>>>>> 341 * If the Agent_OnAttach >>>>>>>>> function returns an error >>>>>>>>> 342 * or, for a statically linked agent named >>>>>>>>> 'L', if the >>>>>>>>> 343 * Agent_OnAttach_L function returns >>>>>>>>> 344 * an error. >>>>>>>>> 375 * If the Agent_OnAttach >>>>>>>>> function returns an error >>>>>>>>> 376 * or, for a statically linked agent named >>>>>>>>> 'L', if the >>>>>>>>> 377 * Agent_OnAttach_L function returns >>>>>>>>> 378 * an error. >>>>>>>>> 442 * If the Agent_OnAttach >>>>>>>>> function returns an error >>>>>>>>> 443 * or, for a statically linked agent named >>>>>>>>> 'L', if the >>>>>>>>> 444 * Agent_OnAttach_L function returns an >>>>>>>>> error >>>>>>>>> 475 * If the Agent_OnAttach >>>>>>>>> function returns an error >>>>>>>>> 476 * or, for a statically linked agent named >>>>>>>>> 'L', if the >>>>>>>>> 477 * Agent_OnAttach_L function returns >>>>>>>>> 478 * an error. >>>>>>>>> ==> >>>>>>>>> >>>>>>>>> 336 * If the Agent_OnAttach[_L] >>>>>>>>> function returns an error. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>> >>>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>>> >>>>>>>>> Lines 442-462: many extra

's. The fragment does not look >>>>>>>>> well. >>>>>>>>> I'd suggest to remove most of them. >>>>>>>>> Also, these lines are too long. Could you make them shorter, >>>>>>>>> please? >>>>>>>>> The same is applied to other long new lines in this file. >>>>>>>> Cleaned this up a bit. >>>>>>>>> Lines 490-491, 502-503, 505-506: >>>>>>>>> The same sentence is repeated 3 times: "the agent library >>>>>>>>> may be statically linked ..." >>>>>>>>> >>>>>>>>> 490 Note that the agent library may be statically linked >>>>>>>>> into the executable >>>>>>>>> 491 in which case no actual loading takes place. >>>>>>>> Fixed. >>>>>>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is >>>>>>>>> specified, the VM will attempt to >>>>>>>>> 502 load the shared library >>>>>>>>> c:\myLibs\foo.dll. As mentioned above, the agent >>>>>>>>> library may be statically linked into the executable >>>>>>>>> 503 in which case no actual loading takes place >>>>>>>>> >>>>>>>>> 505 Note that the agent library may be statically linked >>>>>>>>> into the executable >>>>>>>>> 506 in which case no actual loading takes place. >>>>>>>>> >>>>>>>> Tweaked the above a bit to make it less wordy. >>>>>>>> >>>>>>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>>>>>> >>>>>>>>> 677 and enabled the event >>>>>>>>> >>>>>>>> Fixed. >>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>> >>>>>>>>> - no comments >>>>>>>>> >>>>>>>>> src/os/windows/vm/os_windows.cpp >>>>>>>>> >>>>>>>>> - no comments >>>>>>>>> >>>>>>>>> src/share/vm/prims/jvmtiExport.cpp >>>>>>>>> >>>>>>>>> - no comments >>>>>>>>> >>>>>>>>> src/share/vm/runtime/arguments.hpp >>>>>>>>> >>>>>>>>> - no comments >>>>>>>>> >>>>>>>>> src/share/vm/runtime/os.cpp >>>>>>>>> >>>>>>>>> Space is missed after the 'if': >>>>>>>>> 471 if(entryName != NULL) { >>>>>>>>> >>>>>>>> Fixed. >>>>>>>>> Extra space after the '*': >>>>>>>>> 483 void * saveHandle; >>>>>>>>> >>>>>>>> Fixed. >>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>> >>>>>>>>> - no comments >>>>>>>>> >>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>> >>>>>>>>> The line has been removed: >>>>>>>>> 3866 break; >>>>>>>>> >>>>>>>> Correct, the inner for loop was removed so no need for the break; >>>>>>>>> I'm still in process of reading the code. >>>>>>>>> Another pass is needed to make sure that nothing is missed. >>>>>>>>> But in general, the code quality is pretty good. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/25/13 10:47 AM,bill.pittore at oracle.com wrote: >>>>>>>>>> Still need an official reviewer for the hotspot changes for >>>>>>>>>> statically linked agents. >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> bill >>>>>>>>>> >>>>>>>>>>> These changes address bug 8014135 which adds support for >>>>>>>>>>> statically linked agents in the VM. This is a followup to >>>>>>>>>>> the recent JNI spec changes that addressed statically linked >>>>>>>>>>> JNI libraries( 8005716). >>>>>>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>>>>>> http://openjdk.java.net/jeps/178 >>>>>>>>>>> >>>>>>>>>>> Webrevs are here: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> The changes to jvmti.xml can also be seen in the output file >>>>>>>>>>> that I placed here: >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> bill >>>>>>>>>>> >>>> >>> >> >> > From bengt.rutisson at oracle.com Tue Aug 20 23:52:01 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 21 Aug 2013 08:52:01 +0200 Subject: JDK7 SIGSEGV with G1 garbage collector In-Reply-To: References: Message-ID: <52146391.1090807@oracle.com> Hi Punya, Thank you for the excellent bug report! I cloned the test case and can reproduce the issue both with 7u25 build 15 (that you used) and also with the latest build of JDK8. I'll dig some more into what is going on and file a bug. Will ping this thread when I have more information. Bengt On 8/21/13 12:05 AM, Punya Biswal wrote: > [Apologies if this message is delivered twice; I sent it once before I > realized this was a members-only list.] > > We're running into a JVM segfault when using a third-party library > (Elasticsearch) alongside the G1 garbage collector. This issue has been > reported elsewhere (for example, > https://jira.terracotta.org/jira/browse/CDV-1651) and might already be on > the OpenJDK roadmap. It's usually associated with the use of GNU Trove. > > We've been able to reduce the amount of code required to reproduce the > crash to a short program that reliably crashes on my computer > (a MacBook Pro) using only JDK core classes. I've also included the > hs_err_* diagnostic file; both are at > https://gist.github.com/punya/6287943 . > > Does this reduced repro help understand what's going on? > > > A few points of interest: > > * running with -XX:+UseG1GC -Dcount=100000 always crashes > * running with -XX:+UseG1GC -Xint -Dcount=100000 never crashes > * running with -Xint -Dcount=100000 never crashes > > > Using -ea and/or -server don't any effect these results. With regard to > JVM versions, > > * it never crashes on JDK 6u51 > * it crashes on JDK 7u25 and JDK 7u43 (prerelease) > * it never crashes on JDK 8 (prerelease) > > > I'm happy to provide a link to a core dump if that helps. > > -- > Punya Biswal > Palantir | Engineer > pbiswal at palantir.com | 206 605 2397 From staffan.larsen at oracle.com Wed Aug 21 02:32:30 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 21 Aug 2013 11:32:30 +0200 Subject: RFR: 8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__" In-Reply-To: <3476F401-E6AF-44C3-871E-62F2681DC8D9@oracle.com> References: <3476F401-E6AF-44C3-871E-62F2681DC8D9@oracle.com> Message-ID: <5C3EFB1A-C718-4F3E-8896-BF4F60A2294D@oracle.com> Looks good. /Staffan On 12 aug 2013, at 14:51, Peter Allwin wrote: > Hello! > > This patch addresses several Nashorn compatibility issues with in sa.js and is a merge of my patch [0] and Kris' (kmo) [1] which were developed separately. > > The merged change is identical to [1] with except for line 785 where I've added a conversion to JavaScript String to ensure the correct replace method is called. > > > webrev: http://cr.openjdk.java.net/~allwin/8011888/webrev.01/ > bug: http://bugs.sun.com/view_bug.do?bug_id=8011888 > > > Thanks! > /Peter > > > [0] http://cr.openjdk.java.net/~allwin/8011888/webrev.00/ > [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-July/010831.html > From vladimir.kempik at oracle.com Wed Aug 21 03:40:27 2013 From: vladimir.kempik at oracle.com (Vladimir Kempik) Date: Wed, 21 Aug 2013 14:40:27 +0400 Subject: Request for review: 8020530 Non heap memory size calculated incorrectly In-Reply-To: <5213E517.5000106@oracle.com> References: <521356A1.9010507@oracle.com> <52135DA2.4070403@oracle.com> <8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com> <5213E517.5000106@oracle.com> Message-ID: <5214991B.40107@oracle.com> Thanks everyone for comments. Here is updated webrev http://cr.openjdk.java.net/~vkempik/8020530/webrev.01/ Vladimir. On 21.08.2013 1:52, Mandy Chung wrote: > > On 8/20/2013 5:38 AM, Staffan Larsen wrote: >> That doesn't make a lot of sense to me. Why would a pool have >> undefined values? >> The Metaspace pool has no max value (unless you specify >> -XX:MaxMetaspaceSize=), thus undefined. >> >>> If a subset of pools have undefined values why report completely >>> fallacious values of -1? >> The javadoc for MemoryUsage says getMax() returns -1 if the maximum >> memory size is undefined. > > Yes the spec allows implementation of memory pools with undefined > max. "used" and "committed" must have a value and the "committed" > memory is guaranteed to be available for the VM to use. "max" will > give an idea of the upper bound how much memory can be allocated from > it; however, there is no guarantee that amount of memory is available > for the VM. > >>> It also isn't clear how this relates to the "committed" value in the >>> failure. What gets reported now? >> I guess there can still be a committed value even if we don't have a >> max value for how much we might commit in the future: used <= >> committed <= max. > > The MemoryUsage constructor throws IAE if committed > max if max is > defined. Perhaps it would be better if max should be Long.MAX_VALUE > if undefined (a different issue than this bug). > > Mandy > >> /Staffan >> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Vladimir >>>> > From staffan.larsen at oracle.com Wed Aug 21 04:32:28 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 21 Aug 2013 13:32:28 +0200 Subject: Request for review: 8020530 Non heap memory size calculated incorrectly In-Reply-To: <5214991B.40107@oracle.com> References: <521356A1.9010507@oracle.com> <52135DA2.4070403@oracle.com> <8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com> <5213E517.5000106@oracle.com> <5214991B.40107@oracle.com> Message-ID: <89095DA6-FE7B-45D9-873A-B323BD561060@oracle.com> Still good. Thanks, /Staffan On 21 aug 2013, at 12:40, Vladimir Kempik wrote: > Thanks everyone for comments. > > Here is updated webrev http://cr.openjdk.java.net/~vkempik/8020530/webrev.01/ > > Vladimir. > On 21.08.2013 1:52, Mandy Chung wrote: >> >> On 8/20/2013 5:38 AM, Staffan Larsen wrote: >>> That doesn't make a lot of sense to me. Why would a pool have undefined values? >>> The Metaspace pool has no max value (unless you specify -XX:MaxMetaspaceSize=), thus undefined. >>> >>>> If a subset of pools have undefined values why report completely fallacious values of -1? >>> The javadoc for MemoryUsage says getMax() returns -1 if the maximum memory size is undefined. >> >> Yes the spec allows implementation of memory pools with undefined max. "used" and "committed" must have a value and the "committed" memory is guaranteed to be available for the VM to use. "max" will give an idea of the upper bound how much memory can be allocated from it; however, there is no guarantee that amount of memory is available for the VM. >> >>>> It also isn't clear how this relates to the "committed" value in the failure. What gets reported now? >>> I guess there can still be a committed value even if we don't have a max value for how much we might commit in the future: used <= committed <= max. >> >> The MemoryUsage constructor throws IAE if committed > max if max is defined. Perhaps it would be better if max should be Long.MAX_VALUE if undefined (a different issue than this bug). >> >> Mandy >> >>> /Staffan >>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >> > From dmitry.samersoff at oracle.com Wed Aug 21 04:37:45 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 21 Aug 2013 15:37:45 +0400 Subject: Request for review: 8020530 Non heap memory size calculated incorrectly In-Reply-To: <5214991B.40107@oracle.com> References: <521356A1.9010507@oracle.com> <52135DA2.4070403@oracle.com> <8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com> <5213E517.5000106@oracle.com> <5214991B.40107@oracle.com> Message-ID: <5214A689.7050908@oracle.com> Looks good for me. On 2013-08-21 14:40, Vladimir Kempik wrote: > Thanks everyone for comments. > > Here is updated webrev > http://cr.openjdk.java.net/~vkempik/8020530/webrev.01/ > > Vladimir. > On 21.08.2013 1:52, Mandy Chung wrote: >> >> On 8/20/2013 5:38 AM, Staffan Larsen wrote: >>> That doesn't make a lot of sense to me. Why would a pool have >>> undefined values? >>> The Metaspace pool has no max value (unless you specify >>> -XX:MaxMetaspaceSize=), thus undefined. >>> >>>> If a subset of pools have undefined values why report completely >>>> fallacious values of -1? >>> The javadoc for MemoryUsage says getMax() returns -1 if the maximum >>> memory size is undefined. >> >> Yes the spec allows implementation of memory pools with undefined >> max. "used" and "committed" must have a value and the "committed" >> memory is guaranteed to be available for the VM to use. "max" will >> give an idea of the upper bound how much memory can be allocated from >> it; however, there is no guarantee that amount of memory is available >> for the VM. >> >>>> It also isn't clear how this relates to the "committed" value in the >>>> failure. What gets reported now? >>> I guess there can still be a committed value even if we don't have a >>> max value for how much we might commit in the future: used <= >>> committed <= max. >> >> The MemoryUsage constructor throws IAE if committed > max if max is >> defined. Perhaps it would be better if max should be Long.MAX_VALUE >> if undefined (a different issue than this bug). >> >> Mandy >> >>> /Staffan >>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From goetz.lindenmaier at sap.com Wed Aug 21 05:35:24 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 21 Aug 2013 12:35:24 +0000 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <5213E84B.8000101@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> <520D6EEE.1040906@oracle.com> <520DB6B7.2050901@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015CCA@DEWDFEMB12A.global.corp.sap> <520E246F.1060704@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015DAB@DEWDFEMB12A.global.corp.sap> <520EA24F.5060304@oracle.com> <52124897.7030304@oracle.com> <5213E84B.8000101@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D01681B@DEWDFEMB12A.global.corp.sap> Hi, I don't have another workaround at hand right now. The problem is that there are public destructors in subclasses of StackObj which has the private delete operator. I shrinked the problem to a minimal test program and addressed the issue to our IBM compiler contacts. The minimal change that makes the sources compile is --- a/src/share/vm/memory/allocation.hpp Fri Jul 26 00:59:18 2013 +0200 +++ b/src/share/vm/memory/allocation.hpp Wed Aug 21 10:30:58 2013 +0200 @@ -218,7 +218,8 @@ class StackObj ALLOCATION_SUPER_CLASS_SPEC { private: void* operator new(size_t size); + void* operator new [](size_t size); + public: void operator delete(void* p); - void* operator new [](size_t size); void operator delete [](void* p); }; I.e., make only the delete operators public. VALUE_OBJ_CLASS_SPEC is defined empty on aix, so the fix in _ValueObj is currently not essential. I would appreciate if you can push the change with this fix, so we can get to the point where we can compile on aix soon. If I get a workaround like a pragma, I will undo this. Best regards, Goetz. // xlC 10 and 12 can not compile this program: // "test.cpp", line 12.3: 1540-0300 (S) The "private" member "A::operator delete(void *)" cannot be accessed. class A { private: void operator delete(void* p) {}; }; class B: public A { public: ~B() {} }; -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Mittwoch, 21. August 2013 00:06 Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX I looked throw reviews and fount only one not answered question: On 8/15/13 5:14 PM, David Holmes wrote: >> allocation.hpp >> xlC complains: >> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" >> member "StackObj::operator delete(void *)" cannot be accessed. > > Hmmm. So the whole point of these being private was so that they could > not be called but we had to override the use of the global operators. > The concrete implementations then give fatal errors if you do manage to > use them (impossible?). So making them public is undesirable. > > Is there some other way to resolve this? A pragma to tell xlC to ignore > the perceived problem? thanks, Vladimir On 8/19/13 9:32 AM, Vladimir Kozlov wrote: > I tested 8023033-aixShared-2 in JPRT (including builds and tests on ppc > + arm) and it passed without failures. > > Thanks, > Vladimir > > On 8/16/13 3:06 PM, Stefan Karlsson wrote: >> On 8/16/13 11:28 PM, Lindenmaier, Goetz wrote: >>> >>> Hi Stefan, >>> >>> the problem is that globalDefinitions defines __STDC_FORMAT_MACROS. >>> >>> inttypes.hpp comes in through jni.hpp, which is in both, jvm.hpp and >>> >>> globalDefinitions.hpp through globalDefinitions_.hpp. >>> >>> If jvm.hpp comes first, inttype.hpp is added without the macro defined, >>> >>> and the print formats are missing. >>> >>> I could also define __STDC_FORMAT_MACROS in jni.hpp or the like. >>> >>> The name "globalDefinitions" somehow says that the definitions should >>> be seen >>> >>> everywhere ... so it's basically bad that the file does not end up at >>> the top of the include >>> >>> chain. Maybe I should include it in jni.hpp? or jvm.hpp? >>> >>> What do you think? >>> >> >> I see your problem. >> >> I think the most stable solution would be to add -D__STDC_FORMAT_MACROS >> to the compiler flags. >> >> But that seems out-of-scope for this change, so go ahead and use the >> reordering for now (unless someone else complains). >> >> thanks, >> StefanK >> >>> Best regards, >>> >>> Goetz. >>> >>> *From:*Stefan Karlsson [mailto:stefan.karlsson at oracle.com] >>> *Sent:* Friday, August 16, 2013 3:09 PM >>> *To:* Lindenmaier, Goetz >>> *Cc:* 'Vladimir Kozlov'; 'David Holmes'; >>> 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >>> *Subject:* Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX >>> >>> Hi Goetz, >>> >>> On 8/16/13 2:21 PM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> >>> >>> - I removed the throw() >>> >>> - I removed the #ifndef in port.hpp >>> >>> - I fixed the typeo. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-2/ >>> >>> >>> >>> >>> I always build without precompiled headers, the nightbuild with >>> >>> them. >>> >>> >>> utilities/debug.hpp.udiff.html >>> >>> -#include "prims/jvm.h" >>> #include "utilities/globalDefinitions.hpp" >>> +#include "prims/jvm.h" >>> >>> I don't think your change to debug.hpp is the correct way to solve >>> the problems you were seeing with metaspace.hpp. Swapping the files >>> just means that someone else might hit the same problem adding >>> prims/jvm.hpp to another file. >>> >>> >>> You probably have a circular include dependency somewhere in the >>> code. Could you revert the change to utilities/debug.hpp and try to >>> figure out what the real problem is? >>> >>> thanks, >>> StefanK >>> >>> >>> >>> >>> >>> >>> Yes, there will be makefiles for aix, and the platform files. >>> tTe prototype >>> >>> patches are here >>> >>> >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0014_aix_make_changes.patch >>> >>> >>> >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0015_aix_ppc_files.patch >>> >>> >>> >>> >>> But the make change contains mostly new files, except for >>> >>> >>> >>> --- a/make/defs.make Tue Jul 23 21:07:11 2013 +0200 >>> >>> +++ b/make/defs.make Tue Jul 23 22:13:05 2013 +0200 >>> >>> @@ -166,11 +166,15 @@ >>> >>> HOST := $(shell uname -n) >>> >>> endif >>> >>> >>> >>> -# If not SunOS, not Linux and not BSD, assume Windows >>> >>> +# If not SunOS, not Linux not BSD and not AIX, assume Windows >>> >>> ifneq ($(OS), Linux) >>> >>> ifneq ($(OS), SunOS) >>> >>> ifneq ($(OS), bsd) >>> >>> - OSNAME=windows >>> >>> + ifneq ($(OS), AIX) >>> >>> + OSNAME=windows >>> >>> + else >>> >>> + OSNAME=aix >>> >>> + endif >>> >>> else >>> >>> OSNAME=bsd >>> >>> endif >>> >>> >>> >>> >>> >>> Best regards, >>> >>> Goetz >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> >>> Sent: Friday, August 16, 2013 7:21 AM >>> >>> To: David Holmes >>> >>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net >>> ';'hotspot-dev at openjdk.java.net >>> ' >>> >>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for >>> AIX >>> >>> >>> >>> I thought trow() was added long time ago. But it was added, I >>> think by accident, very recently: >>> >>> >>> >>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a7fb14888912 >>> >>> >>> >>> I missed it when I did the review of those changes. >>> >>> >>> >>> We should remove throw. >>> >>> >>> >>> Vladimir >>> >>> >>> >>> On 8/15/13 5:14 PM, David Holmes wrote: >>> >>> On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: >>> >>> On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: >>> >>> Hi Vladimir, >>> >>> >>> >>> throw is needed because it`s there in the >>> implementation in nmethod.cpp. >>> >>> (So you are using it a bit at least :)) >>> >>> xlc says >>> >>> "nmethod.cpp", line 802.7: 1540-0400 (S) >>> "nmethod::operator >>> >>> new(size_t, int)" has a conflicting declaration. >>> >>> "nmethod.hpp", line 268.9: 1540-0424 (I) "operator >>> new" is declared on >>> >>> line 268 of "nmethod.hpp". >>> >>> >>> >>> Okay, it is just declaration. >>> >>> >>> >>> Why do we have throw here: >>> >>> >>> >>> void* nmethod::operator new(size_t size, int nmethod_size) >>> throw () { >>> >>> // Not critical, may return null if there is too little >>> continuous memory >>> >>> return CodeCache::allocate(nmethod_size); >>> >>> } >>> >>> >>> >>> Seems to me it should be removed if anything. >>> >>> >>> >>> David >>> >>> ----- >>> >>> >>> >>> >>> >>> >>> >>> int64 is defined correctly, uint64 is not defined, >>> but never used in >>> >>> hotspot. >>> >>> I can not reproduce an error, but that's rather old >>> coding from our VM. >>> >>> We also switched from xlc8 to xlc10 in the course of >>> this project. >>> >>> I will test some more and talk to the person who >>> implemented that >>> >>> tomorrow, >>> >>> and if possible remove the change. >>> >>> >>> >>> Okay, I will test it also. >>> >>> >>> >>> Vladimir >>> >>> >>> >>> >>> >>> Best regards & thanks for the review, >>> >>> Goetz. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> >>> From: Vladimir Kozlov >>> [mailto:vladimir.kozlov at oracle.com] >>> >>> Sent: Thursday, August 15, 2013 5:52 PM >>> >>> To: Lindenmaier, Goetz >>> >>> Cc: 'hotspot-dev at openjdk.java.net >>> ';ppc-aix-port-dev at openjdk.java.net >>> ; >>> >>> Albert Noll (albert.noll at oracle.com >>> ) >>> >>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic >>> changes for AIX >>> >>> >>> >>> Goetz, >>> >>> >>> >>> I only see 2 problems which you did not explain: >>> >>> >>> >>> nmethod.hpp. Why the next change? we don't use C++ >>> exceptions: >>> >>> >>> >>> - void* operator new(size_t size, int nmethod_size); >>> >>> + void* operator new(size_t size, int nmethod_size) >>> throw (); >>> >>> >>> >>> port.hpp. Did AIX has the same definitions for jlong >>> and julong?: >>> >>> >>> >>> +#ifndef _AIX >>> >>> +// These conflict with /usr/include/sys/inttypes.h >>> on aix. >>> >>> typedef jlong int64; // Java long for >>> my 64-bit type >>> >>> typedef julong uint64; // Java long for >>> my 64-bit type >>> >>> +#endif >>> >>> >>> >>> >>> >>> And of cause we need to test these changes with >>> compilers we use. >>> >>> >>> >>> Thanks, >>> >>> Vladimir >>> >>> >>> >>> On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> >>> >>> I prepared a webrev for >>> >>> 8023033: PPC64 (part 13): basic changes for AIX >>> >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >>> >>> >>> >>> >>> This contains the basic shared changes needed for >>> the AIX port, >>> >>> as there are >>> >>> - #includes >>> >>> - Fixes to get the code compiling with xlC/on AIX >>> >>> - Basic adaptions as in vm_version.cpp. >>> >>> >>> >>> It also determines the placement and naming of >>> the aix files, >>> >>> which will go to os/aix and os_cpu/aix_ppc, as >>> you can see in >>> >>> >>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >>> >>> >>> >>> >>> >>> >>> Some details about the compilation problems: >>> >>> >>> >>> relocInfo.hpp: >>> >>> xlC wants initialization in inline implementation. >>> >>> >>> >>> vmreg.hpp: >>> >>> BAD is defined in AIX system header sys/param.h. >>> Renamed. >>> >>> >>> >>> allocation.hpp >>> >>> xlC complains: >>> >>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 >>> (S) The "private" >>> >>> member "StackObj::operator delete(void *)" cannot >>> be accessed. >>> >>> >>> >>> sharedRuntimeTrig.cpp >>> >>> Aix defines hz to be 100, see sys/m_param.h. >>> Renamed. >>> >>> >>> >>> debug.hpp >>> >>> With other include order we get a lot of >>> >>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) >>> "PRIuPTR" is not >>> >>> declared. >>> >>> >>> >>> >>> >>> Please review and test this change. Comments are >>> welcome. >>> >>> >>> >>> Thanks and best regards, >>> >>> Goetz. >>> >>> >>> >> From bengt.rutisson at oracle.com Wed Aug 21 06:28:03 2013 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 21 Aug 2013 15:28:03 +0200 Subject: JDK7 SIGSEGV with G1 garbage collector In-Reply-To: <52146391.1090807@oracle.com> References: <52146391.1090807@oracle.com> Message-ID: <5214C063.70307@oracle.com> Hi again, This seems to be a bug in the C2 compiler. I've filed JDK-8023472 to track this. I'll come back with a URL once this bug is publicly available. Thanks again for the great bug report! Bengt On 8/21/13 8:52 AM, Bengt Rutisson wrote: > > Hi Punya, > > Thank you for the excellent bug report! > > I cloned the test case and can reproduce the issue both with 7u25 > build 15 (that you used) and also with the latest build of JDK8. > > I'll dig some more into what is going on and file a bug. Will ping > this thread when I have more information. > > Bengt > > On 8/21/13 12:05 AM, Punya Biswal wrote: >> [Apologies if this message is delivered twice; I sent it once before I >> realized this was a members-only list.] >> >> We're running into a JVM segfault when using a third-party library >> (Elasticsearch) alongside the G1 garbage collector. This issue has been >> reported elsewhere (for example, >> https://jira.terracotta.org/jira/browse/CDV-1651) and might already >> be on >> the OpenJDK roadmap. It's usually associated with the use of GNU Trove. >> >> We've been able to reduce the amount of code required to reproduce the >> crash to a short program that reliably crashes on my computer >> (a MacBook Pro) using only JDK core classes. I've also included the >> hs_err_* diagnostic file; both are at >> https://gist.github.com/punya/6287943 . >> >> Does this reduced repro help understand what's going on? >> >> >> A few points of interest: >> >> * running with -XX:+UseG1GC -Dcount=100000 always crashes >> * running with -XX:+UseG1GC -Xint -Dcount=100000 never crashes >> * running with -Xint -Dcount=100000 never crashes >> >> >> Using -ea and/or -server don't any effect these results. With regard to >> JVM versions, >> >> * it never crashes on JDK 6u51 >> * it crashes on JDK 7u25 and JDK 7u43 (prerelease) >> * it never crashes on JDK 8 (prerelease) >> >> >> I'm happy to provide a link to a core dump if that helps. >> >> -- >> Punya Biswal >> Palantir | Engineer >> pbiswal at palantir.com | 206 605 2397 > From coleen.phillimore at oracle.com Wed Aug 21 07:37:32 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 21 Aug 2013 10:37:32 -0400 Subject: Request for review: 8020530 Non heap memory size calculated incorrectly In-Reply-To: <5214991B.40107@oracle.com> References: <521356A1.9010507@oracle.com> <52135DA2.4070403@oracle.com> <8F0F7B38-9F27-45ED-A9ED-1507D8B883EF@oracle.com> <5213E517.5000106@oracle.com> <5214991B.40107@oracle.com> Message-ID: <5214D0AC.1000008@oracle.com> Looks good, thanks! Coleen On 8/21/2013 6:40 AM, Vladimir Kempik wrote: > Thanks everyone for comments. > > Here is updated webrev > http://cr.openjdk.java.net/~vkempik/8020530/webrev.01/ > > Vladimir. > On 21.08.2013 1:52, Mandy Chung wrote: >> >> On 8/20/2013 5:38 AM, Staffan Larsen wrote: >>> That doesn't make a lot of sense to me. Why would a pool have >>> undefined values? >>> The Metaspace pool has no max value (unless you specify >>> -XX:MaxMetaspaceSize=), thus undefined. >>> >>>> If a subset of pools have undefined values why report completely >>>> fallacious values of -1? >>> The javadoc for MemoryUsage says getMax() returns -1 if the maximum >>> memory size is undefined. >> >> Yes the spec allows implementation of memory pools with undefined >> max. "used" and "committed" must have a value and the "committed" >> memory is guaranteed to be available for the VM to use. "max" will >> give an idea of the upper bound how much memory can be allocated from >> it; however, there is no guarantee that amount of memory is available >> for the VM. >> >>>> It also isn't clear how this relates to the "committed" value in >>>> the failure. What gets reported now? >>> I guess there can still be a committed value even if we don't have a >>> max value for how much we might commit in the future: used <= >>> committed <= max. >> >> The MemoryUsage constructor throws IAE if committed > max if max is >> defined. Perhaps it would be better if max should be Long.MAX_VALUE >> if undefined (a different issue than this bug). >> >> Mandy >> >>> /Staffan >>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >> > From coleen.phillimore at oracle.com Wed Aug 21 10:55:40 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 21 Aug 2013 13:55:40 -0400 Subject: RFR (L): 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment In-Reply-To: References: Message-ID: <5214FF1C.9050702@oracle.com> Hi, I've reviewed this change and I don't know how it can work. You cannot put uncompressed oops in an object when the setting is UseCompressedOops and have garbage collection work. Similarly you can't compress arbitrary metadata because only Klass* types can be compressed. This doesn't seem like it would work at all. Also, we lay out objects in classFileParser assuming the setting of UseCompressedOops/ClassPointers and allocates space based on that. I don't understand the motivation of this change. It appears incorrect. From reading the bug, it seems that you want to get to mirror from InstanceKlass from Java. This will break when we move the mirror. Coleen On 8/19/2013 5:28 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8022853/webrev/ > http://cr.openjdk.java.net/~twisti/8022853-jdk/webrev/ > > 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment > Reviewed-by: > > In some native data structures of the VM oops are stored uncompressed when compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. > From vladimir.kozlov at oracle.com Wed Aug 21 10:57:40 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Aug 2013 10:57:40 -0700 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D01681B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> <520D6EEE.1040906@oracle.com> <520DB6B7.2050901@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015CCA@DEWDFEMB12A.global.corp.sap> <520E246F.1060704@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015DAB@DEWDFEMB12A.global.corp.sap> <520EA24F.5060304@oracle.com> <52124897.7030304@oracle.com> <5213E84B.8000101@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01681B@DEWDFEMB12A.global.corp.sap> Message-ID: <5214FF94.5050007@oracle.com> Can we add #ifdef __IBMCPP__ to your change? + void* operator new [](size_t size); +// xlC can not compile this code with private operator delete() +#ifdef __IBMCPP__ + public: +#endif void operator delete(void* p); - void* operator new [](size_t size); Thanks, Vladimir On 8/21/13 5:35 AM, Lindenmaier, Goetz wrote: > Hi, > > I don't have another workaround at hand right now. > > The problem is that there are public destructors in subclasses of > StackObj which > > has the private delete operator. > > I shrinked the problem to a minimal test program and addressed the issue to > > our IBM compiler contacts. > > The minimal change that makes the sources compile is > > --- a/src/share/vm/memory/allocation.hpp Fri Jul 26 00:59:18 2013 +0200 > > +++ b/src/share/vm/memory/allocation.hpp Wed Aug 21 10:30:58 2013 +0200 > > @@ -218,7 +218,8 @@ > > class StackObj ALLOCATION_SUPER_CLASS_SPEC { > > private: > > void* operator new(size_t size); > > + void* operator new [](size_t size); > > + public: > > void operator delete(void* p); > > - void* operator new [](size_t size); > > void operator delete [](void* p); > > }; > > I.e., make only the delete operators public. VALUE_OBJ_CLASS_SPEC is > defined empty > > on aix, so the fix in _ValueObj is currently not essential. > > I would appreciate if you can push the change with this fix, so we can > get to the > > point where we can compile on aix soon. If I get a workaround like a > pragma, > > I will undo this. > > Best regards, > > Goetz. > > // xlC 10 and 12 can not compile this program: > > // "test.cpp", line 12.3: 1540-0300 (S) The "private" member > "A::operator delete(void *)" cannot be accessed. > > class A { > > private: > > void operator delete(void* p) {}; > > }; > > class B: public A { > > public: > > ~B() {} > > }; > > -----Original Message----- > > From: hotspot-dev-bounces at openjdk.java.net > [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > > Sent: Mittwoch, 21. August 2013 00:06 > > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > > Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX > > I looked throw reviews and fount only one not answered question: > > On 8/15/13 5:14 PM, David Holmes wrote: > >>> allocation.hpp > >>> xlC complains: > >>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" > >>> member "StackObj::operator delete(void *)" cannot be accessed. > >> > >> Hmmm. So the whole point of these being private was so that they could > >> not be called but we had to override the use of the global operators. > >> The concrete implementations then give fatal errors if you do manage to > >> use them (impossible?). So making them public is undesirable. > >> > >> Is there some other way to resolve this? A pragma to tell xlC to ignore > >> the perceived problem? > > thanks, > > Vladimir > > On 8/19/13 9:32 AM, Vladimir Kozlov wrote: > >> I tested 8023033-aixShared-2 in JPRT (including builds and tests on ppc > >> + arm) and it passed without failures. > >> > >> Thanks, > >> Vladimir > >> > >> On 8/16/13 3:06 PM, Stefan Karlsson wrote: > >>> On 8/16/13 11:28 PM, Lindenmaier, Goetz wrote: > >>>> > >>>> Hi Stefan, > >>>> > >>>> the problem is that globalDefinitions defines __STDC_FORMAT_MACROS. > >>>> > >>>> inttypes.hpp comes in through jni.hpp, which is in both, jvm.hpp and > >>>> > >>>> globalDefinitions.hpp through globalDefinitions_.hpp. > >>>> > >>>> If jvm.hpp comes first, inttype.hpp is added without the macro defined, > >>>> > >>>> and the print formats are missing. > >>>> > >>>> I could also define __STDC_FORMAT_MACROS in jni.hpp or the like. > >>>> > >>>> The name ?globalDefinitions? somehow says that the definitions should > >>>> be seen > >>>> > >>>> everywhere ? so it?s basically bad that the file does not end up at > >>>> the top of the include > >>>> > >>>> chain. Maybe I should include it in jni.hpp? or jvm.hpp? > >>>> > >>>> What do you think? > >>>> > >>> > >>> I see your problem. > >>> > >>> I think the most stable solution would be to add -D__STDC_FORMAT_MACROS > >>> to the compiler flags. > >>> > >>> But that seems out-of-scope for this change, so go ahead and use the > >>> reordering for now (unless someone else complains). > >>> > >>> thanks, > >>> StefanK > >>> > >>>> Best regards, > >>>> > >>>> Goetz. > >>>> > >>>> *From:*Stefan Karlsson [mailto:stefan.karlsson at oracle.com] > >>>> *Sent:* Friday, August 16, 2013 3:09 PM > >>>> *To:* Lindenmaier, Goetz > >>>> *Cc:* 'Vladimir Kozlov'; 'David Holmes'; > >>>> 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > >>>> *Subject:* Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX > >>>> > >>>> Hi Goetz, > >>>> > >>>> On 8/16/13 2:21 PM, Lindenmaier, Goetz wrote: > >>>> > >>>> Hi, > >>>> > >>>> > >>>> > >>>> - I removed the throw() > >>>> > >>>> - I removed the #ifndef in port.hpp > >>>> > >>>> - I fixed the typeo. > >>>> > >>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-2/ > >>>> > >>>> > >>>> > >>>> > >>>> I always build without precompiled headers, the nightbuild with > >>>> > >>>> them. > >>>> > >>>> > >>>> utilities/debug.hpp.udiff.html > >>>> > >>>> -#include "prims/jvm.h" > >>>> #include "utilities/globalDefinitions.hpp" > >>>> +#include "prims/jvm.h" > >>>> > >>>> I don't think your change to debug.hpp is the correct way to solve > >>>> the problems you were seeing with metaspace.hpp. Swapping the files > >>>> just means that someone else might hit the same problem adding > >>>> prims/jvm.hpp to another file. > >>>> > >>>> > >>>> You probably have a circular include dependency somewhere in the > >>>> code. Could you revert the change to utilities/debug.hpp and try to > >>>> figure out what the real problem is? > >>>> > >>>> thanks, > >>>> StefanK > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Yes, there will be makefiles for aix, and the platform files. > >>>> tTe prototype > >>>> > >>>> patches are here > >>>> > >>>> > >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0014_aix_make_changes.patch > >>>> > >>>> > >>>> > >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0015_aix_ppc_files.patch > >>>> > >>>> > >>>> > >>>> > >>>> But the make change contains mostly new files, except for > >>>> > >>>> > >>>> > >>>> --- a/make/defs.make Tue Jul 23 21:07:11 2013 +0200 > >>>> > >>>> +++ b/make/defs.make Tue Jul 23 22:13:05 2013 +0200 > >>>> > >>>> @@ -166,11 +166,15 @@ > >>>> > >>>> HOST := $(shell uname -n) > >>>> > >>>> endif > >>>> > >>>> > >>>> > >>>> -# If not SunOS, not Linux and not BSD, assume Windows > >>>> > >>>> +# If not SunOS, not Linux not BSD and not AIX, assume Windows > >>>> > >>>> ifneq ($(OS), Linux) > >>>> > >>>> ifneq ($(OS), SunOS) > >>>> > >>>> ifneq ($(OS), bsd) > >>>> > >>>> - OSNAME=windows > >>>> > >>>> + ifneq ($(OS), AIX) > >>>> > >>>> + OSNAME=windows > >>>> > >>>> + else > >>>> > >>>> + OSNAME=aix > >>>> > >>>> + endif > >>>> > >>>> else > >>>> > >>>> OSNAME=bsd > >>>> > >>>> endif > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Best regards, > >>>> > >>>> Goetz > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> > >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > >>>> > >>>> Sent: Friday, August 16, 2013 7:21 AM > >>>> > >>>> To: David Holmes > >>>> > >>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net > >>>> ';'hotspot-dev at openjdk.java.net > >>>> ' > >>>> > >>>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for > >>>> AIX > >>>> > >>>> > >>>> > >>>> I thought trow() was added long time ago. But it was added, I > >>>> think by accident, very recently: > >>>> > >>>> > >>>> > >>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a7fb14888912 > >>>> > >>>> > >>>> > >>>> I missed it when I did the review of those changes. > >>>> > >>>> > >>>> > >>>> We should remove throw. > >>>> > >>>> > >>>> > >>>> Vladimir > >>>> > >>>> > >>>> > >>>> On 8/15/13 5:14 PM, David Holmes wrote: > >>>> > >>>> On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: > >>>> > >>>> On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: > >>>> > >>>> Hi Vladimir, > >>>> > >>>> > >>>> > >>>> throw is needed because it`s there in the > >>>> implementation in nmethod.cpp. > >>>> > >>>> (So you are using it a bit at least :)) > >>>> > >>>> xlc says > >>>> > >>>> "nmethod.cpp", line 802.7: 1540-0400 (S) > >>>> "nmethod::operator > >>>> > >>>> new(size_t, int)" has a conflicting declaration. > >>>> > >>>> "nmethod.hpp", line 268.9: 1540-0424 (I) "operator > >>>> new" is declared on > >>>> > >>>> line 268 of "nmethod.hpp". > >>>> > >>>> > >>>> > >>>> Okay, it is just declaration. > >>>> > >>>> > >>>> > >>>> Why do we have throw here: > >>>> > >>>> > >>>> > >>>> void* nmethod::operator new(size_t size, int nmethod_size) > >>>> throw () { > >>>> > >>>> // Not critical, may return null if there is too little > >>>> continuous memory > >>>> > >>>> return CodeCache::allocate(nmethod_size); > >>>> > >>>> } > >>>> > >>>> > >>>> > >>>> Seems to me it should be removed if anything. > >>>> > >>>> > >>>> > >>>> David > >>>> > >>>> ----- > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> int64 is defined correctly, uint64 is not defined, > >>>> but never used in > >>>> > >>>> hotspot. > >>>> > >>>> I can not reproduce an error, but that's rather old > >>>> coding from our VM. > >>>> > >>>> We also switched from xlc8 to xlc10 in the course of > >>>> this project. > >>>> > >>>> I will test some more and talk to the person who > >>>> implemented that > >>>> > >>>> tomorrow, > >>>> > >>>> and if possible remove the change. > >>>> > >>>> > >>>> > >>>> Okay, I will test it also. > >>>> > >>>> > >>>> > >>>> Vladimir > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Best regards & thanks for the review, > >>>> > >>>> Goetz. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> > >>>> From: Vladimir Kozlov > >>>> [mailto:vladimir.kozlov at oracle.com] > >>>> > >>>> Sent: Thursday, August 15, 2013 5:52 PM > >>>> > >>>> To: Lindenmaier, Goetz > >>>> > >>>> Cc: 'hotspot-dev at openjdk.java.net > >>>> ';ppc-aix-port-dev at openjdk.java.net > >>>> ; > > >>> > > >>> Albert Noll (albert.noll at oracle.com > > >>> ) > >>>> > >>>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic > >>>> changes for AIX > >>>> > >>>> > >>>> > >>>> Goetz, > >>>> > >>>> > >>>> > >>>> I only see 2 problems which you did not explain: > >>>> > >>>> > >>>> > >>>> nmethod.hpp. Why the next change? we don't use C++ > >>>> exceptions: > >>>> > >>>> > >>>> > >>>> - void* operator new(size_t size, int nmethod_size); > >>>> > >>>> + void* operator new(size_t size, int nmethod_size) > >>>> throw (); > >>>> > >>>> > >>>> > >>>> port.hpp. Did AIX has the same definitions for jlong > >>>> and julong?: > >>>> > >>>> > >>>> > >>>> +#ifndef _AIX > >>>> > >>>> +// These conflict with /usr/include/sys/inttypes.h > >>>> on aix. > >>>> > >>>> typedef jlong int64; // Java long for > >>>> my 64-bit type > >>>> > >>>> typedef julong uint64; // Java long for > >>>> my 64-bit type > >>>> > >>>> +#endif > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> And of cause we need to test these changes with > >>>> compilers we use. > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Vladimir > >>>> > > >>> > > >>> > > >>> On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: > >>>> > >>>> Hi, > >>>> > >>>> > >>>> > >>>> I prepared a webrev for > >>>> > >>>> 8023033: PPC64 (part 13): basic changes for AIX > >>>> > >>>> > >>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ > >>>> > >>>> > >>>> > >>>> > >>>> This contains the basic shared changes needed for > >>>> the AIX port, > >>>> > >>>> as there are > >>>> > >>>> - #includes > >>>> > >>>> - Fixes to get the code compiling with xlC/on AIX > >>>> > >>>> - Basic adaptions as in vm_version.cpp. > >>>> > >>>> > >>>> > >>>> It also determines the placement and naming of > >>>> the aix files, > >>>> > >>>> which will go to os/aix and os_cpu/aix_ppc, as > >>>> you can see in > >>>> > >>>> > >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Some details about the compilation problems: > >>>> > >>>> > >>>> > >>>> relocInfo.hpp: > >>>> > >>>> xlC wants initialization in inline implementation. > >>>> > >>>> > >>>> > >>>> vmreg.hpp: > >>>> > >>>> BAD is defined in AIX system header sys/param.h. > >>>> Renamed. > >>>> > >>>> > >>>> > >>>> allocation.hpp > >>>> > >>>> xlC complains: > >>>> > >>>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 > >>>> (S) The "private" > >>>> > >>>> member "StackObj::operator delete(void *)" cannot > >>>> be accessed. > >>>> > >>>> > >>>> > >>>> sharedRuntimeTrig.cpp > >>>> > >>>> Aix defines hz to be 100, see sys/m_param.h. > >>>> Renamed. > >>>> > >>>> > >>>> > >>>> debug.hpp > >>>> > >>>> With other include order we get a lot of > >>>> > >>>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) > >>>> "PRIuPTR" is not > >>>> > >>>> declared. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Please review and test this change. Comments are > >>>> welcome. > >>>> > >>>> > >>>> > >>>> Thanks and best regards, > > >>> > > >>> Goetz. > > >>> > > >>> > > >>> > > >> > From serguei.spitsyn at oracle.com Wed Aug 21 11:03:47 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 21 Aug 2013 11:03:47 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <52141557.3020300@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <52002372.2030302@oracle.com> <52139F64.2050906@oracle.com> <5213F0F1.4020800@oracle.com> <52141557.3020300@oracle.com> Message-ID: <52150103.1050507@oracle.com> Bill, Thumbs up modulo the below comments. I've noticed a couple of more minor issues. Could you, please, make one more clean-up? src/os/windows/vm/os_windows.cpp There is still some inconsistency in the lines: 5401 // Builds a platform dependent Agent_OnLoad_ function name 5411 char* os::build_agent_function_name(const char *sym_name, const char *lib_name, 5454 // agent_entry_name == _Agent_OnLoad_libName at XX I'm not sure how to make it better but leave it up to you. Maybe the line 5454 is Ok as another style is required there. src/share/vm/prims/jvmti.xml The lines are still too long: 667, 10773, 10776 Thanks, Serguei On 8/20/13 6:18 PM, BILL PITTORE wrote: > Thanks Serguei for the detailed review. I think I captured all the > tweaks you mentioned and have new webrevs at: > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.03/ > http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.04/ > > also you can find the jvmti.html output file at > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.03/jvmti.html > > and the javadoc from VirtualMachine.java at: > http://cr.openjdk.java.net/~bpittore/8014135/javadoc/ > > bill > > On 8/20/2013 6:42 PM, serguei.spitsyn at oracle.com wrote: >> Hi Bill, >> >> It looks good in general. >> >> Some minor comments. >> >> src/share/classes/com/sun/tools/attach/VirtualMachine.java >> >> The copyright comment is out-of-date >> >> >> || src/os/posix/vm/os_posix.cpp >> >> symName => sym_name >> >> src/os/windows/vm/os_windows.cpp >> >> 5454 //agent_entry_name == _Agent_OnLoad_libName at XX >> >> Need a space after // >> >> ||src/share/vm/prims/jvmti.xml >> >> The copyright comment is out-of-date. >> The lines are too long: 520-523, 584, 593, 623, 654, 660, 679, 689. >> >> src/share/vm/prims/jvmtiExport.cpp >> src/share/vm/runtime/arguments.hpp >> >> No comments >> >> ||src/share/vm/runtime/os.cpp >> >> The indentation is incorrect: >> 456 const char *syms[], size_t syms_len) { >> >> The comments are cross-inconsistent (lib_name vs libname): >> >> 447 * Support for finding Agent_On(Un)Load/Attach<_lib_name> if it exists. >> . . . >> 449 * Agent_OnLoad_lib_name or Agent_OnAttach_lib_name function to determine if >> . . . >> 491 // Check for Agent_OnLoad/Attach_libname function >> . . . >> 498 // Found an entry point like Agent_OnLoad_libname so we have a static agent >> >> ||src/share/vm/runtime/os.hpp >> >> 542 // return the handle of this process >> 543 static void* get_default_process_handle(); >> 544 >> 545 // Check for static linked agent library >> 546 static bool find_builtin_agent(AgentLibrary *agent_lib, const char *syms[], >> 547 size_t syms_len); >> 548 >> 549 // Find agent entry point >> 550 static void *find_agent_function(AgentLibrary *agent_lib, bool check_lib, >> 551 const char *syms[], size_t syms_len); The comment at the line #542 should start from capital letter. >> Wrong indentation at the lines: #547, #551. >> >> ||src/share/vm/runtime/thread.cpp >> >> Wrong indentation: >> 3748 on_load_entry = CAST_TO_FN_PTR(OnLoadEntry_t, os::find_agent_function(agent, >> 3749 false, >> 3750 on_load_symbols, >> 3751 num_symbol_entries)); >> >> >> Thanks, >> Serguei >> >> On 8/20/13 9:55 AM, bill.pittore at oracle.com wrote: >>> I've updated the hotspot and jdk webrevs based on Coleen's and >>> Serguei's comments. >>> >>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.03/ >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.02/ >>> >>> thanks, >>> bill >>> >>> >>> On 8/19/2013 1:13 PM, BILL PITTORE wrote: >>>> On 8/5/2013 6:13 PM, Coleen Phillimore wrote: >>>>> >>>>> Hi Bill, I have some high level comments and other comments. This >>>>> wasn't as easy to review as Bob promised me! >>>> :-P >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/src/share/classes/com/sun/tools/attach/VirtualMachine.java.udiff.html >>>>> >>>>> paramter (typo - two instances) >>>>> >>>>> * @throws AgentInitializationException >>>>> - * If the Agent_OnAttach function >>>>> returns an error >>>>> + * If the Agent_OnAttach[_L] function >>>>> returns an error. >>>>> + * an error. >>>>> * >>>> Fixed. >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/os/posix/vm/os_posix.cpp.frames.html >>>>> >>>>> >>>>> nameLen, prefixLen, suffixLen - the JVM coding convention (unlike >>>>> Java) is to have variable names lower case and separated by a _ >>>>> (not camelcase). Same for all the new code here >>>>> buildAgentFunctionName. >>>> Fixed all names. Original code came from JDK which is why I had >>>> this scheme. >>>>> >>>>> Can you put a function above this function to say what it does? So >>>>> once it's code reviewed, we can quickly know what it does without >>>>> having to study this again - ie. Is name something like libxxx.so >>>>> and you're trying to extract lib and .so from it? There's no >>>>> verification of this at lines 286 and 287 but the code is handling >>>>> the case of other sorts of unexpected input (ie line 283). Why >>>>> don't you strip the lib and the .so if !is_absolute_path? >>>> Added a comment to the above function to describe what's going on. >>>> For absolute path case, the lib_name is something like /a/b/libL.so >>>> so we need to strip off the path, the 'lib' prefix and the '.so' >>>> suffix to get the base name. >>>>> 291 agentEntryName = NEW_C_HEAP_ARRAY(char, len, mtThread); >>>>> 292 if (agentEntryName == NULL) { >>>>> 293 return NULL; >>>>> 294 } >>>>> If NEW_C_HEAP_ARRAY fails it terminates the JVM. I think you >>>>> might want this function instead NEW_C_HEAP_ARRAY_RETURN_NULL if >>>>> there's a reasonable recovery possible. >>>>> >>>> Ok, changed it to the above. >>>>> os_windows.cpp >>>>> >>>>> Same comments as above. Also: >>>>> >>>>> 5432 strncat(agentEntryName, name, nameLen); >>>>> 5433 strcat(agentEntryName, p); >>>>> 5434 //agentEntryName == _Agent_OnLoad_libName at 12 >>>>> 5435 } else { >>>>> You could say why 12 but shouldn't it be the length of the >>>>> resulting symbol instead and not 12? >>>> Changed it to '@XX'. It's really the length of the arguments which >>>> could change in the future, so XX should be fine. >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/os.cpp.frames.html >>>>> >>>>> >>>>> findAgentFunction - same comment about the coding conventions. >>>>> functions and variables are lower case with underscores. Class >>>>> names are CamelCase. It would be convenient if the jvm code used >>>>> the java coding convention but the rest of it doesn't so this new >>>>> code is inconsistent. This is hard to follow as it is! >>>>> >>>> Fixed. >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/thread.cpp.frames.html >>>>> >>>>> >>>>> 3826 size_t num_symbol_entries = sizeof(on_unload_symbols) / >>>>> sizeof(char*); >>>>> Why not use ARRAY_SIZE macro? >>>>> >>>> Fixed. >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/prims/jvmtiExport.cpp.frames.html >>>>> >>>>> >>>>> 2208 // Check for builtin agent. If not then if the path is >>>>> absolute we attempt >>>>> 2209 // to load the library. Otherwise we try to load it from >>>>> the standard >>>>> 2210 // dll directory. >>>>> I think you are missing the word "found" in this sentence. You >>>>> are using builtin agent to mean agent defined in a statically >>>>> linked library, I believe. Can you say that instead? Builtin >>>>> means that the jvm knows about it and implements it but in this >>>>> case it doesn't. >>>> Re-worded this to be more explicit about statically linked in >>>>> >>>>> Maybe find_statically_linked_agent() would be a better name for >>>>> this function? >>>> I think builtin came from when we did original JNI builitin >>>> libraries. It might be documented as such in the JEP or CCC. >>>>> >>>>> Is the is_valid() function really mean has_been_loaded()? >>>>> 2236 if (agentLib->valid()) { >>>> Yes, either it was found statically linked into the executable or >>>> it was successfully loaded as a shared lib. >>>>> >>>>> >>>>> Did you run the Internal NSK vm.quick.testlist tests on this to >>>>> verify that nothing breaks? There are a lot of tests with >>>>> different agents and combinations in that suite and it frequently >>>>> holds some surprises in this area so best to run it first. Let >>>>> me know if you need help. >>>> Ran the vm/nsk tests using UTE. Also we have some new test code to >>>> test the statically linked agent functionality. >>>> >>>> Thanks so much for the excellent review. >>>> I'll update the webrev as soon as I rebuild and test. >>>> >>>> bill >>>> >>>>> >>>>> Coleen >>>>> >>>>> On 08/05/2013 10:41 AM, Bob Vandette wrote: >>>>>> On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: >>>>>> >>>>>>> On 8/2/2013 9:12 PM,serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Bill, >>>>>>>> >>>>>>>> A couple of more questions. >>>>>>>> >>>>>>>> webrev.01/jvmti.html >>>>>>>> >>>>>>>> An agent L whose image has been combined with the VM *is >>>>>>>> defined* as /statically linked/ >>>>>>>> if and only if the agent exports a function called Agent_OnLoad_L. >>>>>>>> >>>>>>>> A question to the above. >>>>>>>> Are we going to allow to link a library dynamically if it >>>>>>>> exports both >>>>>>>> the Agent_OnLoad and Agent_OnLoad_L functions? >>>>>>>> It can be convenient if a library exports both Agent_OnLoad and >>>>>>>> Agent_OnLoad_L >>>>>>>> as it can be linked statically or dynamically depending on the >>>>>>>> need without changes. >>>>>>>> >>>>>>> It would be nice but the problem is that you could only link one >>>>>>> agent into the VM if it exported Agent_OnLoad. Otherwise there >>>>>>> would be a symbol collision with the second agent you linked in >>>>>>> that also had Agent_OnLoad. As an agent developer you will have >>>>>>> to select one or the other at build time, either statically >>>>>>> linked in or dynamic. >>>>>>>> You already added the following statement to the JVMTI spec: >>>>>>>> If a /statically linked/ agent L exports a function called >>>>>>>> Agent_OnLoad_L and >>>>>>>> a function called Agent_OnLoad, the Agent_OnLoad function >>>>>>>> will be ignored. >>>>>>>> >>>>>>>> Could we say it in a shorter form?: >>>>>>>> If a /statically linked/ agent L exports a function called >>>>>>>> Agent_OnLoad, >>>>>>>> the Agent_OnLoad function will be ignored. >>>>>>> I believe I copied this from JNI static linking JEP. If so, I'll >>>>>>> probably leave it as is just for consistency with JNI static >>>>>>> spec. JVM TI static linking spec is closely related to JNI >>>>>>> static linking spec. >>>>>>>> In this context would it be reasonable to add another statement: >>>>>>>> If a /dynamically linked/ agent L exports a function called >>>>>>>> Agent_OnLoad_L, >>>>>>>> the Agent_OnLoad_L function will be ignored. >>>>>>>> >>>>>> I'd rather leave this undefined since the behavior is very >>>>>> platform specific. >>>>>> The way we determine if a library is statically linked is by the >>>>>> presence of the Agent_OnLoad_L function. >>>>>> If this function exists in a dynamically linked library, it will >>>>>> be treated as a static library if by some chance >>>>>> it's attempted to be loaded twice, since the symbol will may be >>>>>> visible in the running process. >>>>>> >>>>>> Bob. >>>>>> >>>>>> >>>>>>>> The same questions apply to the Agent_OnAttach and >>>>>>>> Agent_OnAttach_L entry points. >>>>>>>> >>>>>>> I'm out on vacation for a couple of weeks so I'll leave it up to >>>>>>> Bob V. and yourself if you guys want to hash out >>>>>>> better/different wording. >>>>>>> >>>>>>> bill >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 7/30/13 12:17 PM,bill.pittore at oracle.com wrote: >>>>>>>>> Thanks Serguei for the comments. Some comments inline. I >>>>>>>>> updated the webrevs at >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/26/2013 5:00 AM,serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Bill, >>>>>>>>>> >>>>>>>>>> Sorry for the big delay. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'm suggesting to use the reference >>>>>>>>>> *Agent_OnAttach[_L]**||* even more consistently. >>>>>>>>>> (If, in some cases, you prefer the longer form to underline >>>>>>>>>> the difference between >>>>>>>>>> dynamically and statically linked libraries then feel free to >>>>>>>>>> leave it as it is.) >>>>>>>>>> >>>>>>>>>> It would simplify the following fragments: >>>>>>>>>> >>>>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>>>> Agent_OnAttach function >>>>>>>>>> 305 * or, for a statically linked agent named 'L', the >>>>>>>>>> Agent_OnAttach_L function >>>>>>>>>> ==> >>>>>>>>>> >>>>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>>>> Agent_OnAttach[_L] function >>>>>>>>>> >>>>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>>>> Agent_OnAttach >>>>>>>>>> 410 * function or, for a statically linked agent named >>>>>>>>>> 'L', the >>>>>>>>>> 411 * Agent_OnAttach_L function as >>>>>>>>>> specified in the >>>>>>>>>> ==> >>>>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>>>> Agent_OnAttach[_L] >>>>>>>>>> 410 * function as specified in the >>>>>>>>>> >>>>>>>>> I left the above as is since it's part of the method >>>>>>>>> description. The following fragments below I simplified as you >>>>>>>>> suggested. >>>>>>>>> >>>>>>>>>> the following 4 identical fragments: >>>>>>>>>> >>>>>>>>>> 341 * If the Agent_OnAttach >>>>>>>>>> function returns an error >>>>>>>>>> 342 * or, for a statically linked agent named >>>>>>>>>> 'L', if the >>>>>>>>>> 343 * Agent_OnAttach_L function returns >>>>>>>>>> 344 * an error. >>>>>>>>>> 375 * If the Agent_OnAttach >>>>>>>>>> function returns an error >>>>>>>>>> 376 * or, for a statically linked agent named >>>>>>>>>> 'L', if the >>>>>>>>>> 377 * Agent_OnAttach_L function returns >>>>>>>>>> 378 * an error. >>>>>>>>>> 442 * If the Agent_OnAttach >>>>>>>>>> function returns an error >>>>>>>>>> 443 * or, for a statically linked agent named >>>>>>>>>> 'L', if the >>>>>>>>>> 444 * Agent_OnAttach_L function returns >>>>>>>>>> an error >>>>>>>>>> 475 * If the Agent_OnAttach >>>>>>>>>> function returns an error >>>>>>>>>> 476 * or, for a statically linked agent named >>>>>>>>>> 'L', if the >>>>>>>>>> 477 * Agent_OnAttach_L function returns >>>>>>>>>> 478 * an error. >>>>>>>>>> ==> >>>>>>>>>> >>>>>>>>>> 336 * If the Agent_OnAttach[_L] >>>>>>>>>> function returns an error. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>>> >>>>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>>>> >>>>>>>>>> Lines 442-462: many extra

's. The fragment does not look >>>>>>>>>> well. >>>>>>>>>> I'd suggest to remove most of them. >>>>>>>>>> Also, these lines are too long. Could you make them shorter, >>>>>>>>>> please? >>>>>>>>>> The same is applied to other long new lines in this file. >>>>>>>>> Cleaned this up a bit. >>>>>>>>>> Lines 490-491, 502-503, 505-506: >>>>>>>>>> The same sentence is repeated 3 times: "the agent >>>>>>>>>> library may be statically linked ..." >>>>>>>>>> >>>>>>>>>> 490 Note that the agent library may be statically linked >>>>>>>>>> into the executable >>>>>>>>>> 491 in which case no actual loading takes place. >>>>>>>>> Fixed. >>>>>>>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is >>>>>>>>>> specified, the VM will attempt to >>>>>>>>>> 502 load the shared library >>>>>>>>>> c:\myLibs\foo.dll. As mentioned above, the agent >>>>>>>>>> library may be statically linked into the executable >>>>>>>>>> 503 in which case no actual loading takes place >>>>>>>>>> >>>>>>>>>> 505 Note that the agent library may be statically linked >>>>>>>>>> into the executable >>>>>>>>>> 506 in which case no actual loading takes place. >>>>>>>>>> >>>>>>>>> Tweaked the above a bit to make it less wordy. >>>>>>>>> >>>>>>>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>>>>>>> >>>>>>>>>> 677 and enabled the event >>>>>>>>>> >>>>>>>>> Fixed. >>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>> >>>>>>>>>> - no comments >>>>>>>>>> >>>>>>>>>> src/os/windows/vm/os_windows.cpp >>>>>>>>>> >>>>>>>>>> - no comments >>>>>>>>>> >>>>>>>>>> src/share/vm/prims/jvmtiExport.cpp >>>>>>>>>> >>>>>>>>>> - no comments >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/arguments.hpp >>>>>>>>>> >>>>>>>>>> - no comments >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/os.cpp >>>>>>>>>> >>>>>>>>>> Space is missed after the 'if': >>>>>>>>>> 471 if(entryName != NULL) { >>>>>>>>>> >>>>>>>>> Fixed. >>>>>>>>>> Extra space after the '*': >>>>>>>>>> 483 void * saveHandle; >>>>>>>>>> >>>>>>>>> Fixed. >>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>> >>>>>>>>>> - no comments >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>> >>>>>>>>>> The line has been removed: >>>>>>>>>> 3866 break; >>>>>>>>>> >>>>>>>>> Correct, the inner for loop was removed so no need for the break; >>>>>>>>>> I'm still in process of reading the code. >>>>>>>>>> Another pass is needed to make sure that nothing is missed. >>>>>>>>>> But in general, the code quality is pretty good. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/25/13 10:47 AM,bill.pittore at oracle.com wrote: >>>>>>>>>>> Still need an official reviewer for the hotspot changes for >>>>>>>>>>> statically linked agents. >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> bill >>>>>>>>>>> >>>>>>>>>>>> These changes address bug 8014135 which adds support for >>>>>>>>>>>> statically linked agents in the VM. This is a followup to >>>>>>>>>>>> the recent JNI spec changes that addressed statically >>>>>>>>>>>> linked JNI libraries( 8005716). >>>>>>>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>>>>>>> http://openjdk.java.net/jeps/178 >>>>>>>>>>>> >>>>>>>>>>>> Webrevs are here: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The changes to jvmti.xml can also be seen in the output >>>>>>>>>>>> file that I placed here: >>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> bill >>>>>>>>>>>> >>>>> >>>> >>> >>> >> > > From pbiswal at palantir.com Wed Aug 21 11:24:02 2013 From: pbiswal at palantir.com (Punya Biswal) Date: Wed, 21 Aug 2013 18:24:02 +0000 Subject: JDK7 SIGSEGV with G1 garbage collector In-Reply-To: <5214C063.70307@oracle.com> Message-ID: Hi Bengt, Thanks for the prompt response! Please let me know if I can provide anything else that will be useful. -- Punya Biswal Palantir | Engineer On 8/21/13 6:28 AM, "Bengt Rutisson" wrote: > >Hi again, > >This seems to be a bug in the C2 compiler. I've filed JDK-8023472 to >track this. I'll come back with a URL once this bug is publicly available. > >Thanks again for the great bug report! >Bengt > >On 8/21/13 8:52 AM, Bengt Rutisson wrote: >> >> Hi Punya, >> >> Thank you for the excellent bug report! >> >> I cloned the test case and can reproduce the issue both with 7u25 >> build 15 (that you used) and also with the latest build of JDK8. >> >> I'll dig some more into what is going on and file a bug. Will ping >> this thread when I have more information. >> >> Bengt >> >> On 8/21/13 12:05 AM, Punya Biswal wrote: >>> [Apologies if this message is delivered twice; I sent it once before I >>> realized this was a members-only list.] >>> >>> We're running into a JVM segfault when using a third-party library >>> (Elasticsearch) alongside the G1 garbage collector. This issue has been >>> reported elsewhere (for example, >>> >>>https://urldefense.proofpoint.com/v1/url?u=https://jira.terracotta.org/j >>>ira/browse/CDV-1651&k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=kTrYN051orSRhyA6 >>>mqYxbjRIX%2BBCPm7thmzLC79vBeM%3D%0A&m=eQXvXMfzOBqOYQJCPTAI8m0yYLgOXGzbUN >>>Y%2FyEd6LjE%3D%0A&s=4517eb7bba43d15b07ba2a16457f9371f3d18509f2b13a22de37 >>>6bdb2e19e95f) and might already >>> be on >>> the OpenJDK roadmap. It's usually associated with the use of GNU Trove. >>> >>> We've been able to reduce the amount of code required to reproduce the >>> crash to a short program that reliably crashes on my computer >>> (a MacBook Pro) using only JDK core classes. I've also included the >>> hs_err_* diagnostic file; both are at >>> >>>https://urldefense.proofpoint.com/v1/url?u=https://gist.github.com/punya >>>/6287943&k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=kTrYN051orSRhyA6mqYxbjRIX%2 >>>BBCPm7thmzLC79vBeM%3D%0A&m=eQXvXMfzOBqOYQJCPTAI8m0yYLgOXGzbUNY%2FyEd6LjE >>>%3D%0A&s=1a3b70ed491698a5a44b0fc5d03329444dbe1b093056d9609cf1ff8c57deb28 >>>8 . >>> >>> Does this reduced repro help understand what's going on? >>> >>> >>> A few points of interest: >>> >>> * running with -XX:+UseG1GC -Dcount=100000 always crashes >>> * running with -XX:+UseG1GC -Xint -Dcount=100000 never crashes >>> * running with -Xint -Dcount=100000 never crashes >>> >>> >>> Using -ea and/or -server don't any effect these results. With regard to >>> JVM versions, >>> >>> * it never crashes on JDK 6u51 >>> * it crashes on JDK 7u25 and JDK 7u43 (prerelease) >>> * it never crashes on JDK 8 (prerelease) >>> >>> >>> I'm happy to provide a link to a core dump if that helps. >>> >>> -- >>> Punya Biswal >>> Palantir | Engineer >>> pbiswal at palantir.com | 206 605 2397 >> > From bill.pittore at oracle.com Wed Aug 21 12:33:47 2013 From: bill.pittore at oracle.com (BILL PITTORE) Date: Wed, 21 Aug 2013 15:33:47 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <52150103.1050507@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <52002372.2030302@oracle.com> <52139F64.2050906@oracle.com> <5213F0F1.4020800@oracle.com> <52141557.3020300@oracle.com> <52150103.1050507@oracle.com> Message-ID: <5215161B.4090504@oracle.com> On 8/21/2013 2:03 PM, serguei.spitsyn at oracle.com wrote: > Bill, > > Thumbs up modulo the below comments. > > I've noticed a couple of more minor issues. > Could you, please, make one more clean-up? > > src/os/windows/vm/os_windows.cpp > > There is still some inconsistency in the lines: > 5401 // Builds a platform dependent Agent_OnLoad_ function name > 5411 char* os::build_agent_function_name(const char *sym_name, const char *lib_name, > 5454 // agent_entry_name == _Agent_OnLoad_libName at XX > I'm not sure how to make it better but leave it up to you. > Maybe the line 5454 is Ok as another style is required there. > > > src/share/vm/prims/jvmti.xml > > The lines are still too long: 667, 10773, 10776 > All set, take a look at http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.04/ bill > > Thanks, > Serguei > > > On 8/20/13 6:18 PM, BILL PITTORE wrote: >> Thanks Serguei for the detailed review. I think I captured all the >> tweaks you mentioned and have new webrevs at: >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.03/ >> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.04/ >> >> also you can find the jvmti.html output file at >> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.03/jvmti.html >> >> and the javadoc from VirtualMachine.java at: >> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/ >> >> bill >> >> On 8/20/2013 6:42 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Bill, >>> >>> It looks good in general. >>> >>> Some minor comments. >>> >>> src/share/classes/com/sun/tools/attach/VirtualMachine.java >>> >>> The copyright comment is out-of-date >>> >>> >>> || src/os/posix/vm/os_posix.cpp >>> >>> symName => sym_name >>> >>> src/os/windows/vm/os_windows.cpp >>> >>> 5454 //agent_entry_name == _Agent_OnLoad_libName at XX >>> >>> Need a space after // >>> >>> ||src/share/vm/prims/jvmti.xml >>> >>> The copyright comment is out-of-date. >>> The lines are too long: 520-523, 584, 593, 623, 654, 660, 679, 689. >>> >>> src/share/vm/prims/jvmtiExport.cpp >>> src/share/vm/runtime/arguments.hpp >>> >>> No comments >>> >>> ||src/share/vm/runtime/os.cpp >>> >>> The indentation is incorrect: >>> 456 const char *syms[], size_t syms_len) { >>> >>> The comments are cross-inconsistent (lib_name vs libname): >>> >>> 447 * Support for finding Agent_On(Un)Load/Attach<_lib_name> if it exists. >>> . . . >>> 449 * Agent_OnLoad_lib_name or Agent_OnAttach_lib_name function to determine if >>> . . . >>> 491 // Check for Agent_OnLoad/Attach_libname function >>> . . . >>> 498 // Found an entry point like Agent_OnLoad_libname so we have a static agent >>> >>> ||src/share/vm/runtime/os.hpp >>> >>> 542 // return the handle of this process >>> 543 static void* get_default_process_handle(); >>> 544 >>> 545 // Check for static linked agent library >>> 546 static bool find_builtin_agent(AgentLibrary *agent_lib, const char *syms[], >>> 547 size_t syms_len); >>> 548 >>> 549 // Find agent entry point >>> 550 static void *find_agent_function(AgentLibrary *agent_lib, bool check_lib, >>> 551 const char *syms[], size_t syms_len); The comment at the line #542 should start from capital letter. >>> Wrong indentation at the lines: #547, #551. >>> >>> ||src/share/vm/runtime/thread.cpp >>> >>> Wrong indentation: >>> 3748 on_load_entry = CAST_TO_FN_PTR(OnLoadEntry_t, os::find_agent_function(agent, >>> 3749 false, >>> 3750 on_load_symbols, >>> 3751 num_symbol_entries)); >>> >>> >>> Thanks, >>> Serguei >>> >>> On 8/20/13 9:55 AM, bill.pittore at oracle.com wrote: >>>> I've updated the hotspot and jdk webrevs based on Coleen's and >>>> Serguei's comments. >>>> >>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.03/ >>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.02/ >>>> >>>> thanks, >>>> bill >>>> >>>> >>>> On 8/19/2013 1:13 PM, BILL PITTORE wrote: >>>>> On 8/5/2013 6:13 PM, Coleen Phillimore wrote: >>>>>> >>>>>> Hi Bill, I have some high level comments and other comments. >>>>>> This wasn't as easy to review as Bob promised me! >>>>> :-P >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/src/share/classes/com/sun/tools/attach/VirtualMachine.java.udiff.html >>>>>> >>>>>> paramter (typo - two instances) >>>>>> >>>>>> * @throws AgentInitializationException >>>>>> - * If the Agent_OnAttach function >>>>>> returns an error >>>>>> + * If the Agent_OnAttach[_L] function >>>>>> returns an error. >>>>>> + * an error. >>>>>> * >>>>> Fixed. >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/os/posix/vm/os_posix.cpp.frames.html >>>>>> >>>>>> >>>>>> nameLen, prefixLen, suffixLen - the JVM coding convention (unlike >>>>>> Java) is to have variable names lower case and separated by a _ >>>>>> (not camelcase). Same for all the new code here >>>>>> buildAgentFunctionName. >>>>> Fixed all names. Original code came from JDK which is why I had >>>>> this scheme. >>>>>> >>>>>> Can you put a function above this function to say what it does? >>>>>> So once it's code reviewed, we can quickly know what it does >>>>>> without having to study this again - ie. Is name something like >>>>>> libxxx.so and you're trying to extract lib and .so from it? >>>>>> There's no verification of this at lines 286 and 287 but the code >>>>>> is handling the case of other sorts of unexpected input (ie line >>>>>> 283). Why don't you strip the lib and the .so if !is_absolute_path? >>>>> Added a comment to the above function to describe what's going on. >>>>> For absolute path case, the lib_name is something like >>>>> /a/b/libL.so so we need to strip off the path, the 'lib' prefix >>>>> and the '.so' suffix to get the base name. >>>>>> 291 agentEntryName = NEW_C_HEAP_ARRAY(char, len, mtThread); >>>>>> 292 if (agentEntryName == NULL) { >>>>>> 293 return NULL; >>>>>> 294 } >>>>>> If NEW_C_HEAP_ARRAY fails it terminates the JVM. I think you >>>>>> might want this function instead NEW_C_HEAP_ARRAY_RETURN_NULL if >>>>>> there's a reasonable recovery possible. >>>>>> >>>>> Ok, changed it to the above. >>>>>> os_windows.cpp >>>>>> >>>>>> Same comments as above. Also: >>>>>> >>>>>> 5432 strncat(agentEntryName, name, nameLen); >>>>>> 5433 strcat(agentEntryName, p); >>>>>> 5434 //agentEntryName == _Agent_OnLoad_libName at 12 >>>>>> 5435 } else { >>>>>> You could say why 12 but shouldn't it be the length of the >>>>>> resulting symbol instead and not 12? >>>>> Changed it to '@XX'. It's really the length of the arguments which >>>>> could change in the future, so XX should be fine. >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/os.cpp.frames.html >>>>>> >>>>>> >>>>>> findAgentFunction - same comment about the coding conventions. >>>>>> functions and variables are lower case with underscores. Class >>>>>> names are CamelCase. It would be convenient if the jvm code used >>>>>> the java coding convention but the rest of it doesn't so this new >>>>>> code is inconsistent. This is hard to follow as it is! >>>>>> >>>>> Fixed. >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/thread.cpp.frames.html >>>>>> >>>>>> >>>>>> 3826 size_t num_symbol_entries = sizeof(on_unload_symbols) / >>>>>> sizeof(char*); >>>>>> Why not use ARRAY_SIZE macro? >>>>>> >>>>> Fixed. >>>>>> >>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/prims/jvmtiExport.cpp.frames.html >>>>>> >>>>>> >>>>>> 2208 // Check for builtin agent. If not then if the path is >>>>>> absolute we attempt >>>>>> 2209 // to load the library. Otherwise we try to load it from >>>>>> the standard >>>>>> 2210 // dll directory. >>>>>> I think you are missing the word "found" in this sentence. You >>>>>> are using builtin agent to mean agent defined in a statically >>>>>> linked library, I believe. Can you say that instead? Builtin >>>>>> means that the jvm knows about it and implements it but in this >>>>>> case it doesn't. >>>>> Re-worded this to be more explicit about statically linked in >>>>>> >>>>>> Maybe find_statically_linked_agent() would be a better name for >>>>>> this function? >>>>> I think builtin came from when we did original JNI builitin >>>>> libraries. It might be documented as such in the JEP or CCC. >>>>>> >>>>>> Is the is_valid() function really mean has_been_loaded()? >>>>>> 2236 if (agentLib->valid()) { >>>>> Yes, either it was found statically linked into the executable or >>>>> it was successfully loaded as a shared lib. >>>>>> >>>>>> >>>>>> Did you run the Internal NSK vm.quick.testlist tests on this to >>>>>> verify that nothing breaks? There are a lot of tests with >>>>>> different agents and combinations in that suite and it frequently >>>>>> holds some surprises in this area so best to run it first. Let >>>>>> me know if you need help. >>>>> Ran the vm/nsk tests using UTE. Also we have some new test code to >>>>> test the statically linked agent functionality. >>>>> >>>>> Thanks so much for the excellent review. >>>>> I'll update the webrev as soon as I rebuild and test. >>>>> >>>>> bill >>>>> >>>>>> >>>>>> Coleen >>>>>> >>>>>> On 08/05/2013 10:41 AM, Bob Vandette wrote: >>>>>>> On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: >>>>>>> >>>>>>>> On 8/2/2013 9:12 PM,serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Bill, >>>>>>>>> >>>>>>>>> A couple of more questions. >>>>>>>>> >>>>>>>>> webrev.01/jvmti.html >>>>>>>>> >>>>>>>>> An agent L whose image has been combined with the VM *is >>>>>>>>> defined* as /statically linked/ >>>>>>>>> if and only if the agent exports a function called >>>>>>>>> Agent_OnLoad_L. >>>>>>>>> >>>>>>>>> A question to the above. >>>>>>>>> Are we going to allow to link a library dynamically if it >>>>>>>>> exports both >>>>>>>>> the Agent_OnLoad and Agent_OnLoad_L functions? >>>>>>>>> It can be convenient if a library exports both Agent_OnLoad >>>>>>>>> and Agent_OnLoad_L >>>>>>>>> as it can be linked statically or dynamically depending on the >>>>>>>>> need without changes. >>>>>>>>> >>>>>>>> It would be nice but the problem is that you could only link >>>>>>>> one agent into the VM if it exported Agent_OnLoad. Otherwise >>>>>>>> there would be a symbol collision with the second agent you >>>>>>>> linked in that also had Agent_OnLoad. As an agent developer you >>>>>>>> will have to select one or the other at build time, either >>>>>>>> statically linked in or dynamic. >>>>>>>>> You already added the following statement to the JVMTI spec: >>>>>>>>> If a /statically linked/ agent L exports a function called >>>>>>>>> Agent_OnLoad_L and >>>>>>>>> a function called Agent_OnLoad, the Agent_OnLoad function >>>>>>>>> will be ignored. >>>>>>>>> >>>>>>>>> Could we say it in a shorter form?: >>>>>>>>> If a /statically linked/ agent L exports a function called >>>>>>>>> Agent_OnLoad, >>>>>>>>> the Agent_OnLoad function will be ignored. >>>>>>>> I believe I copied this from JNI static linking JEP. If so, >>>>>>>> I'll probably leave it as is just for consistency with JNI >>>>>>>> static spec. JVM TI static linking spec is closely related to >>>>>>>> JNI static linking spec. >>>>>>>>> In this context would it be reasonable to add another statement: >>>>>>>>> If a /dynamically linked/ agent L exports a function called >>>>>>>>> Agent_OnLoad_L, >>>>>>>>> the Agent_OnLoad_L function will be ignored. >>>>>>>>> >>>>>>> I'd rather leave this undefined since the behavior is very >>>>>>> platform specific. >>>>>>> The way we determine if a library is statically linked is by the >>>>>>> presence of the Agent_OnLoad_L function. >>>>>>> If this function exists in a dynamically linked library, it will >>>>>>> be treated as a static library if by some chance >>>>>>> it's attempted to be loaded twice, since the symbol will may be >>>>>>> visible in the running process. >>>>>>> >>>>>>> Bob. >>>>>>> >>>>>>> >>>>>>>>> The same questions apply to the Agent_OnAttach and >>>>>>>>> Agent_OnAttach_L entry points. >>>>>>>>> >>>>>>>> I'm out on vacation for a couple of weeks so I'll leave it up >>>>>>>> to Bob V. and yourself if you guys want to hash out >>>>>>>> better/different wording. >>>>>>>> >>>>>>>> bill >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/30/13 12:17 PM,bill.pittore at oracle.com wrote: >>>>>>>>>> Thanks Serguei for the comments. Some comments inline. I >>>>>>>>>> updated the webrevs at >>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/26/2013 5:00 AM,serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi Bill, >>>>>>>>>>> >>>>>>>>>>> Sorry for the big delay. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'm suggesting to use the reference >>>>>>>>>>> *Agent_OnAttach[_L]**||* even more consistently. >>>>>>>>>>> (If, in some cases, you prefer the longer form to underline >>>>>>>>>>> the difference between >>>>>>>>>>> dynamically and statically linked libraries then feel free >>>>>>>>>>> to leave it as it is.) >>>>>>>>>>> >>>>>>>>>>> It would simplify the following fragments: >>>>>>>>>>> >>>>>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>>>>> Agent_OnAttach function >>>>>>>>>>> 305 * or, for a statically linked agent named 'L', the >>>>>>>>>>> Agent_OnAttach_L function >>>>>>>>>>> ==> >>>>>>>>>>> >>>>>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>>>>> Agent_OnAttach[_L] function >>>>>>>>>>> >>>>>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>>>>> Agent_OnAttach >>>>>>>>>>> 410 * function or, for a statically linked agent named >>>>>>>>>>> 'L', the >>>>>>>>>>> 411 * Agent_OnAttach_L function as >>>>>>>>>>> specified in the >>>>>>>>>>> ==> >>>>>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>>>>> Agent_OnAttach[_L] >>>>>>>>>>> 410 * function as specified in the >>>>>>>>>>> >>>>>>>>>> I left the above as is since it's part of the method >>>>>>>>>> description. The following fragments below I simplified as >>>>>>>>>> you suggested. >>>>>>>>>> >>>>>>>>>>> the following 4 identical fragments: >>>>>>>>>>> >>>>>>>>>>> 341 * If the Agent_OnAttach >>>>>>>>>>> function returns an error >>>>>>>>>>> 342 * or, for a statically linked agent >>>>>>>>>>> named 'L', if the >>>>>>>>>>> 343 * Agent_OnAttach_L function returns >>>>>>>>>>> 344 * an error. >>>>>>>>>>> 375 * If the Agent_OnAttach >>>>>>>>>>> function returns an error >>>>>>>>>>> 376 * or, for a statically linked agent >>>>>>>>>>> named 'L', if the >>>>>>>>>>> 377 * Agent_OnAttach_L function returns >>>>>>>>>>> 378 * an error. >>>>>>>>>>> 442 * If the Agent_OnAttach >>>>>>>>>>> function returns an error >>>>>>>>>>> 443 * or, for a statically linked agent >>>>>>>>>>> named 'L', if the >>>>>>>>>>> 444 * Agent_OnAttach_L function returns >>>>>>>>>>> an error >>>>>>>>>>> 475 * If the Agent_OnAttach >>>>>>>>>>> function returns an error >>>>>>>>>>> 476 * or, for a statically linked agent >>>>>>>>>>> named 'L', if the >>>>>>>>>>> 477 * Agent_OnAttach_L function returns >>>>>>>>>>> 478 * an error. >>>>>>>>>>> ==> >>>>>>>>>>> >>>>>>>>>>> 336 * If the Agent_OnAttach[_L] >>>>>>>>>>> function returns an error. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>>>> >>>>>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>>>>> >>>>>>>>>>> Lines 442-462: many extra

's. The fragment does not >>>>>>>>>>> look well. >>>>>>>>>>> I'd suggest to remove most of them. >>>>>>>>>>> Also, these lines are too long. Could you make them shorter, >>>>>>>>>>> please? >>>>>>>>>>> The same is applied to other long new lines in this file. >>>>>>>>>> Cleaned this up a bit. >>>>>>>>>>> Lines 490-491, 502-503, 505-506: >>>>>>>>>>> The same sentence is repeated 3 times: "the agent >>>>>>>>>>> library may be statically linked ..." >>>>>>>>>>> >>>>>>>>>>> 490 Note that the agent library may be statically linked >>>>>>>>>>> into the executable >>>>>>>>>>> 491 in which case no actual loading takes place. >>>>>>>>>> Fixed. >>>>>>>>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is >>>>>>>>>>> specified, the VM will attempt to >>>>>>>>>>> 502 load the shared library >>>>>>>>>>> c:\myLibs\foo.dll. As mentioned above, the >>>>>>>>>>> agent library may be statically linked into the executable >>>>>>>>>>> 503 in which case no actual loading takes place >>>>>>>>>>> >>>>>>>>>>> 505 Note that the agent library may be statically linked >>>>>>>>>>> into the executable >>>>>>>>>>> 506 in which case no actual loading takes place. >>>>>>>>>>> >>>>>>>>>> Tweaked the above a bit to make it less wordy. >>>>>>>>>> >>>>>>>>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>>>>>>>> >>>>>>>>>>> 677 and enabled the event >>>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>> >>>>>>>>>>> - no comments >>>>>>>>>>> >>>>>>>>>>> src/os/windows/vm/os_windows.cpp >>>>>>>>>>> >>>>>>>>>>> - no comments >>>>>>>>>>> >>>>>>>>>>> src/share/vm/prims/jvmtiExport.cpp >>>>>>>>>>> >>>>>>>>>>> - no comments >>>>>>>>>>> >>>>>>>>>>> src/share/vm/runtime/arguments.hpp >>>>>>>>>>> >>>>>>>>>>> - no comments >>>>>>>>>>> >>>>>>>>>>> src/share/vm/runtime/os.cpp >>>>>>>>>>> >>>>>>>>>>> Space is missed after the 'if': >>>>>>>>>>> 471 if(entryName != NULL) { >>>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>>> Extra space after the '*': >>>>>>>>>>> 483 void * saveHandle; >>>>>>>>>>> >>>>>>>>>> Fixed. >>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>> >>>>>>>>>>> - no comments >>>>>>>>>>> >>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>> >>>>>>>>>>> The line has been removed: >>>>>>>>>>> 3866 break; >>>>>>>>>>> >>>>>>>>>> Correct, the inner for loop was removed so no need for the >>>>>>>>>> break; >>>>>>>>>>> I'm still in process of reading the code. >>>>>>>>>>> Another pass is needed to make sure that nothing is missed. >>>>>>>>>>> But in general, the code quality is pretty good. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 7/25/13 10:47 AM,bill.pittore at oracle.com wrote: >>>>>>>>>>>> Still need an official reviewer for the hotspot changes for >>>>>>>>>>>> statically linked agents. >>>>>>>>>>>> >>>>>>>>>>>> thanks, >>>>>>>>>>>> bill >>>>>>>>>>>> >>>>>>>>>>>>> These changes address bug 8014135 which adds support for >>>>>>>>>>>>> statically linked agents in the VM. This is a followup to >>>>>>>>>>>>> the recent JNI spec changes that addressed statically >>>>>>>>>>>>> linked JNI libraries( 8005716). >>>>>>>>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>>>>>>>> http://openjdk.java.net/jeps/178 >>>>>>>>>>>>> >>>>>>>>>>>>> Webrevs are here: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The changes to jvmti.xml can also be seen in the output >>>>>>>>>>>>> file that I placed here: >>>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> bill >>>>>>>>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From serguei.spitsyn at oracle.com Wed Aug 21 12:44:35 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 21 Aug 2013 12:44:35 -0700 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <5215161B.4090504@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <52002372.2030302@oracle.com> <52139F64.2050906@oracle.com> <5213F0F1.4020800@oracle.com> <52141557.3020300@oracle.com> <52150103.1050507@oracle.com> <5215161B.4090504@oracle.com> Message-ID: <521518A3.8010707@oracle.com> Looks good. Thank you for the changes! Serguei On 8/21/13 12:33 PM, BILL PITTORE wrote: > On 8/21/2013 2:03 PM, serguei.spitsyn at oracle.com wrote: >> Bill, >> >> Thumbs up modulo the below comments. >> >> I've noticed a couple of more minor issues. >> Could you, please, make one more clean-up? >> >> src/os/windows/vm/os_windows.cpp >> >> There is still some inconsistency in the lines: >> 5401 // Builds a platform dependent Agent_OnLoad_ function name >> 5411 char* os::build_agent_function_name(const char *sym_name, const char *lib_name, >> 5454 // agent_entry_name == _Agent_OnLoad_libName at XX >> I'm not sure how to make it better but leave it up to you. >> Maybe the line 5454 is Ok as another style is required there. >> >> >> src/share/vm/prims/jvmti.xml >> >> The lines are still too long: 667, 10773, 10776 >> > All set, take a look at > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.04/ > > bill > >> >> Thanks, >> Serguei >> >> >> On 8/20/13 6:18 PM, BILL PITTORE wrote: >>> Thanks Serguei for the detailed review. I think I captured all the >>> tweaks you mentioned and have new webrevs at: >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.03/ >>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.04/ >>> >>> also you can find the jvmti.html output file at >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.03/jvmti.html >>> >>> and the javadoc from VirtualMachine.java at: >>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/ >>> >>> bill >>> >>> On 8/20/2013 6:42 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Bill, >>>> >>>> It looks good in general. >>>> >>>> Some minor comments. >>>> >>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java >>>> >>>> The copyright comment is out-of-date >>>> >>>> >>>> || src/os/posix/vm/os_posix.cpp >>>> >>>> symName => sym_name >>>> >>>> src/os/windows/vm/os_windows.cpp >>>> >>>> 5454 //agent_entry_name == _Agent_OnLoad_libName at XX >>>> >>>> Need a space after // >>>> >>>> ||src/share/vm/prims/jvmti.xml >>>> >>>> The copyright comment is out-of-date. >>>> The lines are too long: 520-523, 584, 593, 623, 654, 660, 679, 689. >>>> >>>> src/share/vm/prims/jvmtiExport.cpp >>>> src/share/vm/runtime/arguments.hpp >>>> >>>> No comments >>>> >>>> ||src/share/vm/runtime/os.cpp >>>> >>>> The indentation is incorrect: >>>> 456 const char *syms[], size_t syms_len) { >>>> >>>> The comments are cross-inconsistent (lib_name vs libname): >>>> >>>> 447 * Support for finding Agent_On(Un)Load/Attach<_lib_name> if it exists. >>>> . . . >>>> 449 * Agent_OnLoad_lib_name or Agent_OnAttach_lib_name function to determine if >>>> . . . >>>> 491 // Check for Agent_OnLoad/Attach_libname function >>>> . . . >>>> 498 // Found an entry point like Agent_OnLoad_libname so we have a static agent >>>> >>>> ||src/share/vm/runtime/os.hpp >>>> >>>> 542 // return the handle of this process >>>> 543 static void* get_default_process_handle(); >>>> 544 >>>> 545 // Check for static linked agent library >>>> 546 static bool find_builtin_agent(AgentLibrary *agent_lib, const char *syms[], >>>> 547 size_t syms_len); >>>> 548 >>>> 549 // Find agent entry point >>>> 550 static void *find_agent_function(AgentLibrary *agent_lib, bool check_lib, >>>> 551 const char *syms[], size_t syms_len); The comment at the line #542 should start from capital letter. >>>> Wrong indentation at the lines: #547, #551. >>>> >>>> ||src/share/vm/runtime/thread.cpp >>>> >>>> Wrong indentation: >>>> 3748 on_load_entry = CAST_TO_FN_PTR(OnLoadEntry_t, os::find_agent_function(agent, >>>> 3749 false, >>>> 3750 on_load_symbols, >>>> 3751 num_symbol_entries)); >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 8/20/13 9:55 AM, bill.pittore at oracle.com wrote: >>>>> I've updated the hotspot and jdk webrevs based on Coleen's and >>>>> Serguei's comments. >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.03/ >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.02/ >>>>> >>>>> thanks, >>>>> bill >>>>> >>>>> >>>>> On 8/19/2013 1:13 PM, BILL PITTORE wrote: >>>>>> On 8/5/2013 6:13 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi Bill, I have some high level comments and other comments. >>>>>>> This wasn't as easy to review as Bob promised me! >>>>>> :-P >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/src/share/classes/com/sun/tools/attach/VirtualMachine.java.udiff.html >>>>>>> >>>>>>> paramter (typo - two instances) >>>>>>> >>>>>>> * @throws AgentInitializationException >>>>>>> - * If the Agent_OnAttach function >>>>>>> returns an error >>>>>>> + * If the Agent_OnAttach[_L] function >>>>>>> returns an error. >>>>>>> + * an error. >>>>>>> * >>>>>> Fixed. >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/os/posix/vm/os_posix.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> nameLen, prefixLen, suffixLen - the JVM coding convention >>>>>>> (unlike Java) is to have variable names lower case and separated >>>>>>> by a _ (not camelcase). Same for all the new code here >>>>>>> buildAgentFunctionName. >>>>>> Fixed all names. Original code came from JDK which is why I had >>>>>> this scheme. >>>>>>> >>>>>>> Can you put a function above this function to say what it does? >>>>>>> So once it's code reviewed, we can quickly know what it does >>>>>>> without having to study this again - ie. Is name something like >>>>>>> libxxx.so and you're trying to extract lib and .so from it? >>>>>>> There's no verification of this at lines 286 and 287 but the >>>>>>> code is handling the case of other sorts of unexpected input (ie >>>>>>> line 283). Why don't you strip the lib and the .so if >>>>>>> !is_absolute_path? >>>>>> Added a comment to the above function to describe what's going >>>>>> on. For absolute path case, the lib_name is something like >>>>>> /a/b/libL.so so we need to strip off the path, the 'lib' prefix >>>>>> and the '.so' suffix to get the base name. >>>>>>> 291 agentEntryName = NEW_C_HEAP_ARRAY(char, len, mtThread); >>>>>>> 292 if (agentEntryName == NULL) { >>>>>>> 293 return NULL; >>>>>>> 294 } >>>>>>> If NEW_C_HEAP_ARRAY fails it terminates the JVM. I think you >>>>>>> might want this function instead NEW_C_HEAP_ARRAY_RETURN_NULL if >>>>>>> there's a reasonable recovery possible. >>>>>>> >>>>>> Ok, changed it to the above. >>>>>>> os_windows.cpp >>>>>>> >>>>>>> Same comments as above. Also: >>>>>>> >>>>>>> 5432 strncat(agentEntryName, name, nameLen); >>>>>>> 5433 strcat(agentEntryName, p); >>>>>>> 5434 //agentEntryName == _Agent_OnLoad_libName at 12 >>>>>>> 5435 } else { >>>>>>> You could say why 12 but shouldn't it be the length of the >>>>>>> resulting symbol instead and not 12? >>>>>> Changed it to '@XX'. It's really the length of the arguments >>>>>> which could change in the future, so XX should be fine. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/os.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> findAgentFunction - same comment about the coding conventions. >>>>>>> functions and variables are lower case with underscores. Class >>>>>>> names are CamelCase. It would be convenient if the jvm code >>>>>>> used the java coding convention but the rest of it doesn't so >>>>>>> this new code is inconsistent. This is hard to follow as it is! >>>>>>> >>>>>> Fixed. >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/thread.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> 3826 size_t num_symbol_entries = sizeof(on_unload_symbols) / >>>>>>> sizeof(char*); >>>>>>> Why not use ARRAY_SIZE macro? >>>>>>> >>>>>> Fixed. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/prims/jvmtiExport.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> 2208 // Check for builtin agent. If not then if the path is >>>>>>> absolute we attempt >>>>>>> 2209 // to load the library. Otherwise we try to load it from >>>>>>> the standard >>>>>>> 2210 // dll directory. >>>>>>> I think you are missing the word "found" in this sentence. You >>>>>>> are using builtin agent to mean agent defined in a statically >>>>>>> linked library, I believe. Can you say that instead? Builtin >>>>>>> means that the jvm knows about it and implements it but in this >>>>>>> case it doesn't. >>>>>> Re-worded this to be more explicit about statically linked in >>>>>>> >>>>>>> Maybe find_statically_linked_agent() would be a better name for >>>>>>> this function? >>>>>> I think builtin came from when we did original JNI builitin >>>>>> libraries. It might be documented as such in the JEP or CCC. >>>>>>> >>>>>>> Is the is_valid() function really mean has_been_loaded()? >>>>>>> 2236 if (agentLib->valid()) { >>>>>> Yes, either it was found statically linked into the executable or >>>>>> it was successfully loaded as a shared lib. >>>>>>> >>>>>>> >>>>>>> Did you run the Internal NSK vm.quick.testlist tests on this to >>>>>>> verify that nothing breaks? There are a lot of tests with >>>>>>> different agents and combinations in that suite and it >>>>>>> frequently holds some surprises in this area so best to run it >>>>>>> first. Let me know if you need help. >>>>>> Ran the vm/nsk tests using UTE. Also we have some new test code >>>>>> to test the statically linked agent functionality. >>>>>> >>>>>> Thanks so much for the excellent review. >>>>>> I'll update the webrev as soon as I rebuild and test. >>>>>> >>>>>> bill >>>>>> >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> On 08/05/2013 10:41 AM, Bob Vandette wrote: >>>>>>>> On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: >>>>>>>> >>>>>>>>> On 8/2/2013 9:12 PM,serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Bill, >>>>>>>>>> >>>>>>>>>> A couple of more questions. >>>>>>>>>> >>>>>>>>>> webrev.01/jvmti.html >>>>>>>>>> >>>>>>>>>> An agent L whose image has been combined with the VM *is >>>>>>>>>> defined* as /statically linked/ >>>>>>>>>> if and only if the agent exports a function called >>>>>>>>>> Agent_OnLoad_L. >>>>>>>>>> >>>>>>>>>> A question to the above. >>>>>>>>>> Are we going to allow to link a library dynamically if it >>>>>>>>>> exports both >>>>>>>>>> the Agent_OnLoad and Agent_OnLoad_L functions? >>>>>>>>>> It can be convenient if a library exports both Agent_OnLoad >>>>>>>>>> and Agent_OnLoad_L >>>>>>>>>> as it can be linked statically or dynamically depending on >>>>>>>>>> the need without changes. >>>>>>>>>> >>>>>>>>> It would be nice but the problem is that you could only link >>>>>>>>> one agent into the VM if it exported Agent_OnLoad. Otherwise >>>>>>>>> there would be a symbol collision with the second agent you >>>>>>>>> linked in that also had Agent_OnLoad. As an agent developer >>>>>>>>> you will have to select one or the other at build time, either >>>>>>>>> statically linked in or dynamic. >>>>>>>>>> You already added the following statement to the JVMTI spec: >>>>>>>>>> If a /statically linked/ agent L exports a function called >>>>>>>>>> Agent_OnLoad_L and >>>>>>>>>> a function called Agent_OnLoad, the Agent_OnLoad function >>>>>>>>>> will be ignored. >>>>>>>>>> >>>>>>>>>> Could we say it in a shorter form?: >>>>>>>>>> If a /statically linked/ agent L exports a function called >>>>>>>>>> Agent_OnLoad, >>>>>>>>>> the Agent_OnLoad function will be ignored. >>>>>>>>> I believe I copied this from JNI static linking JEP. If so, >>>>>>>>> I'll probably leave it as is just for consistency with JNI >>>>>>>>> static spec. JVM TI static linking spec is closely related to >>>>>>>>> JNI static linking spec. >>>>>>>>>> In this context would it be reasonable to add another statement: >>>>>>>>>> If a /dynamically linked/ agent L exports a function called >>>>>>>>>> Agent_OnLoad_L, >>>>>>>>>> the Agent_OnLoad_L function will be ignored. >>>>>>>>>> >>>>>>>> I'd rather leave this undefined since the behavior is very >>>>>>>> platform specific. >>>>>>>> The way we determine if a library is statically linked is by >>>>>>>> the presence of the Agent_OnLoad_L function. >>>>>>>> If this function exists in a dynamically linked library, it >>>>>>>> will be treated as a static library if by some chance >>>>>>>> it's attempted to be loaded twice, since the symbol will may be >>>>>>>> visible in the running process. >>>>>>>> >>>>>>>> Bob. >>>>>>>> >>>>>>>> >>>>>>>>>> The same questions apply to the Agent_OnAttach and >>>>>>>>>> Agent_OnAttach_L entry points. >>>>>>>>>> >>>>>>>>> I'm out on vacation for a couple of weeks so I'll leave it up >>>>>>>>> to Bob V. and yourself if you guys want to hash out >>>>>>>>> better/different wording. >>>>>>>>> >>>>>>>>> bill >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/30/13 12:17 PM,bill.pittore at oracle.com wrote: >>>>>>>>>>> Thanks Serguei for the comments. Some comments inline. I >>>>>>>>>>> updated the webrevs at >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 7/26/2013 5:00 AM,serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Hi Bill, >>>>>>>>>>>> >>>>>>>>>>>> Sorry for the big delay. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'm suggesting to use the reference >>>>>>>>>>>> *Agent_OnAttach[_L]**||* even more consistently. >>>>>>>>>>>> (If, in some cases, you prefer the longer form to underline >>>>>>>>>>>> the difference between >>>>>>>>>>>> dynamically and statically linked libraries then feel free >>>>>>>>>>>> to leave it as it is.) >>>>>>>>>>>> >>>>>>>>>>>> It would simplify the following fragments: >>>>>>>>>>>> >>>>>>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>>>>>> Agent_OnAttach function >>>>>>>>>>>> 305 * or, for a statically linked agent named 'L', the >>>>>>>>>>>> Agent_OnAttach_L function >>>>>>>>>>>> ==> >>>>>>>>>>>> >>>>>>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>>>>>> Agent_OnAttach[_L] function >>>>>>>>>>>> >>>>>>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>>>>>> Agent_OnAttach >>>>>>>>>>>> 410 * function or, for a statically linked agent named >>>>>>>>>>>> 'L', the >>>>>>>>>>>> 411 * Agent_OnAttach_L function as >>>>>>>>>>>> specified in the >>>>>>>>>>>> ==> >>>>>>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>>>>>> Agent_OnAttach[_L] >>>>>>>>>>>> 410 * function as specified in the >>>>>>>>>>>> >>>>>>>>>>> I left the above as is since it's part of the method >>>>>>>>>>> description. The following fragments below I simplified as >>>>>>>>>>> you suggested. >>>>>>>>>>> >>>>>>>>>>>> the following 4 identical fragments: >>>>>>>>>>>> >>>>>>>>>>>> 341 * If the Agent_OnAttach >>>>>>>>>>>> function returns an error >>>>>>>>>>>> 342 * or, for a statically linked agent >>>>>>>>>>>> named 'L', if the >>>>>>>>>>>> 343 * Agent_OnAttach_L function returns >>>>>>>>>>>> 344 * an error. >>>>>>>>>>>> 375 * If the Agent_OnAttach >>>>>>>>>>>> function returns an error >>>>>>>>>>>> 376 * or, for a statically linked agent >>>>>>>>>>>> named 'L', if the >>>>>>>>>>>> 377 * Agent_OnAttach_L function returns >>>>>>>>>>>> 378 * an error. >>>>>>>>>>>> 442 * If the Agent_OnAttach >>>>>>>>>>>> function returns an error >>>>>>>>>>>> 443 * or, for a statically linked agent >>>>>>>>>>>> named 'L', if the >>>>>>>>>>>> 444 * Agent_OnAttach_L function returns >>>>>>>>>>>> an error >>>>>>>>>>>> 475 * If the Agent_OnAttach >>>>>>>>>>>> function returns an error >>>>>>>>>>>> 476 * or, for a statically linked agent >>>>>>>>>>>> named 'L', if the >>>>>>>>>>>> 477 * Agent_OnAttach_L function returns >>>>>>>>>>>> 478 * an error. >>>>>>>>>>>> ==> >>>>>>>>>>>> >>>>>>>>>>>> 336 * If the Agent_OnAttach[_L] >>>>>>>>>>>> function returns an error. >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>>>>>> >>>>>>>>>>>> Lines 442-462: many extra

's. The fragment does not >>>>>>>>>>>> look well. >>>>>>>>>>>> I'd suggest to remove most of them. >>>>>>>>>>>> Also, these lines are too long. Could you make them >>>>>>>>>>>> shorter, please? >>>>>>>>>>>> The same is applied to other long new lines in this file. >>>>>>>>>>> Cleaned this up a bit. >>>>>>>>>>>> Lines 490-491, 502-503, 505-506: >>>>>>>>>>>> The same sentence is repeated 3 times: "the agent >>>>>>>>>>>> library may be statically linked ..." >>>>>>>>>>>> >>>>>>>>>>>> 490 Note that the agent library may be statically >>>>>>>>>>>> linked into the executable >>>>>>>>>>>> 491 in which case no actual loading takes place. >>>>>>>>>>> Fixed. >>>>>>>>>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is >>>>>>>>>>>> specified, the VM will attempt to >>>>>>>>>>>> 502 load the shared library >>>>>>>>>>>> c:\myLibs\foo.dll. As mentioned above, the >>>>>>>>>>>> agent library may be statically linked into the executable >>>>>>>>>>>> 503 in which case no actual loading takes place >>>>>>>>>>>> >>>>>>>>>>>> 505 Note that the agent library may be statically >>>>>>>>>>>> linked into the executable >>>>>>>>>>>> 506 in which case no actual loading takes place. >>>>>>>>>>>> >>>>>>>>>>> Tweaked the above a bit to make it less wordy. >>>>>>>>>>> >>>>>>>>>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>>>>>>>>> >>>>>>>>>>>> 677 and enabled the event >>>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>> >>>>>>>>>>>> - no comments >>>>>>>>>>>> >>>>>>>>>>>> src/os/windows/vm/os_windows.cpp >>>>>>>>>>>> >>>>>>>>>>>> - no comments >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/prims/jvmtiExport.cpp >>>>>>>>>>>> >>>>>>>>>>>> - no comments >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/runtime/arguments.hpp >>>>>>>>>>>> >>>>>>>>>>>> - no comments >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/runtime/os.cpp >>>>>>>>>>>> >>>>>>>>>>>> Space is missed after the 'if': >>>>>>>>>>>> 471 if(entryName != NULL) { >>>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>>> Extra space after the '*': >>>>>>>>>>>> 483 void * saveHandle; >>>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>> >>>>>>>>>>>> - no comments >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>> >>>>>>>>>>>> The line has been removed: >>>>>>>>>>>> 3866 break; >>>>>>>>>>>> >>>>>>>>>>> Correct, the inner for loop was removed so no need for the >>>>>>>>>>> break; >>>>>>>>>>>> I'm still in process of reading the code. >>>>>>>>>>>> Another pass is needed to make sure that nothing is missed. >>>>>>>>>>>> But in general, the code quality is pretty good. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 7/25/13 10:47 AM,bill.pittore at oracle.com wrote: >>>>>>>>>>>>> Still need an official reviewer for the hotspot changes >>>>>>>>>>>>> for statically linked agents. >>>>>>>>>>>>> >>>>>>>>>>>>> thanks, >>>>>>>>>>>>> bill >>>>>>>>>>>>> >>>>>>>>>>>>>> These changes address bug 8014135 which adds support for >>>>>>>>>>>>>> statically linked agents in the VM. This is a followup to >>>>>>>>>>>>>> the recent JNI spec changes that addressed statically >>>>>>>>>>>>>> linked JNI libraries( 8005716). >>>>>>>>>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>>>>>>>>> http://openjdk.java.net/jeps/178 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Webrevs are here: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The changes to jvmti.xml can also be seen in the output >>>>>>>>>>>>>> file that I placed here: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> bill >>>>>>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > From christian.thalinger at oracle.com Wed Aug 21 13:27:06 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Aug 2013 13:27:06 -0700 Subject: RFR (L): 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment In-Reply-To: <5214FF1C.9050702@oracle.com> References: <5214FF1C.9050702@oracle.com> Message-ID: On Aug 21, 2013, at 10:55 AM, Coleen Phillimore wrote: > > Hi, > > I've reviewed this change and I don't know how it can work. You cannot put uncompressed oops in an object when the setting is UseCompressedOops and have garbage collection work. This is not the main use case for these methods. Sometimes oops are not compressed even when we run with compressed oops as for the Klass::_java_mirror case. There may be other fields like this but I don't know about them. > Similarly you can't compress arbitrary metadata because only Klass* types can be compressed. This doesn't seem like it would work at all. Currently get/putMetadata only supports StorageMode.UNCOMPRESSED_KLASS and StorageMode.COMPRESSED_KLASS. We might add other storage modes in the future if we decide to compress other things. > Also, we lay out objects in classFileParser assuming the setting of UseCompressedOops/ClassPointers and allocates space based on that. > > I don't understand the motivation of this change. It appears incorrect. The motivation is to enable Java code which is tightly coupled to the VM to read and possibly write such fields. Right now it is not possible. > > From reading the bug, it seems that you want to get to mirror from InstanceKlass from Java. This will break when we move the mirror. As said above, since it's tightly coupled to the VM we will notice very soon when something changes and will change the Java code accordingly. -- Chris > > Coleen > > On 8/19/2013 5:28 PM, Christian Thalinger wrote: >> http://cr.openjdk.java.net/~twisti/8022853/webrev/ >> http://cr.openjdk.java.net/~twisti/8022853-jdk/webrev/ >> >> 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment >> Reviewed-by: >> >> In some native data structures of the VM oops are stored uncompressed when compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. >> > From coleen.phillimore at oracle.com Wed Aug 21 13:58:21 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 21 Aug 2013 16:58:21 -0400 Subject: RFR (L): 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment In-Reply-To: References: <5214FF1C.9050702@oracle.com> Message-ID: <521529ED.3070702@oracle.com> On 8/21/2013 4:27 PM, Christian Thalinger wrote: > On Aug 21, 2013, at 10:55 AM, Coleen Phillimore wrote: > >> Hi, >> >> I've reviewed this change and I don't know how it can work. You cannot put uncompressed oops in an object when the setting is UseCompressedOops and have garbage collection work. > This is not the main use case for these methods. Sometimes oops are not compressed even when we run with compressed oops as for the Klass::_java_mirror case. There may be other fields like this but I don't know about them. The other fields are subject to change also. If there is a specific use case, why not add a JVM_blah entry for that use case? Reading this code it is completely unclear that the objects passed in are actually Hotspot metadata. We don't export metadata to Java. From this code, there is no checking what this is allowed to do. It's too general purpose, when you have some specific use case in mind. > >> Similarly you can't compress arbitrary metadata because only Klass* types can be compressed. This doesn't seem like it would work at all. > Currently get/putMetadata only supports StorageMode.UNCOMPRESSED_KLASS and StorageMode.COMPRESSED_KLASS. We might add other storage modes in the future if we decide to compress other things. There is no indication of this from the code. From the code, these things are oops, when they are not? We use type checking in C++ and Java is supposed to be even safer. > >> Also, we lay out objects in classFileParser assuming the setting of UseCompressedOops/ClassPointers and allocates space based on that. >> >> I don't understand the motivation of this change. It appears incorrect. > The motivation is to enable Java code which is tightly coupled to the VM to read and possibly write such fields. Right now it is not possible. Which fields and why? Some sort of compiler interface is probably more appropriate where you can ask the JVM with native calls what you need to know. >> From reading the bug, it seems that you want to get to mirror from InstanceKlass from Java. This will break when we move the mirror. > As said above, since it's tightly coupled to the VM we will notice very soon when something changes and will change the Java code accordingly. I have to believe that there is a better way to do this. Actually, I have ideas how to do this that might also work for the SA. The last thing we want to see is another bunch of Java code tightly coupled with the jvm implementation in another place with another implementation. Coleen > > -- Chris > >> Coleen >> >> On 8/19/2013 5:28 PM, Christian Thalinger wrote: >>> http://cr.openjdk.java.net/~twisti/8022853/webrev/ >>> http://cr.openjdk.java.net/~twisti/8022853-jdk/webrev/ >>> >>> 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment >>> Reviewed-by: >>> >>> In some native data structures of the VM oops are stored uncompressed when compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. >>> From karen.kinnear at oracle.com Wed Aug 21 14:05:32 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 21 Aug 2013 17:05:32 -0400 Subject: RFR (L): 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment In-Reply-To: <521529ED.3070702@oracle.com> References: <5214FF1C.9050702@oracle.com> <521529ED.3070702@oracle.com> Message-ID: <7789A2FB-3266-4CC5-976A-556733DABD82@oracle.com> I have to second what Coleen is saying. Longer term, we need to think about a compiler interface, with specific calls for specific metadata fields, rather than reaching in directly to read and write internal vm metadata. This approach makes it hard to maintain without having to keep both sides in sync and "knowing" who is accessing what metadata - in case we need to change layout, or atomicity, or make fields conditional, etc. etc. Love to have that discussion independent of this particular unsafe extension. thanks, Karen On Aug 21, 2013, at 4:58 PM, Coleen Phillimore wrote: > On 8/21/2013 4:27 PM, Christian Thalinger wrote: >> On Aug 21, 2013, at 10:55 AM, Coleen Phillimore wrote: >> >>> Hi, >>> >>> I've reviewed this change and I don't know how it can work. You cannot put uncompressed oops in an object when the setting is UseCompressedOops and have garbage collection work. >> This is not the main use case for these methods. Sometimes oops are not compressed even when we run with compressed oops as for the Klass::_java_mirror case. There may be other fields like this but I don't know about them. > > The other fields are subject to change also. If there is a specific use case, why not add a JVM_blah entry for that use case? Reading this code it is completely unclear that the objects passed in are actually Hotspot metadata. We don't export metadata to Java. From this code, there is no checking what this is allowed to do. It's too general purpose, when you have some specific use case in mind. > >> >>> Similarly you can't compress arbitrary metadata because only Klass* types can be compressed. This doesn't seem like it would work at all. >> Currently get/putMetadata only supports StorageMode.UNCOMPRESSED_KLASS and StorageMode.COMPRESSED_KLASS. We might add other storage modes in the future if we decide to compress other things. > > There is no indication of this from the code. From the code, these things are oops, when they are not? We use type checking in C++ and Java is supposed to be even safer. > >> >>> Also, we lay out objects in classFileParser assuming the setting of UseCompressedOops/ClassPointers and allocates space based on that. >>> >>> I don't understand the motivation of this change. It appears incorrect. >> The motivation is to enable Java code which is tightly coupled to the VM to read and possibly write such fields. Right now it is not possible. > > Which fields and why? Some sort of compiler interface is probably more appropriate where you can ask the JVM with native calls what you need to know. >>> From reading the bug, it seems that you want to get to mirror from InstanceKlass from Java. This will break when we move the mirror. >> As said above, since it's tightly coupled to the VM we will notice very soon when something changes and will change the Java code accordingly. > > I have to believe that there is a better way to do this. Actually, I have ideas how to do this that might also work for the SA. The last thing we want to see is another bunch of Java code tightly coupled with the jvm implementation in another place with another implementation. > > Coleen >> >> -- Chris >> >>> Coleen >>> >>> On 8/19/2013 5:28 PM, Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/8022853/webrev/ >>>> http://cr.openjdk.java.net/~twisti/8022853-jdk/webrev/ >>>> >>>> 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment >>>> Reviewed-by: >>>> >>>> In some native data structures of the VM oops are stored uncompressed when compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. >>>> > From christian.thalinger at oracle.com Wed Aug 21 14:22:02 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Aug 2013 14:22:02 -0700 Subject: RFR (L): 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment In-Reply-To: <521529ED.3070702@oracle.com> References: <5214FF1C.9050702@oracle.com> <521529ED.3070702@oracle.com> Message-ID: <8A1BC399-E98A-41C9-981A-3336C5B232CC@oracle.com> On Aug 21, 2013, at 1:58 PM, Coleen Phillimore wrote: > On 8/21/2013 4:27 PM, Christian Thalinger wrote: >> On Aug 21, 2013, at 10:55 AM, Coleen Phillimore wrote: >> >>> Hi, >>> >>> I've reviewed this change and I don't know how it can work. You cannot put uncompressed oops in an object when the setting is UseCompressedOops and have garbage collection work. >> This is not the main use case for these methods. Sometimes oops are not compressed even when we run with compressed oops as for the Klass::_java_mirror case. There may be other fields like this but I don't know about them. > > The other fields are subject to change also. If there is a specific use case, why not add a JVM_blah entry for that use case? Reading this code it is completely unclear that the objects passed in are actually Hotspot metadata. We don't export metadata to Java. From this code, there is no checking what this is allowed to do. It's too general purpose, when you have some specific use case in mind. Would you also say that Unsafe.getAddress is too general purpose because you can read any kind of address? One thing that you seem to forget here is that today you can write any unsafe code you want using get/put Int/Long/Address. You name it. This is no different except that these new methods are doing the right thing when you know what you are passing in, to which field in what configuration. This is the whole idea about Unsafe; you have to know what you are doing. > >> >>> Similarly you can't compress arbitrary metadata because only Klass* types can be compressed. This doesn't seem like it would work at all. >> Currently get/putMetadata only supports StorageMode.UNCOMPRESSED_KLASS and StorageMode.COMPRESSED_KLASS. We might add other storage modes in the future if we decide to compress other things. > > There is no indication of this from the code. From the code, these things are oops, when they are not? We use type checking in C++ and Java is supposed to be even safer. ?but this is unsafe :-) > >> >>> Also, we lay out objects in classFileParser assuming the setting of UseCompressedOops/ClassPointers and allocates space based on that. >>> >>> I don't understand the motivation of this change. It appears incorrect. >> The motivation is to enable Java code which is tightly coupled to the VM to read and possibly write such fields. Right now it is not possible. > > Which fields and why? Some sort of compiler interface is probably more appropriate where you can ask the JVM with native calls what you need to know. For example type checking in compiled code. You need to read Klass* references from the Class to do the type checking. The Klass* is either compressed or not. Right now there is no way to read the right value from (unsafe) Java code and we can't call out to the VM (via JNI or another C++ down call) in hot paths. >>> From reading the bug, it seems that you want to get to mirror from InstanceKlass from Java. This will break when we move the mirror. >> As said above, since it's tightly coupled to the VM we will notice very soon when something changes and will change the Java code accordingly. > > I have to believe that there is a better way to do this. Actually, I have ideas how to do this that might also work for the SA. Can you share your thoughts? -- Chris > The last thing we want to see is another bunch of Java code tightly coupled with the jvm implementation in another place with another implementation. > > Coleen >> >> -- Chris >> >>> Coleen >>> >>> On 8/19/2013 5:28 PM, Christian Thalinger wrote: >>>> http://cr.openjdk.java.net/~twisti/8022853/webrev/ >>>> http://cr.openjdk.java.net/~twisti/8022853-jdk/webrev/ >>>> >>>> 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment >>>> Reviewed-by: >>>> >>>> In some native data structures of the VM oops are stored uncompressed when compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. >>>> > From christian.thalinger at oracle.com Wed Aug 21 14:26:46 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Aug 2013 14:26:46 -0700 Subject: RFR (L): 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment In-Reply-To: <7789A2FB-3266-4CC5-976A-556733DABD82@oracle.com> References: <5214FF1C.9050702@oracle.com> <521529ED.3070702@oracle.com> <7789A2FB-3266-4CC5-976A-556733DABD82@oracle.com> Message-ID: <431D8CA3-2471-4EB7-847E-991DF58D301D@oracle.com> On Aug 21, 2013, at 2:05 PM, Karen Kinnear wrote: > I have to second what Coleen is saying. Longer term, we need to think about a compiler interface, with specific > calls for specific metadata fields, rather than reaching in directly to read and write internal vm metadata. I think this is not going to work for all cases. When it comes to compiled code you want optimal code and that does definitely not include slow calls into the VM. > This approach makes it hard to maintain without having to keep both sides in sync and "knowing" who is accessing what > metadata - in case we need to change layout, or atomicity, or make fields conditional, etc. etc. We are doing the same thing right now with all our compilers and the template interpreter. If the interpreter executes e.g. an instanceof it reads the Klass* from the oop. Thus it needs to know (a) where the field is and (b) what layout it has. > > Love to have that discussion independent of this particular unsafe extension. Sure. -- Chris > > thanks, > Karen > > > On Aug 21, 2013, at 4:58 PM, Coleen Phillimore wrote: > >> On 8/21/2013 4:27 PM, Christian Thalinger wrote: >>> On Aug 21, 2013, at 10:55 AM, Coleen Phillimore wrote: >>> >>>> Hi, >>>> >>>> I've reviewed this change and I don't know how it can work. You cannot put uncompressed oops in an object when the setting is UseCompressedOops and have garbage collection work. >>> This is not the main use case for these methods. Sometimes oops are not compressed even when we run with compressed oops as for the Klass::_java_mirror case. There may be other fields like this but I don't know about them. >> >> The other fields are subject to change also. If there is a specific use case, why not add a JVM_blah entry for that use case? Reading this code it is completely unclear that the objects passed in are actually Hotspot metadata. We don't export metadata to Java. From this code, there is no checking what this is allowed to do. It's too general purpose, when you have some specific use case in mind. >> >>> >>>> Similarly you can't compress arbitrary metadata because only Klass* types can be compressed. This doesn't seem like it would work at all. >>> Currently get/putMetadata only supports StorageMode.UNCOMPRESSED_KLASS and StorageMode.COMPRESSED_KLASS. We might add other storage modes in the future if we decide to compress other things. >> >> There is no indication of this from the code. From the code, these things are oops, when they are not? We use type checking in C++ and Java is supposed to be even safer. >> >>> >>>> Also, we lay out objects in classFileParser assuming the setting of UseCompressedOops/ClassPointers and allocates space based on that. >>>> >>>> I don't understand the motivation of this change. It appears incorrect. >>> The motivation is to enable Java code which is tightly coupled to the VM to read and possibly write such fields. Right now it is not possible. >> >> Which fields and why? Some sort of compiler interface is probably more appropriate where you can ask the JVM with native calls what you need to know. >>>> From reading the bug, it seems that you want to get to mirror from InstanceKlass from Java. This will break when we move the mirror. >>> As said above, since it's tightly coupled to the VM we will notice very soon when something changes and will change the Java code accordingly. >> >> I have to believe that there is a better way to do this. Actually, I have ideas how to do this that might also work for the SA. The last thing we want to see is another bunch of Java code tightly coupled with the jvm implementation in another place with another implementation. >> >> Coleen >>> >>> -- Chris >>> >>>> Coleen >>>> >>>> On 8/19/2013 5:28 PM, Christian Thalinger wrote: >>>>> http://cr.openjdk.java.net/~twisti/8022853/webrev/ >>>>> http://cr.openjdk.java.net/~twisti/8022853-jdk/webrev/ >>>>> >>>>> 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment >>>>> Reviewed-by: >>>>> >>>>> In some native data structures of the VM oops are stored uncompressed when compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. >>>>> >> > From vladimir.kozlov at oracle.com Wed Aug 21 15:09:53 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Aug 2013 15:09:53 -0700 Subject: JDK7 SIGSEGV with G1 garbage collector In-Reply-To: References: Message-ID: <52153AB1.2000901@oracle.com> Punya, Can I add your test to our regression tests together with the fix? http://cr.openjdk.java.net/~kvn/8023472/webrev/test/compiler/gcbarriers/G1CrashTest.java.html I added our copyright header and pointed you as author. Regards, Vladimir On 8/21/13 11:24 AM, Punya Biswal wrote: > Hi Bengt, > > Thanks for the prompt response! Please let me know if I can provide > anything else that will be useful. > > -- > Punya Biswal > Palantir | Engineer > > > On 8/21/13 6:28 AM, "Bengt Rutisson" wrote: > >> >> Hi again, >> >> This seems to be a bug in the C2 compiler. I've filed JDK-8023472 to >> track this. I'll come back with a URL once this bug is publicly available. >> >> Thanks again for the great bug report! >> Bengt >> >> On 8/21/13 8:52 AM, Bengt Rutisson wrote: >>> >>> Hi Punya, >>> >>> Thank you for the excellent bug report! >>> >>> I cloned the test case and can reproduce the issue both with 7u25 >>> build 15 (that you used) and also with the latest build of JDK8. >>> >>> I'll dig some more into what is going on and file a bug. Will ping >>> this thread when I have more information. >>> >>> Bengt >>> >>> On 8/21/13 12:05 AM, Punya Biswal wrote: >>>> [Apologies if this message is delivered twice; I sent it once before I >>>> realized this was a members-only list.] >>>> >>>> We're running into a JVM segfault when using a third-party library >>>> (Elasticsearch) alongside the G1 garbage collector. This issue has been >>>> reported elsewhere (for example, >>>> >>>> https://urldefense.proofpoint.com/v1/url?u=https://jira.terracotta.org/j >>>> ira/browse/CDV-1651&k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=kTrYN051orSRhyA6 >>>> mqYxbjRIX%2BBCPm7thmzLC79vBeM%3D%0A&m=eQXvXMfzOBqOYQJCPTAI8m0yYLgOXGzbUN >>>> Y%2FyEd6LjE%3D%0A&s=4517eb7bba43d15b07ba2a16457f9371f3d18509f2b13a22de37 >>>> 6bdb2e19e95f) and might already >>>> be on >>>> the OpenJDK roadmap. It's usually associated with the use of GNU Trove. >>>> >>>> We've been able to reduce the amount of code required to reproduce the >>>> crash to a short program that reliably crashes on my computer >>>> (a MacBook Pro) using only JDK core classes. I've also included the >>>> hs_err_* diagnostic file; both are at >>>> >>>> https://urldefense.proofpoint.com/v1/url?u=https://gist.github.com/punya >>>> /6287943&k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=kTrYN051orSRhyA6mqYxbjRIX%2 >>>> BBCPm7thmzLC79vBeM%3D%0A&m=eQXvXMfzOBqOYQJCPTAI8m0yYLgOXGzbUNY%2FyEd6LjE >>>> %3D%0A&s=1a3b70ed491698a5a44b0fc5d03329444dbe1b093056d9609cf1ff8c57deb28 >>>> 8 . >>>> >>>> Does this reduced repro help understand what's going on? >>>> >>>> >>>> A few points of interest: >>>> >>>> * running with -XX:+UseG1GC -Dcount=100000 always crashes >>>> * running with -XX:+UseG1GC -Xint -Dcount=100000 never crashes >>>> * running with -Xint -Dcount=100000 never crashes >>>> >>>> >>>> Using -ea and/or -server don't any effect these results. With regard to >>>> JVM versions, >>>> >>>> * it never crashes on JDK 6u51 >>>> * it crashes on JDK 7u25 and JDK 7u43 (prerelease) >>>> * it never crashes on JDK 8 (prerelease) >>>> >>>> >>>> I'm happy to provide a link to a core dump if that helps. >>>> >>>> -- >>>> Punya Biswal >>>> Palantir | Engineer >>>> pbiswal at palantir.com | 206 605 2397 >>> >> From pbiswal at palantir.com Wed Aug 21 15:14:42 2013 From: pbiswal at palantir.com (Punya Biswal) Date: Wed, 21 Aug 2013 22:14:42 +0000 Subject: JDK7 SIGSEGV with G1 garbage collector In-Reply-To: <52153AB1.2000901@oracle.com> References: <52153AB1.2000901@oracle.com> Message-ID: <928685E732CF824AAA16A1CB3E60A8823B0C44C3@ex02-west.YOJOE.local> Yes, absolutely. Punya Sent from a mobile device -----Original Message----- From: Vladimir Kozlov [vladimir.kozlov at oracle.com] Sent: Wednesday, August 21, 2013 03:10 PM Pacific Standard Time To: Punya Biswal Cc: hotspot-dev at openjdk.java.net Subject: Re: JDK7 SIGSEGV with G1 garbage collector Punya, Can I add your test to our regression tests together with the fix? https://urldefense.proofpoint.com/v1/url?u=http://cr.openjdk.java.net/~kvn/8023472/webrev/test/compiler/gcbarriers/G1CrashTest.java.html&k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=kTrYN051orSRhyA6mqYxbjRIX%2BBCPm7thmzLC79vBeM%3D%0A&m=UmUl4Z9msWkFMaantPvtXtR%2B4GyY78MuGH4Lp%2BQPi1k%3D%0A&s=004d6e9257aa2d0f225730fc0343a6c0eb452bee9efd44972d57fe0a74f62adc I added our copyright header and pointed you as author. Regards, Vladimir On 8/21/13 11:24 AM, Punya Biswal wrote: > Hi Bengt, > > Thanks for the prompt response! Please let me know if I can provide > anything else that will be useful. > > -- > Punya Biswal > Palantir | Engineer > > > On 8/21/13 6:28 AM, "Bengt Rutisson" wrote: > >> >> Hi again, >> >> This seems to be a bug in the C2 compiler. I've filed JDK-8023472 to >> track this. I'll come back with a URL once this bug is publicly available. >> >> Thanks again for the great bug report! >> Bengt >> >> On 8/21/13 8:52 AM, Bengt Rutisson wrote: >>> >>> Hi Punya, >>> >>> Thank you for the excellent bug report! >>> >>> I cloned the test case and can reproduce the issue both with 7u25 >>> build 15 (that you used) and also with the latest build of JDK8. >>> >>> I'll dig some more into what is going on and file a bug. Will ping >>> this thread when I have more information. >>> >>> Bengt >>> >>> On 8/21/13 12:05 AM, Punya Biswal wrote: >>>> [Apologies if this message is delivered twice; I sent it once before I >>>> realized this was a members-only list.] >>>> >>>> We're running into a JVM segfault when using a third-party library >>>> (Elasticsearch) alongside the G1 garbage collector. This issue has been >>>> reported elsewhere (for example, >>>> >>>> https://urldefense.proofpoint.com/v1/url?u=https://jira.terracotta.org/j >>>> ira/browse/CDV-1651&k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=kTrYN051orSRhyA6 >>>> mqYxbjRIX%2BBCPm7thmzLC79vBeM%3D%0A&m=eQXvXMfzOBqOYQJCPTAI8m0yYLgOXGzbUN >>>> Y%2FyEd6LjE%3D%0A&s=4517eb7bba43d15b07ba2a16457f9371f3d18509f2b13a22de37 >>>> 6bdb2e19e95f) and might already >>>> be on >>>> the OpenJDK roadmap. It's usually associated with the use of GNU Trove. >>>> >>>> We've been able to reduce the amount of code required to reproduce the >>>> crash to a short program that reliably crashes on my computer >>>> (a MacBook Pro) using only JDK core classes. I've also included the >>>> hs_err_* diagnostic file; both are at >>>> >>>> https://urldefense.proofpoint.com/v1/url?u=https://gist.github.com/punya >>>> /6287943&k=fDZpZZQMmYwf27OU23GmAQ%3D%3D%0A&r=kTrYN051orSRhyA6mqYxbjRIX%2 >>>> BBCPm7thmzLC79vBeM%3D%0A&m=eQXvXMfzOBqOYQJCPTAI8m0yYLgOXGzbUNY%2FyEd6LjE >>>> %3D%0A&s=1a3b70ed491698a5a44b0fc5d03329444dbe1b093056d9609cf1ff8c57deb28 >>>> 8 . >>>> >>>> Does this reduced repro help understand what's going on? >>>> >>>> >>>> A few points of interest: >>>> >>>> * running with -XX:+UseG1GC -Dcount=100000 always crashes >>>> * running with -XX:+UseG1GC -Xint -Dcount=100000 never crashes >>>> * running with -Xint -Dcount=100000 never crashes >>>> >>>> >>>> Using -ea and/or -server don't any effect these results. With regard to >>>> JVM versions, >>>> >>>> * it never crashes on JDK 6u51 >>>> * it crashes on JDK 7u25 and JDK 7u43 (prerelease) >>>> * it never crashes on JDK 8 (prerelease) >>>> >>>> >>>> I'm happy to provide a link to a core dump if that helps. >>>> >>>> -- >>>> Punya Biswal >>>> Palantir | Engineer >>>> pbiswal at palantir.com | 206 605 2397 >>> >> From vladimir.kozlov at oracle.com Wed Aug 21 17:50:27 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Aug 2013 17:50:27 -0700 Subject: JDK7 SIGSEGV with G1 garbage collector In-Reply-To: <928685E732CF824AAA16A1CB3E60A8823B0C44C3@ex02-west.YOJOE.local> References: <52153AB1.2000901@oracle.com> <928685E732CF824AAA16A1CB3E60A8823B0C44C3@ex02-west.YOJOE.local> Message-ID: <52156053.5050308@oracle.com> Thanks! Vladimir On 8/21/13 3:14 PM, Punya Biswal wrote: > Yes, absolutely. > > Punya > > > > Sent from a mobile device > > -----Original Message----- > *From: *Vladimir Kozlov [vladimir.kozlov at oracle.com > Punya, > > Can I add your test to our regression tests together with the fix? > > I added our copyright header and pointed you as author. > > Regards, > Vladimir From daniel.daugherty at oracle.com Wed Aug 21 19:23:21 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 22 Aug 2013 02:23:21 +0000 Subject: hg: hsx/hotspot-main/hotspot: 11 new changesets Message-ID: <20130822022344.E017C48A75@hg.openjdk.java.net> Changeset: d96f52012aaa Author: rdurbin Date: 2013-08-14 15:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d96f52012aaa 8005073: [TESTBUG] remove crufty '_g' support from HS tests Summary: remove crufty '_g' support from HS tests Reviewed-by: dcubed, sla ! test/Makefile Changeset: 740e263c80c6 Author: hseigel Date: 2013-08-15 20:04 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/740e263c80c6 8003424: Enable Class Data Sharing for CompressedOops 8016729: ObjectAlignmentInBytes=16 now forces the use of heap based compressed oops 8005933: The -Xshare:auto option is ignored for -server Summary: Move klass metaspace above the heap and support CDS with compressed klass ptrs. Reviewed-by: coleenp, kvn, mgerdin, tschatzl, stefank ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klass.inline.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java + test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java + test/runtime/CDSCompressedKPtrs/XShareAuto.java ! test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java Changeset: e5003079dfa5 Author: dcubed Date: 2013-08-16 10:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e5003079dfa5 Merge ! src/share/vm/utilities/globalDefinitions.hpp Changeset: b1fd869e7df0 Author: minqi Date: 2013-08-19 09:16 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b1fd869e7df0 8023188: Unsafe volatile double store on bsd is broken Reviewed-by: dcubed, dholmes Contributed-by: yumin.qi at oracle.com ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp Changeset: 1a8fb39bdbc4 Author: ehelin Date: 2013-08-07 16:47 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1a8fb39bdbc4 8014659: NPG: performance counters for compressed klass space Reviewed-by: mgerdin, coleenp, hseigel, jmasa, ctornqvi ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/memory/universe.cpp + test/gc/metaspace/TestMetaspacePerfCounters.java + test/testlibrary/AssertsTest.java + test/testlibrary/com/oracle/java/testlibrary/Asserts.java + test/testlibrary/com/oracle/java/testlibrary/ByteCodeLoader.java + test/testlibrary/com/oracle/java/testlibrary/InMemoryJavaCompiler.java + test/testlibrary/com/oracle/java/testlibrary/InputArguments.java + test/testlibrary/com/oracle/java/testlibrary/PerfCounter.java + test/testlibrary/com/oracle/java/testlibrary/PerfCounters.java Changeset: 878bb0b7e799 Author: ehelin Date: 2013-08-19 17:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/878bb0b7e799 Merge Changeset: 10c59b8021ec Author: kevinw Date: 2013-08-19 14:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/10c59b8021ec 8022655: ClassDump ignored jarStream setting Reviewed-by: minqi, sla ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! test/compiler/ciReplay/common.sh Changeset: 9011aa6843ce Author: kevinw Date: 2013-08-19 22:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9011aa6843ce Merge Changeset: e22ee8e7ae62 Author: jiangli Date: 2013-08-19 14:59 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e22ee8e7ae62 8021948: Change InstanceKlass::_source_file_name and _generic_signature from Symbol* to constant pool indexes. Summary: Change InstanceKlass::_source_file_name and _generic_signature to u2 fields. Reviewed-by: coleenp, iklam ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: aeebffb56606 Author: jiangli Date: 2013-08-20 00:48 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aeebffb56606 Merge Changeset: 9d6c9b0a8f15 Author: dcubed Date: 2013-08-20 13:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9d6c9b0a8f15 8023287: HOTSPOT_BUILD_COMPILER needs to support "Sun Studio 12u3" Summary: Recognize 0x5120 as "Sun Studio 12u3". Reviewed-by: dholmes, coleenp ! src/share/vm/runtime/vm_version.cpp From david.holmes at oracle.com Wed Aug 21 20:24:37 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 22 Aug 2013 13:24:37 +1000 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <5214FF94.5050007@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> <520D6EEE.1040906@oracle.com> <520DB6B7.2050901@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015CCA@DEWDFEMB12A.global.corp.sap> <520E246F.1060704@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015DAB@DEWDFEMB12A.global.corp.sap> <520EA24F.5060304@oracle.com> <52124897.7030304@oracle.com> <5213E84B.8000101@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01681B@DEWDFEMB12A.global.corp.sap> <5214FF94.5050007@oracle.com> Message-ID: <52158475.4040304@oracle.com> I'm okay with the public operator delete (whether conditional or unconditional). Though I think the use of delete in the subclass destructors needs to be looked at! Thanks, David On 22/08/2013 3:57 AM, Vladimir Kozlov wrote: > Can we add #ifdef __IBMCPP__ to your change? > > + void* operator new [](size_t size); > +// xlC can not compile this code with private operator delete() > +#ifdef __IBMCPP__ > + public: > +#endif > void operator delete(void* p); > - void* operator new [](size_t size); > > Thanks, > Vladimir > > On 8/21/13 5:35 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I don't have another workaround at hand right now. >> >> The problem is that there are public destructors in subclasses of >> StackObj which >> >> has the private delete operator. >> >> I shrinked the problem to a minimal test program and addressed the >> issue to >> >> our IBM compiler contacts. >> >> The minimal change that makes the sources compile is >> >> --- a/src/share/vm/memory/allocation.hpp Fri Jul 26 00:59:18 2013 +0200 >> >> +++ b/src/share/vm/memory/allocation.hpp Wed Aug 21 10:30:58 2013 +0200 >> >> @@ -218,7 +218,8 @@ >> >> class StackObj ALLOCATION_SUPER_CLASS_SPEC { >> >> private: >> >> void* operator new(size_t size); >> >> + void* operator new [](size_t size); >> >> + public: >> >> void operator delete(void* p); >> >> - void* operator new [](size_t size); >> >> void operator delete [](void* p); >> >> }; >> >> I.e., make only the delete operators public. VALUE_OBJ_CLASS_SPEC is >> defined empty >> >> on aix, so the fix in _ValueObj is currently not essential. >> >> I would appreciate if you can push the change with this fix, so we can >> get to the >> >> point where we can compile on aix soon. If I get a workaround like a >> pragma, >> >> I will undo this. >> >> Best regards, >> >> Goetz. >> >> // xlC 10 and 12 can not compile this program: >> >> // "test.cpp", line 12.3: 1540-0300 (S) The "private" member >> "A::operator delete(void *)" cannot be accessed. >> >> class A { >> >> private: >> >> void operator delete(void* p) {}; >> >> }; >> >> class B: public A { >> >> public: >> >> ~B() {} >> >> }; >> >> -----Original Message----- >> >> From: hotspot-dev-bounces at openjdk.java.net >> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir >> Kozlov >> >> Sent: Mittwoch, 21. August 2013 00:06 >> >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> >> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX >> >> I looked throw reviews and fount only one not answered question: >> >> On 8/15/13 5:14 PM, David Holmes wrote: >> >>>> allocation.hpp >> >>>> xlC complains: >> >>>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" >> >>>> member "StackObj::operator delete(void *)" cannot be accessed. >> >>> >> >>> Hmmm. So the whole point of these being private was so that they could >> >>> not be called but we had to override the use of the global operators. >> >>> The concrete implementations then give fatal errors if you do manage to >> >>> use them (impossible?). So making them public is undesirable. >> >>> >> >>> Is there some other way to resolve this? A pragma to tell xlC to ignore >> >>> the perceived problem? >> >> thanks, >> >> Vladimir >> >> On 8/19/13 9:32 AM, Vladimir Kozlov wrote: >> >>> I tested 8023033-aixShared-2 in JPRT (including builds and tests on ppc >> >>> + arm) and it passed without failures. >> >>> >> >>> Thanks, >> >>> Vladimir >> >>> >> >>> On 8/16/13 3:06 PM, Stefan Karlsson wrote: >> >>>> On 8/16/13 11:28 PM, Lindenmaier, Goetz wrote: >> >>>>> >> >>>>> Hi Stefan, >> >>>>> >> >>>>> the problem is that globalDefinitions defines __STDC_FORMAT_MACROS. >> >>>>> >> >>>>> inttypes.hpp comes in through jni.hpp, which is in both, jvm.hpp and >> >>>>> >> >>>>> globalDefinitions.hpp through globalDefinitions_.hpp. >> >>>>> >> >>>>> If jvm.hpp comes first, inttype.hpp is added without the macro >>>>> defined, >> >>>>> >> >>>>> and the print formats are missing. >> >>>>> >> >>>>> I could also define __STDC_FORMAT_MACROS in jni.hpp or the like. >> >>>>> >> >>>>> The name ?globalDefinitions? somehow says that the definitions should >> >>>>> be seen >> >>>>> >> >>>>> everywhere ? so it?s basically bad that the file does not end up at >> >>>>> the top of the include >> >>>>> >> >>>>> chain. Maybe I should include it in jni.hpp? or jvm.hpp? >> >>>>> >> >>>>> What do you think? >> >>>>> >> >>>> >> >>>> I see your problem. >> >>>> >> >>>> I think the most stable solution would be to add -D__STDC_FORMAT_MACROS >> >>>> to the compiler flags. >> >>>> >> >>>> But that seems out-of-scope for this change, so go ahead and use the >> >>>> reordering for now (unless someone else complains). >> >>>> >> >>>> thanks, >> >>>> StefanK >> >>>> >> >>>>> Best regards, >> >>>>> >> >>>>> Goetz. >> >>>>> >> >>>>> *From:*Stefan Karlsson [mailto:stefan.karlsson at oracle.com] >> >>>>> *Sent:* Friday, August 16, 2013 3:09 PM >> >>>>> *To:* Lindenmaier, Goetz >> >>>>> *Cc:* 'Vladimir Kozlov'; 'David Holmes'; >> >>>>> 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> >>>>> *Subject:* Re: RFR (M): 8023033: PPC64 (part 13): basic changes for >>>>> AIX >> >>>>> >> >>>>> Hi Goetz, >> >>>>> >> >>>>> On 8/16/13 2:21 PM, Lindenmaier, Goetz wrote: >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> >> >>>>> >> >>>>> - I removed the throw() >> >>>>> >> >>>>> - I removed the #ifndef in port.hpp >> >>>>> >> >>>>> - I fixed the typeo. >> >>>>> >> >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-2/ >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> I always build without precompiled headers, the nightbuild with >> >>>>> >> >>>>> them. >> >>>>> >> >>>>> >> >>>>> utilities/debug.hpp.udiff.html >> >>>>> >> >>>>> -#include "prims/jvm.h" >> >>>>> #include "utilities/globalDefinitions.hpp" >> >>>>> +#include "prims/jvm.h" >> >>>>> >> >>>>> I don't think your change to debug.hpp is the correct way to solve >> >>>>> the problems you were seeing with metaspace.hpp. Swapping the files >> >>>>> just means that someone else might hit the same problem adding >> >>>>> prims/jvm.hpp to another file. >> >>>>> >> >>>>> >> >>>>> You probably have a circular include dependency somewhere in the >> >>>>> code. Could you revert the change to utilities/debug.hpp and try to >> >>>>> figure out what the real problem is? >> >>>>> >> >>>>> thanks, >> >>>>> StefanK >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Yes, there will be makefiles for aix, and the platform files. >> >>>>> tTe prototype >> >>>>> >> >>>>> patches are here >> >>>>> >> >>>>> >> >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0014_aix_make_changes.patch >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0015_aix_ppc_files.patch >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> But the make change contains mostly new files, except for >> >>>>> >> >>>>> >> >>>>> >> >>>>> --- a/make/defs.make Tue Jul 23 21:07:11 2013 +0200 >> >>>>> >> >>>>> +++ b/make/defs.make Tue Jul 23 22:13:05 2013 +0200 >> >>>>> >> >>>>> @@ -166,11 +166,15 @@ >> >>>>> >> >>>>> HOST := $(shell uname -n) >> >>>>> >> >>>>> endif >> >>>>> >> >>>>> >> >>>>> >> >>>>> -# If not SunOS, not Linux and not BSD, assume Windows >> >>>>> >> >>>>> +# If not SunOS, not Linux not BSD and not AIX, assume Windows >> >>>>> >> >>>>> ifneq ($(OS), Linux) >> >>>>> >> >>>>> ifneq ($(OS), SunOS) >> >>>>> >> >>>>> ifneq ($(OS), bsd) >> >>>>> >> >>>>> - OSNAME=windows >> >>>>> >> >>>>> + ifneq ($(OS), AIX) >> >>>>> >> >>>>> + OSNAME=windows >> >>>>> >> >>>>> + else >> >>>>> >> >>>>> + OSNAME=aix >> >>>>> >> >>>>> + endif >> >>>>> >> >>>>> else >> >>>>> >> >>>>> OSNAME=bsd >> >>>>> >> >>>>> endif >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Best regards, >> >>>>> >> >>>>> Goetz >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -----Original Message----- >> >>>>> >> >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> >>>>> >> >>>>> Sent: Friday, August 16, 2013 7:21 AM >> >>>>> >> >>>>> To: David Holmes >> >>>>> >> >>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net >> >>>>> ';'hotspot-dev at openjdk.java.net >>>>> >> >>>>> ' >> >>>>> >> >>>>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for >> >>>>> AIX >> >>>>> >> >>>>> >> >>>>> >> >>>>> I thought trow() was added long time ago. But it was added, I >> >>>>> think by accident, very recently: >> >>>>> >> >>>>> >> >>>>> >> >>>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a7fb14888912 >> >>>>> >> >>>>> >> >>>>> >> >>>>> I missed it when I did the review of those changes. >> >>>>> >> >>>>> >> >>>>> >> >>>>> We should remove throw. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Vladimir >> >>>>> >> >>>>> >> >>>>> >> >>>>> On 8/15/13 5:14 PM, David Holmes wrote: >> >>>>> >> >>>>> On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: >> >>>>> >> >>>>> On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: >> >>>>> >> >>>>> Hi Vladimir, >> >>>>> >> >>>>> >> >>>>> >> >>>>> throw is needed because it`s there in the >> >>>>> implementation in nmethod.cpp. >> >>>>> >> >>>>> (So you are using it a bit at least :)) >> >>>>> >> >>>>> xlc says >> >>>>> >> >>>>> "nmethod.cpp", line 802.7: 1540-0400 (S) >> >>>>> "nmethod::operator >> >>>>> >> >>>>> new(size_t, int)" has a conflicting declaration. >> >>>>> >> >>>>> "nmethod.hpp", line 268.9: 1540-0424 (I) "operator >> >>>>> new" is declared on >> >>>>> >> >>>>> line 268 of "nmethod.hpp". >> >>>>> >> >>>>> >> >>>>> >> >>>>> Okay, it is just declaration. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Why do we have throw here: >> >>>>> >> >>>>> >> >>>>> >> >>>>> void* nmethod::operator new(size_t size, int nmethod_size) >> >>>>> throw () { >> >>>>> >> >>>>> // Not critical, may return null if there is too little >> >>>>> continuous memory >> >>>>> >> >>>>> return CodeCache::allocate(nmethod_size); >> >>>>> >> >>>>> } >> >>>>> >> >>>>> >> >>>>> >> >>>>> Seems to me it should be removed if anything. >> >>>>> >> >>>>> >> >>>>> >> >>>>> David >> >>>>> >> >>>>> ----- >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> int64 is defined correctly, uint64 is not defined, >> >>>>> but never used in >> >>>>> >> >>>>> hotspot. >> >>>>> >> >>>>> I can not reproduce an error, but that's rather old >> >>>>> coding from our VM. >> >>>>> >> >>>>> We also switched from xlc8 to xlc10 in the course of >> >>>>> this project. >> >>>>> >> >>>>> I will test some more and talk to the person who >> >>>>> implemented that >> >>>>> >> >>>>> tomorrow, >> >>>>> >> >>>>> and if possible remove the change. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Okay, I will test it also. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Vladimir >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Best regards & thanks for the review, >> >>>>> >> >>>>> Goetz. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -----Original Message----- >> >>>>> >> >>>>> From: Vladimir Kozlov >> >>>>> [mailto:vladimir.kozlov at oracle.com] >> >>>>> >> >>>>> Sent: Thursday, August 15, 2013 5:52 PM >> >>>>> >> >>>>> To: Lindenmaier, Goetz >> >>>>> >> >>>>> Cc: 'hotspot-dev at openjdk.java.net >> >>>>> ';ppc-aix-port-dev at openjdk.java.net >>>>> >> >>>>> ; >> >> >>> >> >> >>> Albert Noll (albert.noll at oracle.com >> >> >>> ) >> >>>>> >> >>>>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic >> >>>>> changes for AIX >> >>>>> >> >>>>> >> >>>>> >> >>>>> Goetz, >> >>>>> >> >>>>> >> >>>>> >> >>>>> I only see 2 problems which you did not explain: >> >>>>> >> >>>>> >> >>>>> >> >>>>> nmethod.hpp. Why the next change? we don't use C++ >> >>>>> exceptions: >> >>>>> >> >>>>> >> >>>>> >> >>>>> - void* operator new(size_t size, int nmethod_size); >> >>>>> >> >>>>> + void* operator new(size_t size, int nmethod_size) >> >>>>> throw (); >> >>>>> >> >>>>> >> >>>>> >> >>>>> port.hpp. Did AIX has the same definitions for jlong >> >>>>> and julong?: >> >>>>> >> >>>>> >> >>>>> >> >>>>> +#ifndef _AIX >> >>>>> >> >>>>> +// These conflict with /usr/include/sys/inttypes.h >> >>>>> on aix. >> >>>>> >> >>>>> typedef jlong int64; // Java long for >> >>>>> my 64-bit type >> >>>>> >> >>>>> typedef julong uint64; // Java long for >> >>>>> my 64-bit type >> >>>>> >> >>>>> +#endif >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> And of cause we need to test these changes with >> >>>>> compilers we use. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Thanks, >> >>>>> >> >>>>> Vladimir >> >>>>> >> >> >>> >> >> >>> >> >> >>> On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> >> >>>>> >> >>>>> I prepared a webrev for >> >>>>> >> >>>>> 8023033: PPC64 (part 13): basic changes for AIX >> >>>>> >> >>>>> >> >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> This contains the basic shared changes needed for >> >>>>> the AIX port, >> >>>>> >> >>>>> as there are >> >>>>> >> >>>>> - #includes >> >>>>> >> >>>>> - Fixes to get the code compiling with xlC/on AIX >> >>>>> >> >>>>> - Basic adaptions as in vm_version.cpp. >> >>>>> >> >>>>> >> >>>>> >> >>>>> It also determines the placement and naming of >> >>>>> the aix files, >> >>>>> >> >>>>> which will go to os/aix and os_cpu/aix_ppc, as >> >>>>> you can see in >> >>>>> >> >>>>> >> >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Some details about the compilation problems: >> >>>>> >> >>>>> >> >>>>> >> >>>>> relocInfo.hpp: >> >>>>> >> >>>>> xlC wants initialization in inline implementation. >> >>>>> >> >>>>> >> >>>>> >> >>>>> vmreg.hpp: >> >>>>> >> >>>>> BAD is defined in AIX system header sys/param.h. >> >>>>> Renamed. >> >>>>> >> >>>>> >> >>>>> >> >>>>> allocation.hpp >> >>>>> >> >>>>> xlC complains: >> >>>>> >> >>>>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 >> >>>>> (S) The "private" >> >>>>> >> >>>>> member "StackObj::operator delete(void *)" cannot >> >>>>> be accessed. >> >>>>> >> >>>>> >> >>>>> >> >>>>> sharedRuntimeTrig.cpp >> >>>>> >> >>>>> Aix defines hz to be 100, see sys/m_param.h. >> >>>>> Renamed. >> >>>>> >> >>>>> >> >>>>> >> >>>>> debug.hpp >> >>>>> >> >>>>> With other include order we get a lot of >> >>>>> >> >>>>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) >> >>>>> "PRIuPTR" is not >> >>>>> >> >>>>> declared. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Please review and test this change. Comments are >> >>>>> welcome. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Thanks and best regards, >> >> >>> >> >> >>> Goetz. >> >> >>> >> >> >>> >> >> >>> >> >> >> >> From peter.allwin at oracle.com Thu Aug 22 02:34:28 2013 From: peter.allwin at oracle.com (Peter Allwin) Date: Thu, 22 Aug 2013 11:34:28 +0200 Subject: RFR: 8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__" In-Reply-To: References: <3476F401-E6AF-44C3-871E-62F2681DC8D9@oracle.com> <5208FA82.5090509@oracle.com> Message-ID: <62A30946-19C0-4B9D-9CDC-9E9EB2E2B77C@oracle.com> Hi Kris, Thanks for the reminder, I added Yunda as a contributor. Thanks everyone for your reviews! Regards, /peter On Aug 12, 2013, at 6:03 PM, Krystal Mok wrote: > Hi Peter, > > Looks good to me. Thank you! > I'd like to mention again that the getHandle -> getAddress change has been purposed by Yunda, which I mentioned in [1], too. > > Best regards, > Kris (kmo) > > On Monday, August 12, 2013, A. Sundararajan wrote: > > Looks good > > -Sundar > > On Monday 12 August 2013 06:21 PM, Peter Allwin wrote: >> Hello! >> >> This patch addresses several Nashorn compatibility issues with in sa.js and is a merge of my patch [0] and Kris' (kmo) [1] which were developed separately. >> >> The merged change is identical to [1] with except for line 785 where I've added a conversion to JavaScript String to ensure the correct replace method is called. >> >> >> webrev: http://cr.openjdk.java.net/~allwin/8011888/webrev.01/ >> bug: http://bugs.sun.com/view_bug.do?bug_id=8011888 >> >> >> Thanks! >> /Peter >> >> >> [0] http://cr.openjdk.java.net/~allwin/8011888/webrev.00/ >> [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-July/010831.html >> > From stefan.karlsson at oracle.com Thu Aug 22 04:22:46 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 22 Aug 2013 13:22:46 +0200 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: <51D3065C.6090401@oracle.com> References: <51D3065C.6090401@oracle.com> Message-ID: <5215F486.6050105@oracle.com> http://cr.openjdk.java.net/~stefank/8007074/webrev.01/ Hi all, The original patch didn't make it in time for the hs24 release. So, please review this patch that's now based on hs25 (JDK8) instead of hs24. The main difference between the two patches is the heap setup code, which is different because of the permgen removal. thanks, StefanK On 07/02/2013 06:57 PM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8007074/webrev.00/ > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007074 > > The default way of using Large Pages in HotSpot on Linux > (UseHugeTLBFS) is broken. This is causing a number of crashes in > different subsystems of the JVM. > > > Bug Description > =============== > > The main reason for this bug is that mmap(addr, size, ... > MAP_FIXED|MAP_HUGETLB ...) will remove the previous mapping at [addr, > addr+size) when we run out of large pages on Linux. > > This affects different parts of the JVM, but the most obvious is the > allocation of the Java heap: > > When the JVM starts it reserves a memory area for the entire Java > heap. We use mmap(...MAP_NORESERVE...) to reserve a contiguous chunk > of memory that no other > subsystem of the JVM, or Java program, will be allowed to mmap into. > > The reservation of the memory only reflects the maximum possible heap > size, but often a smaller heap size is used if the memory pressure is > low. The part of > the heap that is actually used is committed with > mmap(...MAP_FIXED...). When the heap is growing we commit a > consecutive chunk of memory after the > previously committed memory. We rely on the fact that no other thread > will mmap into the reserved memory area for the Java heap. > > The actual committing of the memory is done by first trying to > allocate large pages with mmap(...MAP_FIXED|MAP_HUGETLB...), and if > that fails we call mmap with the same parameters but without the large > pages flag (MAP_HUGETLB). > > Just after we have failed to mmap large pages and before the small > pages have been mmapped, there's an unmapped memory region in the > middle of the Java heap, where other threads might mmap into. When > that happens we get memory trashing and crashes. > > > Large Pages in HotSpot - on Linux > ================================= > > Currently, before the bug fix, HotSpot supports three ways of > allocating large pages on Linux. > 1) -XX:+UseSHM - Commits the large pages upfront when the memory is > reserved. > > 2) -XX:+UseHugeTLBFS - This is the broken implementation. It's also > the default way large pages are allocated. If the OS is correctly > configured, we get these kind of large pages for three different reasons: > 2.1) The user has not specified any large pages flags > 2.2) The user has specified -XX:+UseLargePages > 2.3) The user has specified -XX:+UseHugeTLBFS > > 3) Transparent Huge Pages - is supported on recent Linux Kernels. The > user can choose to configure the OS to: > 3.1) completely handle the allocation of large pages, or > 3.2) let the JVM advise where it would be good to allocate large > pages. There exist code for this today, that is guarded by the (2) > -XX:+UseHugeTLBFS flag. > > > The Proposed Patch > ================== > > 4) Create a new flag -XX:+UseTransparentHugePages, and move the > transparent huge pages advise in (3.2) out from the (2) > -XX:+UseHugeTLBFS code. > > 5) Make -XX:+UseTransparentHugePages the default way to allocate large > pages if the OS supports them. It will be the only kind of large pages > we'll use if the user has not specified any large pages flags. > > 6) Change the order of how we choose the kind of large pages when > -XX:+UseLargePages has been specified. It used to be UseHugeTLBFS then > UseSHM, now it's UseTransparentHugePages, then UseHugeTLBFS, then UseSHM. > > 7) Implement a workaround fix for the (2) -XX:+UseHugeTLBFS > implementation. With the fix the large pages are committed upfront > when they are reserved. It's mostly the same way we do it for the > older (1) -XX:+UseSHM large pages. This change will fix the bug, but > has a couple of drawbacks: > 7.1) We have to allocate the entire large pages memory area when it is > reserved instead of when parts of it are committed. > 7.2) We can't dynamically shrink or grow the used memory in the large > pages areas. > If these restrictions are not suitable for the user, then (3) > -XX:+UseTransparentHugePages could be used instead. > > 8) Ignore -XX:LargePageSizeInBytes on Linux since the OS doesn't > support multiple large page sizes and both the old code and new code > is broken if the user is allowed to set it to some other value then > the OS chosen value. Warn if the user specifies a value different than > the OS default value. > > > Testing > ======= > > New unit tests have been added. These can be run in a non-product > build with: > java -XX:+ExecuteInternalVMTests -XX:+VerboseInternalVMTests pages flags> -version > > unit tests: with and without large pages on Linux, Windows, Solaris, > x86, x64, sparcv9. > jprt: default > jprt: -XX:+UseLargePages > jprt: -XX:+UseLargePages -XX:-UseCompressedOops > vm.quick.testlist, vm.pcl.testlist, vm.gc.testlist: multiple > platforms, with large pages on all major GCs with and without > compressed oops. > SPECjbb2005 performance runs: on Linux x64 with -XX:+UseHugeTLBFS > before and after the patch. > Kitchensink: 3 days on Linux x64 > > > thanks, > StefanK From david.holmes at oracle.com Thu Aug 22 04:39:53 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 22 Aug 2013 21:39:53 +1000 Subject: RFR (L): 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment In-Reply-To: <431D8CA3-2471-4EB7-847E-991DF58D301D@oracle.com> References: <5214FF1C.9050702@oracle.com> <521529ED.3070702@oracle.com> <7789A2FB-3266-4CC5-976A-556733DABD82@oracle.com> <431D8CA3-2471-4EB7-847E-991DF58D301D@oracle.com> Message-ID: <5215F889.80905@oracle.com> I'll ask the stoopid question: how/why is "java code" reading a Klass* ??? David On 22/08/2013 7:26 AM, Christian Thalinger wrote: > > On Aug 21, 2013, at 2:05 PM, Karen Kinnear wrote: > >> I have to second what Coleen is saying. Longer term, we need to think about a compiler interface, with specific >> calls for specific metadata fields, rather than reaching in directly to read and write internal vm metadata. > > I think this is not going to work for all cases. When it comes to compiled code you want optimal code and that does definitely not include slow calls into the VM. > >> This approach makes it hard to maintain without having to keep both sides in sync and "knowing" who is accessing what >> metadata - in case we need to change layout, or atomicity, or make fields conditional, etc. etc. > > We are doing the same thing right now with all our compilers and the template interpreter. If the interpreter executes e.g. an instanceof it reads the Klass* from the oop. Thus it needs to know (a) where the field is and (b) what layout it has. > >> >> Love to have that discussion independent of this particular unsafe extension. > > Sure. > > -- Chris > >> >> thanks, >> Karen >> >> >> On Aug 21, 2013, at 4:58 PM, Coleen Phillimore wrote: >> >>> On 8/21/2013 4:27 PM, Christian Thalinger wrote: >>>> On Aug 21, 2013, at 10:55 AM, Coleen Phillimore wrote: >>>> >>>>> Hi, >>>>> >>>>> I've reviewed this change and I don't know how it can work. You cannot put uncompressed oops in an object when the setting is UseCompressedOops and have garbage collection work. >>>> This is not the main use case for these methods. Sometimes oops are not compressed even when we run with compressed oops as for the Klass::_java_mirror case. There may be other fields like this but I don't know about them. >>> >>> The other fields are subject to change also. If there is a specific use case, why not add a JVM_blah entry for that use case? Reading this code it is completely unclear that the objects passed in are actually Hotspot metadata. We don't export metadata to Java. From this code, there is no checking what this is allowed to do. It's too general purpose, when you have some specific use case in mind. >>> >>>> >>>>> Similarly you can't compress arbitrary metadata because only Klass* types can be compressed. This doesn't seem like it would work at all. >>>> Currently get/putMetadata only supports StorageMode.UNCOMPRESSED_KLASS and StorageMode.COMPRESSED_KLASS. We might add other storage modes in the future if we decide to compress other things. >>> >>> There is no indication of this from the code. From the code, these things are oops, when they are not? We use type checking in C++ and Java is supposed to be even safer. >>> >>>> >>>>> Also, we lay out objects in classFileParser assuming the setting of UseCompressedOops/ClassPointers and allocates space based on that. >>>>> >>>>> I don't understand the motivation of this change. It appears incorrect. >>>> The motivation is to enable Java code which is tightly coupled to the VM to read and possibly write such fields. Right now it is not possible. >>> >>> Which fields and why? Some sort of compiler interface is probably more appropriate where you can ask the JVM with native calls what you need to know. >>>>> From reading the bug, it seems that you want to get to mirror from InstanceKlass from Java. This will break when we move the mirror. >>>> As said above, since it's tightly coupled to the VM we will notice very soon when something changes and will change the Java code accordingly. >>> >>> I have to believe that there is a better way to do this. Actually, I have ideas how to do this that might also work for the SA. The last thing we want to see is another bunch of Java code tightly coupled with the jvm implementation in another place with another implementation. >>> >>> Coleen >>>> >>>> -- Chris >>>> >>>>> Coleen >>>>> >>>>> On 8/19/2013 5:28 PM, Christian Thalinger wrote: >>>>>> http://cr.openjdk.java.net/~twisti/8022853/webrev/ >>>>>> http://cr.openjdk.java.net/~twisti/8022853-jdk/webrev/ >>>>>> >>>>>> 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment >>>>>> Reviewed-by: >>>>>> >>>>>> In some native data structures of the VM oops are stored uncompressed when compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. >>>>>> >>> >> > From goetz.lindenmaier at sap.com Thu Aug 22 05:57:06 2013 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 22 Aug 2013 12:57:06 +0000 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <5214FF94.5050007@oracle.com> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> <520D6EEE.1040906@oracle.com> <520DB6B7.2050901@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015CCA@DEWDFEMB12A.global.corp.sap> <520E246F.1060704@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015DAB@DEWDFEMB12A.global.corp.sap> <520EA24F.5060304@oracle.com> <52124897.7030304@oracle.com> <5213E84B.8000101@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01681B@DEWDFEMB12A.global.corp.sap> <5214FF94.5050007@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC0D016CCA@DEWDFEMB12A.global.corp.sap> Hi Vladimir, David, I added the #define __IBMCPP__ and reordered the news and deletes. I also added a '=' we missed in 12 in os_posix.cpp. I hope it's ok to do this in this change. http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-3/ Best regards Goetz. -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Mittwoch, 21. August 2013 19:58 Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX Can we add #ifdef __IBMCPP__ to your change? + void* operator new [](size_t size); +// xlC can not compile this code with private operator delete() +#ifdef __IBMCPP__ + public: +#endif void operator delete(void* p); - void* operator new [](size_t size); Thanks, Vladimir On 8/21/13 5:35 AM, Lindenmaier, Goetz wrote: > Hi, > > I don't have another workaround at hand right now. > > The problem is that there are public destructors in subclasses of > StackObj which > > has the private delete operator. > > I shrinked the problem to a minimal test program and addressed the issue to > > our IBM compiler contacts. > > The minimal change that makes the sources compile is > > --- a/src/share/vm/memory/allocation.hpp Fri Jul 26 00:59:18 2013 +0200 > > +++ b/src/share/vm/memory/allocation.hpp Wed Aug 21 10:30:58 2013 +0200 > > @@ -218,7 +218,8 @@ > > class StackObj ALLOCATION_SUPER_CLASS_SPEC { > > private: > > void* operator new(size_t size); > > + void* operator new [](size_t size); > > + public: > > void operator delete(void* p); > > - void* operator new [](size_t size); > > void operator delete [](void* p); > > }; > > I.e., make only the delete operators public. VALUE_OBJ_CLASS_SPEC is > defined empty > > on aix, so the fix in _ValueObj is currently not essential. > > I would appreciate if you can push the change with this fix, so we can > get to the > > point where we can compile on aix soon. If I get a workaround like a > pragma, > > I will undo this. > > Best regards, > > Goetz. > > // xlC 10 and 12 can not compile this program: > > // "test.cpp", line 12.3: 1540-0300 (S) The "private" member > "A::operator delete(void *)" cannot be accessed. > > class A { > > private: > > void operator delete(void* p) {}; > > }; > > class B: public A { > > public: > > ~B() {} > > }; > > -----Original Message----- > > From: hotspot-dev-bounces at openjdk.java.net > [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > > Sent: Mittwoch, 21. August 2013 00:06 > > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > > Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX > > I looked throw reviews and fount only one not answered question: > > On 8/15/13 5:14 PM, David Holmes wrote: > >>> allocation.hpp > >>> xlC complains: > >>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" > >>> member "StackObj::operator delete(void *)" cannot be accessed. > >> > >> Hmmm. So the whole point of these being private was so that they could > >> not be called but we had to override the use of the global operators. > >> The concrete implementations then give fatal errors if you do manage to > >> use them (impossible?). So making them public is undesirable. > >> > >> Is there some other way to resolve this? A pragma to tell xlC to ignore > >> the perceived problem? > > thanks, > > Vladimir > > On 8/19/13 9:32 AM, Vladimir Kozlov wrote: > >> I tested 8023033-aixShared-2 in JPRT (including builds and tests on ppc > >> + arm) and it passed without failures. > >> > >> Thanks, > >> Vladimir > >> > >> On 8/16/13 3:06 PM, Stefan Karlsson wrote: > >>> On 8/16/13 11:28 PM, Lindenmaier, Goetz wrote: > >>>> > >>>> Hi Stefan, > >>>> > >>>> the problem is that globalDefinitions defines __STDC_FORMAT_MACROS. > >>>> > >>>> inttypes.hpp comes in through jni.hpp, which is in both, jvm.hpp and > >>>> > >>>> globalDefinitions.hpp through globalDefinitions_.hpp. > >>>> > >>>> If jvm.hpp comes first, inttype.hpp is added without the macro defined, > >>>> > >>>> and the print formats are missing. > >>>> > >>>> I could also define __STDC_FORMAT_MACROS in jni.hpp or the like. > >>>> > >>>> The name "globalDefinitions" somehow says that the definitions should > >>>> be seen > >>>> > >>>> everywhere ... so it's basically bad that the file does not end up at > >>>> the top of the include > >>>> > >>>> chain. Maybe I should include it in jni.hpp? or jvm.hpp? > >>>> > >>>> What do you think? > >>>> > >>> > >>> I see your problem. > >>> > >>> I think the most stable solution would be to add -D__STDC_FORMAT_MACROS > >>> to the compiler flags. > >>> > >>> But that seems out-of-scope for this change, so go ahead and use the > >>> reordering for now (unless someone else complains). > >>> > >>> thanks, > >>> StefanK > >>> > >>>> Best regards, > >>>> > >>>> Goetz. > >>>> > >>>> *From:*Stefan Karlsson [mailto:stefan.karlsson at oracle.com] > >>>> *Sent:* Friday, August 16, 2013 3:09 PM > >>>> *To:* Lindenmaier, Goetz > >>>> *Cc:* 'Vladimir Kozlov'; 'David Holmes'; > >>>> 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > >>>> *Subject:* Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX > >>>> > >>>> Hi Goetz, > >>>> > >>>> On 8/16/13 2:21 PM, Lindenmaier, Goetz wrote: > >>>> > >>>> Hi, > >>>> > >>>> > >>>> > >>>> - I removed the throw() > >>>> > >>>> - I removed the #ifndef in port.hpp > >>>> > >>>> - I fixed the typeo. > >>>> > >>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-2/ > >>>> > >>>> > >>>> > >>>> > >>>> I always build without precompiled headers, the nightbuild with > >>>> > >>>> them. > >>>> > >>>> > >>>> utilities/debug.hpp.udiff.html > >>>> > >>>> -#include "prims/jvm.h" > >>>> #include "utilities/globalDefinitions.hpp" > >>>> +#include "prims/jvm.h" > >>>> > >>>> I don't think your change to debug.hpp is the correct way to solve > >>>> the problems you were seeing with metaspace.hpp. Swapping the files > >>>> just means that someone else might hit the same problem adding > >>>> prims/jvm.hpp to another file. > >>>> > >>>> > >>>> You probably have a circular include dependency somewhere in the > >>>> code. Could you revert the change to utilities/debug.hpp and try to > >>>> figure out what the real problem is? > >>>> > >>>> thanks, > >>>> StefanK > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Yes, there will be makefiles for aix, and the platform files. > >>>> tTe prototype > >>>> > >>>> patches are here > >>>> > >>>> > >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0014_aix_make_changes.patch > >>>> > >>>> > >>>> > >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0015_aix_ppc_files.patch > >>>> > >>>> > >>>> > >>>> > >>>> But the make change contains mostly new files, except for > >>>> > >>>> > >>>> > >>>> --- a/make/defs.make Tue Jul 23 21:07:11 2013 +0200 > >>>> > >>>> +++ b/make/defs.make Tue Jul 23 22:13:05 2013 +0200 > >>>> > >>>> @@ -166,11 +166,15 @@ > >>>> > >>>> HOST := $(shell uname -n) > >>>> > >>>> endif > >>>> > >>>> > >>>> > >>>> -# If not SunOS, not Linux and not BSD, assume Windows > >>>> > >>>> +# If not SunOS, not Linux not BSD and not AIX, assume Windows > >>>> > >>>> ifneq ($(OS), Linux) > >>>> > >>>> ifneq ($(OS), SunOS) > >>>> > >>>> ifneq ($(OS), bsd) > >>>> > >>>> - OSNAME=windows > >>>> > >>>> + ifneq ($(OS), AIX) > >>>> > >>>> + OSNAME=windows > >>>> > >>>> + else > >>>> > >>>> + OSNAME=aix > >>>> > >>>> + endif > >>>> > >>>> else > >>>> > >>>> OSNAME=bsd > >>>> > >>>> endif > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Best regards, > >>>> > >>>> Goetz > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> > >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > >>>> > >>>> Sent: Friday, August 16, 2013 7:21 AM > >>>> > >>>> To: David Holmes > >>>> > >>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net > >>>> ';'hotspot-dev at openjdk.java.net > >>>> ' > >>>> > >>>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for > >>>> AIX > >>>> > >>>> > >>>> > >>>> I thought trow() was added long time ago. But it was added, I > >>>> think by accident, very recently: > >>>> > >>>> > >>>> > >>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a7fb14888912 > >>>> > >>>> > >>>> > >>>> I missed it when I did the review of those changes. > >>>> > >>>> > >>>> > >>>> We should remove throw. > >>>> > >>>> > >>>> > >>>> Vladimir > >>>> > >>>> > >>>> > >>>> On 8/15/13 5:14 PM, David Holmes wrote: > >>>> > >>>> On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: > >>>> > >>>> On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: > >>>> > >>>> Hi Vladimir, > >>>> > >>>> > >>>> > >>>> throw is needed because it`s there in the > >>>> implementation in nmethod.cpp. > >>>> > >>>> (So you are using it a bit at least :)) > >>>> > >>>> xlc says > >>>> > >>>> "nmethod.cpp", line 802.7: 1540-0400 (S) > >>>> "nmethod::operator > >>>> > >>>> new(size_t, int)" has a conflicting declaration. > >>>> > >>>> "nmethod.hpp", line 268.9: 1540-0424 (I) "operator > >>>> new" is declared on > >>>> > >>>> line 268 of "nmethod.hpp". > >>>> > >>>> > >>>> > >>>> Okay, it is just declaration. > >>>> > >>>> > >>>> > >>>> Why do we have throw here: > >>>> > >>>> > >>>> > >>>> void* nmethod::operator new(size_t size, int nmethod_size) > >>>> throw () { > >>>> > >>>> // Not critical, may return null if there is too little > >>>> continuous memory > >>>> > >>>> return CodeCache::allocate(nmethod_size); > >>>> > >>>> } > >>>> > >>>> > >>>> > >>>> Seems to me it should be removed if anything. > >>>> > >>>> > >>>> > >>>> David > >>>> > >>>> ----- > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> int64 is defined correctly, uint64 is not defined, > >>>> but never used in > >>>> > >>>> hotspot. > >>>> > >>>> I can not reproduce an error, but that's rather old > >>>> coding from our VM. > >>>> > >>>> We also switched from xlc8 to xlc10 in the course of > >>>> this project. > >>>> > >>>> I will test some more and talk to the person who > >>>> implemented that > >>>> > >>>> tomorrow, > >>>> > >>>> and if possible remove the change. > >>>> > >>>> > >>>> > >>>> Okay, I will test it also. > >>>> > >>>> > >>>> > >>>> Vladimir > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Best regards & thanks for the review, > >>>> > >>>> Goetz. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> > >>>> From: Vladimir Kozlov > >>>> [mailto:vladimir.kozlov at oracle.com] > >>>> > >>>> Sent: Thursday, August 15, 2013 5:52 PM > >>>> > >>>> To: Lindenmaier, Goetz > >>>> > >>>> Cc: 'hotspot-dev at openjdk.java.net > >>>> ';ppc-aix-port-dev at openjdk.java.net > >>>> ; > > >>> > > >>> Albert Noll (albert.noll at oracle.com > > >>> ) > >>>> > >>>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic > >>>> changes for AIX > >>>> > >>>> > >>>> > >>>> Goetz, > >>>> > >>>> > >>>> > >>>> I only see 2 problems which you did not explain: > >>>> > >>>> > >>>> > >>>> nmethod.hpp. Why the next change? we don't use C++ > >>>> exceptions: > >>>> > >>>> > >>>> > >>>> - void* operator new(size_t size, int nmethod_size); > >>>> > >>>> + void* operator new(size_t size, int nmethod_size) > >>>> throw (); > >>>> > >>>> > >>>> > >>>> port.hpp. Did AIX has the same definitions for jlong > >>>> and julong?: > >>>> > >>>> > >>>> > >>>> +#ifndef _AIX > >>>> > >>>> +// These conflict with /usr/include/sys/inttypes.h > >>>> on aix. > >>>> > >>>> typedef jlong int64; // Java long for > >>>> my 64-bit type > >>>> > >>>> typedef julong uint64; // Java long for > >>>> my 64-bit type > >>>> > >>>> +#endif > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> And of cause we need to test these changes with > >>>> compilers we use. > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Vladimir > >>>> > > >>> > > >>> > > >>> On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: > >>>> > >>>> Hi, > >>>> > >>>> > >>>> > >>>> I prepared a webrev for > >>>> > >>>> 8023033: PPC64 (part 13): basic changes for AIX > >>>> > >>>> > >>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ > >>>> > >>>> > >>>> > >>>> > >>>> This contains the basic shared changes needed for > >>>> the AIX port, > >>>> > >>>> as there are > >>>> > >>>> - #includes > >>>> > >>>> - Fixes to get the code compiling with xlC/on AIX > >>>> > >>>> - Basic adaptions as in vm_version.cpp. > >>>> > >>>> > >>>> > >>>> It also determines the placement and naming of > >>>> the aix files, > >>>> > >>>> which will go to os/aix and os_cpu/aix_ppc, as > >>>> you can see in > >>>> > >>>> > >>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Some details about the compilation problems: > >>>> > >>>> > >>>> > >>>> relocInfo.hpp: > >>>> > >>>> xlC wants initialization in inline implementation. > >>>> > >>>> > >>>> > >>>> vmreg.hpp: > >>>> > >>>> BAD is defined in AIX system header sys/param.h. > >>>> Renamed. > >>>> > >>>> > >>>> > >>>> allocation.hpp > >>>> > >>>> xlC complains: > >>>> > >>>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 > >>>> (S) The "private" > >>>> > >>>> member "StackObj::operator delete(void *)" cannot > >>>> be accessed. > >>>> > >>>> > >>>> > >>>> sharedRuntimeTrig.cpp > >>>> > >>>> Aix defines hz to be 100, see sys/m_param.h. > >>>> Renamed. > >>>> > >>>> > >>>> > >>>> debug.hpp > >>>> > >>>> With other include order we get a lot of > >>>> > >>>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) > >>>> "PRIuPTR" is not > >>>> > >>>> declared. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> Please review and test this change. Comments are > >>>> welcome. > >>>> > >>>> > >>>> > >>>> Thanks and best regards, > > >>> > > >>> Goetz. > > >>> > > >>> > > >>> > > >> > From vladimir.kozlov at oracle.com Thu Aug 22 09:47:37 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 22 Aug 2013 09:47:37 -0700 Subject: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX In-Reply-To: <4295855A5C1DE049A61835A1887419CC0D016CCA@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC0D013171@DEWDFEMB12A.global.corp.sap> <520CF907.3040908@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01433D@DEWDFEMB12A.global.corp.sap> <520D4E04.3010709@oracle.com> <520D6EEE.1040906@oracle.com> <520DB6B7.2050901@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015CCA@DEWDFEMB12A.global.corp.sap> <520E246F.1060704@oracle.com> <4295855A5C1DE049A61835A1887419CC0D015DAB@DEWDFEMB12A.global.corp.sap> <520EA24F.5060304@oracle.com> <52124897.7030304@oracle.com> <5213E84B.8000101@oracle.com> <4295855A5C1DE049A61835A1887419CC0D01681B@DEWDFEMB12A.global.corp.sap> <5214FF94.5050007@oracle.com> <4295855A5C1DE049A61835A1887419CC0D016CCA@DEWDFEMB12A.global.corp.sap> Message-ID: <521640A9.1030409@oracle.com> Thank you, Goetz The job in JPRT. Vladimir On 8/22/13 5:57 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, David, > > I added the #define __IBMCPP__ and reordered the news and deletes. > > I also added a '=' we missed in 12 in os_posix.cpp. > I hope it's ok to do this in this change. > http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-3/ > > Best regards > Goetz. > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Mittwoch, 21. August 2013 19:58 > Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX > > Can we add #ifdef __IBMCPP__ to your change? > > + void* operator new [](size_t size); > +// xlC can not compile this code with private operator delete() > +#ifdef __IBMCPP__ > + public: > +#endif > void operator delete(void* p); > - void* operator new [](size_t size); > > Thanks, > Vladimir > > On 8/21/13 5:35 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> I don't have another workaround at hand right now. >> >> The problem is that there are public destructors in subclasses of >> StackObj which >> >> has the private delete operator. >> >> I shrinked the problem to a minimal test program and addressed the issue to >> >> our IBM compiler contacts. >> >> The minimal change that makes the sources compile is >> >> --- a/src/share/vm/memory/allocation.hpp Fri Jul 26 00:59:18 2013 +0200 >> >> +++ b/src/share/vm/memory/allocation.hpp Wed Aug 21 10:30:58 2013 +0200 >> >> @@ -218,7 +218,8 @@ >> >> class StackObj ALLOCATION_SUPER_CLASS_SPEC { >> >> private: >> >> void* operator new(size_t size); >> >> + void* operator new [](size_t size); >> >> + public: >> >> void operator delete(void* p); >> >> - void* operator new [](size_t size); >> >> void operator delete [](void* p); >> >> }; >> >> I.e., make only the delete operators public. VALUE_OBJ_CLASS_SPEC is >> defined empty >> >> on aix, so the fix in _ValueObj is currently not essential. >> >> I would appreciate if you can push the change with this fix, so we can >> get to the >> >> point where we can compile on aix soon. If I get a workaround like a >> pragma, >> >> I will undo this. >> >> Best regards, >> >> Goetz. >> >> // xlC 10 and 12 can not compile this program: >> >> // "test.cpp", line 12.3: 1540-0300 (S) The "private" member >> "A::operator delete(void *)" cannot be accessed. >> >> class A { >> >> private: >> >> void operator delete(void* p) {}; >> >> }; >> >> class B: public A { >> >> public: >> >> ~B() {} >> >> }; >> >> -----Original Message----- >> >> From: hotspot-dev-bounces at openjdk.java.net >> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov >> >> Sent: Mittwoch, 21. August 2013 00:06 >> >> Cc: 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> >> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX >> >> I looked throw reviews and fount only one not answered question: >> >> On 8/15/13 5:14 PM, David Holmes wrote: >> >>>> allocation.hpp >> >>>> xlC complains: >> >>>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 (S) The "private" >> >>>> member "StackObj::operator delete(void *)" cannot be accessed. >> >>> >> >>> Hmmm. So the whole point of these being private was so that they could >> >>> not be called but we had to override the use of the global operators. >> >>> The concrete implementations then give fatal errors if you do manage to >> >>> use them (impossible?). So making them public is undesirable. >> >>> >> >>> Is there some other way to resolve this? A pragma to tell xlC to ignore >> >>> the perceived problem? >> >> thanks, >> >> Vladimir >> >> On 8/19/13 9:32 AM, Vladimir Kozlov wrote: >> >>> I tested 8023033-aixShared-2 in JPRT (including builds and tests on ppc >> >>> + arm) and it passed without failures. >> >>> >> >>> Thanks, >> >>> Vladimir >> >>> >> >>> On 8/16/13 3:06 PM, Stefan Karlsson wrote: >> >>>> On 8/16/13 11:28 PM, Lindenmaier, Goetz wrote: >> >>>>> >> >>>>> Hi Stefan, >> >>>>> >> >>>>> the problem is that globalDefinitions defines __STDC_FORMAT_MACROS. >> >>>>> >> >>>>> inttypes.hpp comes in through jni.hpp, which is in both, jvm.hpp and >> >>>>> >> >>>>> globalDefinitions.hpp through globalDefinitions_.hpp. >> >>>>> >> >>>>> If jvm.hpp comes first, inttype.hpp is added without the macro defined, >> >>>>> >> >>>>> and the print formats are missing. >> >>>>> >> >>>>> I could also define __STDC_FORMAT_MACROS in jni.hpp or the like. >> >>>>> >> >>>>> The name "globalDefinitions" somehow says that the definitions should >> >>>>> be seen >> >>>>> >> >>>>> everywhere ... so it's basically bad that the file does not end up at >> >>>>> the top of the include >> >>>>> >> >>>>> chain. Maybe I should include it in jni.hpp? or jvm.hpp? >> >>>>> >> >>>>> What do you think? >> >>>>> >> >>>> >> >>>> I see your problem. >> >>>> >> >>>> I think the most stable solution would be to add -D__STDC_FORMAT_MACROS >> >>>> to the compiler flags. >> >>>> >> >>>> But that seems out-of-scope for this change, so go ahead and use the >> >>>> reordering for now (unless someone else complains). >> >>>> >> >>>> thanks, >> >>>> StefanK >> >>>> >> >>>>> Best regards, >> >>>>> >> >>>>> Goetz. >> >>>>> >> >>>>> *From:*Stefan Karlsson [mailto:stefan.karlsson at oracle.com] >> >>>>> *Sent:* Friday, August 16, 2013 3:09 PM >> >>>>> *To:* Lindenmaier, Goetz >> >>>>> *Cc:* 'Vladimir Kozlov'; 'David Holmes'; >> >>>>> 'ppc-aix-port-dev at openjdk.java.net'; 'hotspot-dev at openjdk.java.net' >> >>>>> *Subject:* Re: RFR (M): 8023033: PPC64 (part 13): basic changes for AIX >> >>>>> >> >>>>> Hi Goetz, >> >>>>> >> >>>>> On 8/16/13 2:21 PM, Lindenmaier, Goetz wrote: >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> >> >>>>> >> >>>>> - I removed the throw() >> >>>>> >> >>>>> - I removed the #ifndef in port.hpp >> >>>>> >> >>>>> - I fixed the typeo. >> >>>>> >> >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared-2/ >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> I always build without precompiled headers, the nightbuild with >> >>>>> >> >>>>> them. >> >>>>> >> >>>>> >> >>>>> utilities/debug.hpp.udiff.html >> >>>>> >> >>>>> -#include "prims/jvm.h" >> >>>>> #include "utilities/globalDefinitions.hpp" >> >>>>> +#include "prims/jvm.h" >> >>>>> >> >>>>> I don't think your change to debug.hpp is the correct way to solve >> >>>>> the problems you were seeing with metaspace.hpp. Swapping the files >> >>>>> just means that someone else might hit the same problem adding >> >>>>> prims/jvm.hpp to another file. >> >>>>> >> >>>>> >> >>>>> You probably have a circular include dependency somewhere in the >> >>>>> code. Could you revert the change to utilities/debug.hpp and try to >> >>>>> figure out what the real problem is? >> >>>>> >> >>>>> thanks, >> >>>>> StefanK >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Yes, there will be makefiles for aix, and the platform files. >> >>>>> tTe prototype >> >>>>> >> >>>>> patches are here >> >>>>> >> >>>>> >> >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0014_aix_make_changes.patch >> >>>>> >> >>>>> >> >>>>> >> >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/ppc_patches/0015_aix_ppc_files.patch >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> But the make change contains mostly new files, except for >> >>>>> >> >>>>> >> >>>>> >> >>>>> --- a/make/defs.make Tue Jul 23 21:07:11 2013 +0200 >> >>>>> >> >>>>> +++ b/make/defs.make Tue Jul 23 22:13:05 2013 +0200 >> >>>>> >> >>>>> @@ -166,11 +166,15 @@ >> >>>>> >> >>>>> HOST := $(shell uname -n) >> >>>>> >> >>>>> endif >> >>>>> >> >>>>> >> >>>>> >> >>>>> -# If not SunOS, not Linux and not BSD, assume Windows >> >>>>> >> >>>>> +# If not SunOS, not Linux not BSD and not AIX, assume Windows >> >>>>> >> >>>>> ifneq ($(OS), Linux) >> >>>>> >> >>>>> ifneq ($(OS), SunOS) >> >>>>> >> >>>>> ifneq ($(OS), bsd) >> >>>>> >> >>>>> - OSNAME=windows >> >>>>> >> >>>>> + ifneq ($(OS), AIX) >> >>>>> >> >>>>> + OSNAME=windows >> >>>>> >> >>>>> + else >> >>>>> >> >>>>> + OSNAME=aix >> >>>>> >> >>>>> + endif >> >>>>> >> >>>>> else >> >>>>> >> >>>>> OSNAME=bsd >> >>>>> >> >>>>> endif >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Best regards, >> >>>>> >> >>>>> Goetz >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -----Original Message----- >> >>>>> >> >>>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> >>>>> >> >>>>> Sent: Friday, August 16, 2013 7:21 AM >> >>>>> >> >>>>> To: David Holmes >> >>>>> >> >>>>> Cc: Lindenmaier, Goetz; 'ppc-aix-port-dev at openjdk.java.net >> >>>>> ';'hotspot-dev at openjdk.java.net >> >>>>> ' >> >>>>> >> >>>>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic changes for >> >>>>> AIX >> >>>>> >> >>>>> >> >>>>> >> >>>>> I thought trow() was added long time ago. But it was added, I >> >>>>> think by accident, very recently: >> >>>>> >> >>>>> >> >>>>> >> >>>>> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/a7fb14888912 >> >>>>> >> >>>>> >> >>>>> >> >>>>> I missed it when I did the review of those changes. >> >>>>> >> >>>>> >> >>>>> >> >>>>> We should remove throw. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Vladimir >> >>>>> >> >>>>> >> >>>>> >> >>>>> On 8/15/13 5:14 PM, David Holmes wrote: >> >>>>> >> >>>>> On 16/08/2013 7:54 AM, Vladimir Kozlov wrote: >> >>>>> >> >>>>> On 8/15/13 2:32 PM, Lindenmaier, Goetz wrote: >> >>>>> >> >>>>> Hi Vladimir, >> >>>>> >> >>>>> >> >>>>> >> >>>>> throw is needed because it`s there in the >> >>>>> implementation in nmethod.cpp. >> >>>>> >> >>>>> (So you are using it a bit at least :)) >> >>>>> >> >>>>> xlc says >> >>>>> >> >>>>> "nmethod.cpp", line 802.7: 1540-0400 (S) >> >>>>> "nmethod::operator >> >>>>> >> >>>>> new(size_t, int)" has a conflicting declaration. >> >>>>> >> >>>>> "nmethod.hpp", line 268.9: 1540-0424 (I) "operator >> >>>>> new" is declared on >> >>>>> >> >>>>> line 268 of "nmethod.hpp". >> >>>>> >> >>>>> >> >>>>> >> >>>>> Okay, it is just declaration. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Why do we have throw here: >> >>>>> >> >>>>> >> >>>>> >> >>>>> void* nmethod::operator new(size_t size, int nmethod_size) >> >>>>> throw () { >> >>>>> >> >>>>> // Not critical, may return null if there is too little >> >>>>> continuous memory >> >>>>> >> >>>>> return CodeCache::allocate(nmethod_size); >> >>>>> >> >>>>> } >> >>>>> >> >>>>> >> >>>>> >> >>>>> Seems to me it should be removed if anything. >> >>>>> >> >>>>> >> >>>>> >> >>>>> David >> >>>>> >> >>>>> ----- >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> int64 is defined correctly, uint64 is not defined, >> >>>>> but never used in >> >>>>> >> >>>>> hotspot. >> >>>>> >> >>>>> I can not reproduce an error, but that's rather old >> >>>>> coding from our VM. >> >>>>> >> >>>>> We also switched from xlc8 to xlc10 in the course of >> >>>>> this project. >> >>>>> >> >>>>> I will test some more and talk to the person who >> >>>>> implemented that >> >>>>> >> >>>>> tomorrow, >> >>>>> >> >>>>> and if possible remove the change. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Okay, I will test it also. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Vladimir >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Best regards & thanks for the review, >> >>>>> >> >>>>> Goetz. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -----Original Message----- >> >>>>> >> >>>>> From: Vladimir Kozlov >> >>>>> [mailto:vladimir.kozlov at oracle.com] >> >>>>> >> >>>>> Sent: Thursday, August 15, 2013 5:52 PM >> >>>>> >> >>>>> To: Lindenmaier, Goetz >> >>>>> >> >>>>> Cc: 'hotspot-dev at openjdk.java.net >> >>>>> ';ppc-aix-port-dev at openjdk.java.net >> >>>>> ; >> >> >>> >> >> >>> Albert Noll (albert.noll at oracle.com >> >> >>> ) >> >>>>> >> >>>>> Subject: Re: RFR (M): 8023033: PPC64 (part 13): basic >> >>>>> changes for AIX >> >>>>> >> >>>>> >> >>>>> >> >>>>> Goetz, >> >>>>> >> >>>>> >> >>>>> >> >>>>> I only see 2 problems which you did not explain: >> >>>>> >> >>>>> >> >>>>> >> >>>>> nmethod.hpp. Why the next change? we don't use C++ >> >>>>> exceptions: >> >>>>> >> >>>>> >> >>>>> >> >>>>> - void* operator new(size_t size, int nmethod_size); >> >>>>> >> >>>>> + void* operator new(size_t size, int nmethod_size) >> >>>>> throw (); >> >>>>> >> >>>>> >> >>>>> >> >>>>> port.hpp. Did AIX has the same definitions for jlong >> >>>>> and julong?: >> >>>>> >> >>>>> >> >>>>> >> >>>>> +#ifndef _AIX >> >>>>> >> >>>>> +// These conflict with /usr/include/sys/inttypes.h >> >>>>> on aix. >> >>>>> >> >>>>> typedef jlong int64; // Java long for >> >>>>> my 64-bit type >> >>>>> >> >>>>> typedef julong uint64; // Java long for >> >>>>> my 64-bit type >> >>>>> >> >>>>> +#endif >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> And of cause we need to test these changes with >> >>>>> compilers we use. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Thanks, >> >>>>> >> >>>>> Vladimir >> >>>>> >> >> >>> >> >> >>> >> >> >>> On 8/15/13 5:10 AM, Lindenmaier, Goetz wrote: >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> >> >>>>> >> >>>>> I prepared a webrev for >> >>>>> >> >>>>> 8023033: PPC64 (part 13): basic changes for AIX >> >>>>> >> >>>>> >> >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8023033-aixShared/ >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> This contains the basic shared changes needed for >> >>>>> the AIX port, >> >>>>> >> >>>>> as there are >> >>>>> >> >>>>> - #includes >> >>>>> >> >>>>> - Fixes to get the code compiling with xlC/on AIX >> >>>>> >> >>>>> - Basic adaptions as in vm_version.cpp. >> >>>>> >> >>>>> >> >>>>> >> >>>>> It also determines the placement and naming of >> >>>>> the aix files, >> >>>>> >> >>>>> which will go to os/aix and os_cpu/aix_ppc, as >> >>>>> you can see in >> >>>>> >> >>>>> >> >>>>> http://hg.openjdk.java.net/ppc-aix-port/jdk8/hotspot/file/9677ba28c6d8/src/os/aix/vm/ >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Some details about the compilation problems: >> >>>>> >> >>>>> >> >>>>> >> >>>>> relocInfo.hpp: >> >>>>> >> >>>>> xlC wants initialization in inline implementation. >> >>>>> >> >>>>> >> >>>>> >> >>>>> vmreg.hpp: >> >>>>> >> >>>>> BAD is defined in AIX system header sys/param.h. >> >>>>> Renamed. >> >>>>> >> >>>>> >> >>>>> >> >>>>> allocation.hpp >> >>>>> >> >>>>> xlC complains: >> >>>>> >> >>>>> runtime/mutexLocker.hpp", line 192.3: 1540-0300 >> >>>>> (S) The "private" >> >>>>> >> >>>>> member "StackObj::operator delete(void *)" cannot >> >>>>> be accessed. >> >>>>> >> >>>>> >> >>>>> >> >>>>> sharedRuntimeTrig.cpp >> >>>>> >> >>>>> Aix defines hz to be 100, see sys/m_param.h. >> >>>>> Renamed. >> >>>>> >> >>>>> >> >>>>> >> >>>>> debug.hpp >> >>>>> >> >>>>> With other include order we get a lot of >> >>>>> >> >>>>> memory/metaspace.hpp", line 281.66: 1540-0130 (S) >> >>>>> "PRIuPTR" is not >> >>>>> >> >>>>> declared. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Please review and test this change. Comments are >> >>>>> welcome. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Thanks and best regards, >> >> >>> >> >> >>> Goetz. >> >> >>> >> >> >>> >> >> >>> >> >> >> >> From john.coomes at oracle.com Thu Aug 22 10:31:39 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 22 Aug 2013 17:31:39 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b104 for changeset d411c60a8c2f Message-ID: <20130822173142.D997348AA6@hg.openjdk.java.net> Changeset: 4e38de7c767e Author: cl Date: 2013-08-22 09:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/4e38de7c767e Added tag jdk8-b104 for changeset d411c60a8c2f ! .hgtags From john.coomes at oracle.com Thu Aug 22 10:31:49 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 22 Aug 2013 17:31:49 +0000 Subject: hg: hsx/hotspot-main/jaxp: Added tag jdk8-b104 for changeset a22fe9bd01e6 Message-ID: <20130822173201.29B2148AA7@hg.openjdk.java.net> Changeset: af28b93bfb6f Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/af28b93bfb6f Added tag jdk8-b104 for changeset a22fe9bd01e6 ! .hgtags From john.coomes at oracle.com Thu Aug 22 10:32:10 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 22 Aug 2013 17:32:10 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b104 for changeset 42211ab0ab1c Message-ID: <20130822173218.4835648AA8@hg.openjdk.java.net> Changeset: 88390df7ed2c Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/88390df7ed2c Added tag jdk8-b104 for changeset 42211ab0ab1c ! .hgtags From john.coomes at oracle.com Thu Aug 22 10:34:49 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 22 Aug 2013 17:34:49 +0000 Subject: hg: hsx/hotspot-main/langtools: Added tag jdk8-b104 for changeset dd4a00c220c6 Message-ID: <20130822173504.4AC6048AAA@hg.openjdk.java.net> Changeset: f2ee3a4e7927 Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f2ee3a4e7927 Added tag jdk8-b104 for changeset dd4a00c220c6 ! .hgtags From john.coomes at oracle.com Thu Aug 22 10:32:32 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 22 Aug 2013 17:32:32 +0000 Subject: hg: hsx/hotspot-main/jdk: Added tag jdk8-b104 for changeset f1d8d15bfcb5 Message-ID: <20130822173352.D22DA48AA9@hg.openjdk.java.net> Changeset: c982f579b67e Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c982f579b67e Added tag jdk8-b104 for changeset f1d8d15bfcb5 ! .hgtags From john.coomes at oracle.com Thu Aug 22 10:35:15 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 22 Aug 2013 17:35:15 +0000 Subject: hg: hsx/hotspot-main/nashorn: Added tag jdk8-b104 for changeset afc100513451 Message-ID: <20130822173520.63EE648AAB@hg.openjdk.java.net> Changeset: 74244f43c577 Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/74244f43c577 Added tag jdk8-b104 for changeset afc100513451 ! .hgtags From john.coomes at oracle.com Thu Aug 22 10:31:30 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 22 Aug 2013 17:31:30 +0000 Subject: hg: hsx/hotspot-main: 5 new changesets Message-ID: <20130822173131.6692948AA5@hg.openjdk.java.net> Changeset: 4fb877dfe5c4 Author: erikj Date: 2013-08-15 17:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/4fb877dfe5c4 8020411: lin32 - JDK 8 build for Linux-i586 on Oracle Linux 6.4 64-bit machines does not generate the bundles directory in the build directory Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in Changeset: f10f673d9b17 Author: igerasim Date: 2013-08-16 14:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f10f673d9b17 8023156: make dist-clean should remove javacservers directory Reviewed-by: erikj ! common/makefiles/Main.gmk Changeset: dadf49495ab4 Author: erikj Date: 2013-08-19 10:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/dadf49495ab4 8021430: 64 bit JDK build fails on windows 7 due to missing corba source files Reviewed-by: tbell, katleman ! common/makefiles/IdlCompilation.gmk Changeset: 96c1b9b7524b Author: katleman Date: 2013-08-20 15:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/96c1b9b7524b Merge Changeset: c3b5197f2851 Author: cl Date: 2013-08-22 09:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/c3b5197f2851 Added tag jdk8-b104 for changeset 96c1b9b7524b ! .hgtags From adomurad at redhat.com Thu Aug 22 11:13:16 2013 From: adomurad at redhat.com (Adam Domurad) Date: Thu, 22 Aug 2013 14:13:16 -0400 Subject: RR(S): 8009062 poor performance of JNI AttachCurrentThread after fix for 7017193 In-Reply-To: <5213B5C1.3000705@oracle.com> References: <5213B5C1.3000705@oracle.com> Message-ID: <521654BC.408@redhat.com> On 08/20/2013 02:30 PM, Dmitry Samersoff wrote: > Hi Everybody, > > Here is webrev of changes I'm about to integrate: > > http://cr.openjdk.java.net/~dsamersoff/8009062/webrev.13/ > > The problem: > > Under Linux stack of main thread is growable, so we have to make sure > that address we plan to put a guard pages to and below is not mapped. > > Historically we find bounds of the stack of main thread by seeking > /proc/self/maps for "[stack]" and parsing this line. > > But after intensive testing we figured out that it's not required to > re-read stack bounds after create_attached_thread() because we are > manually grow stack up to the bounds in create_attached_thread() > > > Solution: > > I use mincore(2) to check whether > the page is mapped or not. Typically mincore(2) is used to check whether > the page is resides in physical memory or not, but this function returns > -1 and set errno to ENOMEM if a region we are asking about contains not > mapped memory. > > Testing: > > Passed jprt, jck and and couple of ute tests. Wrote special regression test. > > -Dmitry > It checks out from my end. Thanks for sticking with it! -Adam From rickard.backman at oracle.com Thu Aug 22 13:59:16 2013 From: rickard.backman at oracle.com (rickard.backman at oracle.com) Date: Thu, 22 Aug 2013 20:59:16 +0000 Subject: hg: hsx/hotspot-main/hotspot: 10 new changesets Message-ID: <20130822205938.1347F48AD7@hg.openjdk.java.net> Changeset: afbe18ae0905 Author: bharadwaj Date: 2013-08-15 11:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/afbe18ae0905 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases Summary: Corrected details Reviewed-by: kvn, twisti, rbackman Contributed-by: david.r.chase at oracle.com ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: adb9a7d94cb5 Author: adlertz Date: 2013-08-16 10:23 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/adb9a7d94cb5 8023003: Cleanup the public interface to PhaseCFG Summary: public methods that don't need to be public should be private. Reviewed-by: kvn, twisti ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 6c72125a2f40 Author: iignatyev Date: 2013-08-16 17:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6c72125a2f40 8016456: ciReplay test assumes TIERED compilation is available Reviewed-by: vlivanov, kvn, dholmes ! test/compiler/ciReplay/common.sh Changeset: f99558245e5c Author: iignatyev Date: 2013-08-14 23:50 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f99558245e5c 8022832: Add WB APIs for OSR compilation Reviewed-by: kvn ! src/share/vm/oops/method.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/compiler/whitebox/SetForceInlineMethodTest.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: d18b10b1fd09 Author: iignatyev Date: 2013-08-16 13:39 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d18b10b1fd09 Merge Changeset: 4b2838704fd5 Author: kvn Date: 2013-08-16 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4b2838704fd5 8021898: Broken JIT compiler optimization for loop unswitching Summary: fix method clone_projs() to clone all related MachProj nodes. Reviewed-by: roland, adlertz ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 6725044c5725 Author: rbackman Date: 2013-08-19 09:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/6725044c5725 Merge ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/oops/method.cpp Changeset: e16282db4946 Author: twisti Date: 2013-08-20 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e16282db4946 8022956: Clang: enable return type warnings on BSD Reviewed-by: coleenp, sla ! make/bsd/makefiles/gcc.make ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/interp_masm_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/cpu/zero/vm/nativeInst_zero.hpp ! src/cpu/zero/vm/register_zero.cpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/cpu/zero/vm/vtableStubs_zero.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp Changeset: acedd49a1bce Author: rbackman Date: 2013-08-08 03:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/acedd49a1bce 8022675: Redundant class init check Reviewed-by: kvn, twisti ! src/share/vm/opto/library_call.cpp Changeset: 4dece0730c50 Author: rbackman Date: 2013-08-22 18:37 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4dece0730c50 Merge ! src/share/vm/runtime/vmStructs.cpp ! test/compiler/ciReplay/common.sh From christian.thalinger at oracle.com Thu Aug 22 15:04:26 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 22 Aug 2013 15:04:26 -0700 Subject: RFR (L): 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment In-Reply-To: References: Message-ID: After internal discussions and major pushback I am withdrawing this review. -- Chris On Aug 19, 2013, at 2:28 PM, Christian Thalinger wrote: > http://cr.openjdk.java.net/~twisti/8022853/webrev/ > http://cr.openjdk.java.net/~twisti/8022853-jdk/webrev/ > > 8022853: add ability to Unsafe to load and store uncompressed object and Klass references in a compressed environment > Reviewed-by: > > In some native data structures of the VM oops are stored uncompressed when compressed oops are turned on, for example Klass::_java_mirror. Java code which is tightly coupled with the VM should have the ability to read and write such fields. > From jon.masamitsu at oracle.com Thu Aug 22 19:59:50 2013 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Fri, 23 Aug 2013 02:59:50 +0000 Subject: hg: hsx/hotspot-main/hotspot: 11 new changesets Message-ID: <20130823030016.4F5B448AE2@hg.openjdk.java.net> Changeset: 5888334c9c24 Author: johnc Date: 2013-08-15 10:52 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5888334c9c24 7145569: G1: optimize nmethods scanning Summary: Add a list of nmethods to the RSet for a region that contain references into the region. Skip scanning the code cache during root scanning and scan the nmethod lists during RSet scanning instead. Reviewed-by: tschatzl, brutisso, mgerdin, twisti, kvn ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/utilities/growableArray.hpp Changeset: 8088d93a63e6 Author: brutisso Date: 2013-08-15 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8088d93a63e6 Merge Changeset: 9720d338b1d5 Author: brutisso Date: 2013-08-16 11:26 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/9720d338b1d5 8023145: G1: G1CollectedHeap::mark_strong_code_roots() needs to handle ParallelGCThreads=0 Reviewed-by: stefank, mgerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: d0afbee540e0 Author: stefank Date: 2013-08-19 13:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/d0afbee540e0 8023227: Enhance layout_helper_log2_element_size assert Reviewed-by: mgerdin, jmasa ! src/share/vm/oops/klass.hpp Changeset: 422920730903 Author: ehelin Date: 2013-08-19 18:17 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/422920730903 8023219: NPG: MetaspaceMemoryPool should report statistics for all of metaspace Reviewed-by: stefank, sjohanss ! src/share/vm/services/memoryPool.cpp Changeset: 57600c4aeabe Author: jmasa Date: 2013-08-19 08:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/57600c4aeabe Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 31f220c1f789 Author: jmasa Date: 2013-08-20 10:02 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/31f220c1f789 Merge Changeset: 61521bd65100 Author: tschatzl Date: 2013-08-21 10:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/61521bd65100 8022784: TaskQueue misses minimal documentation and references for analysis Summary: Add appropriate documentation and references to publication to allow easier analysis of the TaskQueue implementation. Reviewed-by: dholmes, ehelin ! src/share/vm/utilities/taskqueue.hpp Changeset: cb9da55b1990 Author: jmasa Date: 2013-08-14 19:52 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cb9da55b1990 8021809: Partitioning based on eden sampling during allocation not reset correctly Reviewed-by: ysr, hiroshi ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: b51aee2dd8bb Author: jmasa Date: 2013-08-22 11:13 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b51aee2dd8bb Merge ! src/share/vm/oops/klass.hpp Changeset: 8009adb44523 Author: jmasa Date: 2013-08-22 14:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/8009adb44523 Merge From roland.westrelin at oracle.com Fri Aug 23 00:40:16 2013 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 23 Aug 2013 09:40:16 +0200 Subject: Result: New HSX Committer: Niclas Adlertz Message-ID: Voting for Niclas Adlertz [1] is now closed. Yes: 19 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. Best regards, Roland Westrelin [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-August/010462.html [2] http://openjdk.java.net/bylaws#lazy-consensus From yunda.mly at taobao.com Fri Aug 23 02:13:05 2013 From: yunda.mly at taobao.com (=?UTF-8?B?5LqR6L6+KFl1bmRhKQ==?=) Date: Fri, 23 Aug 2013 17:13:05 +0800 Subject: RFR: 8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__" In-Reply-To: <62A30946-19C0-4B9D-9CDC-9E9EB2E2B77C@oracle.com> References: <3476F401-E6AF-44C3-871E-62F2681DC8D9@oracle.com> <5208FA82.5090509@oracle.com> <62A30946-19C0-4B9D-9CDC-9E9EB2E2B77C@oracle.com> Message-ID: <009201ce9fe0$fa8194d0$ef84be70$@taobao.com> Peter & Kris Thank both of you very much! Yunda From: serviceability-dev-bounces at openjdk.java.net [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Peter Allwin Sent: Thursday, August 22, 2013 5:34 PM To: Krystal Mok Cc: serviceability-dev at openjdk.java.net; hotspot-dev Subject: Re: RFR: 8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__" Hi Kris, Thanks for the reminder, I added Yunda as a contributor. Thanks everyone for your reviews! Regards, /peter On Aug 12, 2013, at 6:03 PM, Krystal Mok wrote: Hi Peter, Looks good to me. Thank you! I'd like to mention again that the getHandle -> getAddress change has been purposed by Yunda, which I mentioned in [1], too. Best regards, Kris (kmo) On Monday, August 12, 2013, A. Sundararajan wrote: Looks good -Sundar On Monday 12 August 2013 06:21 PM, Peter Allwin wrote: Hello! This patch addresses several Nashorn compatibility issues with in sa.js and is a merge of my patch [0] and Kris' (kmo) [1] which were developed separately. The merged change is identical to [1] with except for line 785 where I've added a conversion to JavaScript String to ensure the correct replace method is called. webrev: http://cr.openjdk.java.net/~allwin/8011888/webrev.01/ bug: http://bugs.sun.com/view_bug.do?bug_id=8011888 Thanks! /Peter [0] http://cr.openjdk.java.net/~allwin/8011888/webrev.00/ [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-July/010831.html From thomas.schatzl at oracle.com Fri Aug 23 03:32:31 2013 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 23 Aug 2013 12:32:31 +0200 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: <5215F486.6050105@oracle.com> References: <51D3065C.6090401@oracle.com> <5215F486.6050105@oracle.com> Message-ID: <1377253951.3010.43.camel@cirrus> Hi Stefan, On Thu, 2013-08-22 at 13:22 +0200, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8007074/webrev.01/ > > Hi all, > > The original patch didn't make it in time for the hs24 release. So, > please review this patch that's now based on hs25 (JDK8) instead of hs24. > > The main difference between the two patches is the heap setup code, > which is different because of the permgen removal. Still looks good. Minor nit: Why is there a difference to the hsx24 patch of the text in the assert at the end of Universe::preferred_heap_base()? I.e. "" instead of "Must be"? Thanks, Thomas From stefan.karlsson at oracle.com Fri Aug 23 03:47:46 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 23 Aug 2013 12:47:46 +0200 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: <1377253951.3010.43.camel@cirrus> References: <51D3065C.6090401@oracle.com> <5215F486.6050105@oracle.com> <1377253951.3010.43.camel@cirrus> Message-ID: <52173DD2.8060106@oracle.com> On 2013-08-23 12:32, Thomas Schatzl wrote: > Hi Stefan, > > On Thu, 2013-08-22 at 13:22 +0200, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8007074/webrev.01/ >> >> Hi all, >> >> The original patch didn't make it in time for the hs24 release. So, >> please review this patch that's now based on hs25 (JDK8) instead of hs24. >> >> The main difference between the two patches is the heap setup code, >> which is different because of the permgen removal. > Still looks good. Thanks! > > Minor nit: > Why is there a difference to the hsx24 patch of the text in the assert > at the end of Universe::preferred_heap_base()? I.e. "" instead of "Must > be"? I'll fix it. thanks, StefanK > > Thanks, > Thomas > > From stefan.johansson at oracle.com Fri Aug 23 05:30:04 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 23 Aug 2013 14:30:04 +0200 Subject: RFR: 8016155: SIGBUS when running Kitchensink with ParallelScavenge and ParallelOld Message-ID: <521755CC.7040303@oracle.com> Hi all, I would like some reviews on my fix for bug: http://bugs.sun.com/view_bug.do?bug_id=8016155 Webrev: http://cr.openjdk.java.net/~sjohanss/8016155/webrev.00 Summary: On Linux we have a problem that we hit a SIGBUS when one NUMA node runs out of large pages but the system as a whole has large pages left. To avoid this we need to ease the requirement on which node the memory should be allocated on. This can be done by using the memory policy MPOL_PREFERRED, which prefers a certain node, instead of MPOL_BIND, which requires a certain node. Testing: To verify the fix I've run Kitchensink as describe in the bug report, but also done some manual testing. To sanity test performance I've run SPECjbb2005 with and without UseNUMA before and after the fix and I haven't seen any problem. I also ran SPECjbb2005 on a system where one NUMA node has been configured with no large pages while the other has enough for the test. Without the fix this crashes immediately, but with the fix the results are sane. Thanks, Stefan From per.liden at oracle.com Fri Aug 23 06:00:32 2013 From: per.liden at oracle.com (Per Liden) Date: Fri, 23 Aug 2013 15:00:32 +0200 Subject: RFR: 8016155: SIGBUS when running Kitchensink with ParallelScavenge and ParallelOld In-Reply-To: <521755CC.7040303@oracle.com> References: <521755CC.7040303@oracle.com> Message-ID: <52175CF0.10603@oracle.com> Fix looks good! /Per On 08/23/2013 02:30 PM, Stefan Johansson wrote: > Hi all, > > I would like some reviews on my fix for bug: > http://bugs.sun.com/view_bug.do?bug_id=8016155 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8016155/webrev.00 > > Summary: > On Linux we have a problem that we hit a SIGBUS when one NUMA node > runs out of large pages but the system as a whole has large pages > left. To avoid this we need to ease the requirement on which node the > memory should be allocated on. This can be done by using the memory > policy MPOL_PREFERRED, which prefers a certain node, instead of > MPOL_BIND, which requires a certain node. > > Testing: > To verify the fix I've run Kitchensink as describe in the bug report, > but also done some manual testing. To sanity test performance I've run > SPECjbb2005 with and without UseNUMA before and after the fix and I > haven't seen any problem. I also ran SPECjbb2005 on a system where one > NUMA node has been configured with no large pages while the other has > enough for the test. Without the fix this crashes immediately, but > with the fix the results are sane. > > Thanks, > Stefan From alejandro.murillo at oracle.com Fri Aug 23 07:14:45 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 23 Aug 2013 14:14:45 +0000 Subject: hg: hsx/hsx25/hotspot: 36 new changesets Message-ID: <20130823141610.0074548B03@hg.openjdk.java.net> Changeset: c93e0a210e1b Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c93e0a210e1b Added tag jdk8-b104 for changeset 104743074675 ! .hgtags Changeset: 37165c3618a3 Author: amurillo Date: 2013-08-16 04:24 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/37165c3618a3 8023152: new hotspot build - hs25-b47 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d96f52012aaa Author: rdurbin Date: 2013-08-14 15:12 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d96f52012aaa 8005073: [TESTBUG] remove crufty '_g' support from HS tests Summary: remove crufty '_g' support from HS tests Reviewed-by: dcubed, sla ! test/Makefile Changeset: 740e263c80c6 Author: hseigel Date: 2013-08-15 20:04 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/740e263c80c6 8003424: Enable Class Data Sharing for CompressedOops 8016729: ObjectAlignmentInBytes=16 now forces the use of heap based compressed oops 8005933: The -Xshare:auto option is ignored for -server Summary: Move klass metaspace above the heap and support CDS with compressed klass ptrs. Reviewed-by: coleenp, kvn, mgerdin, tschatzl, stefank ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/heap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klass.inline.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/utilities/globalDefinitions.hpp + test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java + test/runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java + test/runtime/CDSCompressedKPtrs/XShareAuto.java ! test/runtime/SharedArchiveFile/CdsSameObjectAlignment.java Changeset: e5003079dfa5 Author: dcubed Date: 2013-08-16 10:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e5003079dfa5 Merge ! src/share/vm/utilities/globalDefinitions.hpp Changeset: b1fd869e7df0 Author: minqi Date: 2013-08-19 09:16 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b1fd869e7df0 8023188: Unsafe volatile double store on bsd is broken Reviewed-by: dcubed, dholmes Contributed-by: yumin.qi at oracle.com ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp Changeset: 1a8fb39bdbc4 Author: ehelin Date: 2013-08-07 16:47 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1a8fb39bdbc4 8014659: NPG: performance counters for compressed klass space Reviewed-by: mgerdin, coleenp, hseigel, jmasa, ctornqvi ! src/share/vm/gc_implementation/g1/g1MonitoringSupport.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/memory/universe.cpp + test/gc/metaspace/TestMetaspacePerfCounters.java + test/testlibrary/AssertsTest.java + test/testlibrary/com/oracle/java/testlibrary/Asserts.java + test/testlibrary/com/oracle/java/testlibrary/ByteCodeLoader.java + test/testlibrary/com/oracle/java/testlibrary/InMemoryJavaCompiler.java + test/testlibrary/com/oracle/java/testlibrary/InputArguments.java + test/testlibrary/com/oracle/java/testlibrary/PerfCounter.java + test/testlibrary/com/oracle/java/testlibrary/PerfCounters.java Changeset: 878bb0b7e799 Author: ehelin Date: 2013-08-19 17:29 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/878bb0b7e799 Merge Changeset: 10c59b8021ec Author: kevinw Date: 2013-08-19 14:28 +0100 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/10c59b8021ec 8022655: ClassDump ignored jarStream setting Reviewed-by: minqi, sla ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java ! test/compiler/ciReplay/common.sh Changeset: 9011aa6843ce Author: kevinw Date: 2013-08-19 22:28 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9011aa6843ce Merge Changeset: e22ee8e7ae62 Author: jiangli Date: 2013-08-19 14:59 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e22ee8e7ae62 8021948: Change InstanceKlass::_source_file_name and _generic_signature from Symbol* to constant pool indexes. Summary: Change InstanceKlass::_source_file_name and _generic_signature to u2 fields. Reviewed-by: coleenp, iklam ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: aeebffb56606 Author: jiangli Date: 2013-08-20 00:48 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/aeebffb56606 Merge Changeset: 9d6c9b0a8f15 Author: dcubed Date: 2013-08-20 13:47 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9d6c9b0a8f15 8023287: HOTSPOT_BUILD_COMPILER needs to support "Sun Studio 12u3" Summary: Recognize 0x5120 as "Sun Studio 12u3". Reviewed-by: dholmes, coleenp ! src/share/vm/runtime/vm_version.cpp Changeset: afbe18ae0905 Author: bharadwaj Date: 2013-08-15 11:59 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/afbe18ae0905 8022441: Bad code generated for certain interpreted CRC intrinsics, 2 cases Summary: Corrected details Reviewed-by: kvn, twisti, rbackman Contributed-by: david.r.chase at oracle.com ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: adb9a7d94cb5 Author: adlertz Date: 2013-08-16 10:23 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/adb9a7d94cb5 8023003: Cleanup the public interface to PhaseCFG Summary: public methods that don't need to be public should be private. Reviewed-by: kvn, twisti ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 6c72125a2f40 Author: iignatyev Date: 2013-08-16 17:34 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6c72125a2f40 8016456: ciReplay test assumes TIERED compilation is available Reviewed-by: vlivanov, kvn, dholmes ! test/compiler/ciReplay/common.sh Changeset: f99558245e5c Author: iignatyev Date: 2013-08-14 23:50 +0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f99558245e5c 8022832: Add WB APIs for OSR compilation Reviewed-by: kvn ! src/share/vm/oops/method.cpp ! src/share/vm/prims/whitebox.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/compilationPolicy.hpp ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/compiler/whitebox/SetForceInlineMethodTest.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: d18b10b1fd09 Author: iignatyev Date: 2013-08-16 13:39 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d18b10b1fd09 Merge Changeset: 4b2838704fd5 Author: kvn Date: 2013-08-16 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4b2838704fd5 8021898: Broken JIT compiler optimization for loop unswitching Summary: fix method clone_projs() to clone all related MachProj nodes. Reviewed-by: roland, adlertz ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 6725044c5725 Author: rbackman Date: 2013-08-19 09:33 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/6725044c5725 Merge ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/oops/method.cpp Changeset: e16282db4946 Author: twisti Date: 2013-08-20 10:57 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e16282db4946 8022956: Clang: enable return type warnings on BSD Reviewed-by: coleenp, sla ! make/bsd/makefiles/gcc.make ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/interp_masm_zero.hpp ! src/cpu/zero/vm/interpreter_zero.cpp ! src/cpu/zero/vm/nativeInst_zero.hpp ! src/cpu/zero/vm/register_zero.cpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/cpu/zero/vm/vtableStubs_zero.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/thread_bsd_zero.hpp Changeset: acedd49a1bce Author: rbackman Date: 2013-08-08 03:16 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/acedd49a1bce 8022675: Redundant class init check Reviewed-by: kvn, twisti ! src/share/vm/opto/library_call.cpp Changeset: 4dece0730c50 Author: rbackman Date: 2013-08-22 18:37 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4dece0730c50 Merge ! src/share/vm/runtime/vmStructs.cpp ! test/compiler/ciReplay/common.sh Changeset: 5888334c9c24 Author: johnc Date: 2013-08-15 10:52 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5888334c9c24 7145569: G1: optimize nmethods scanning Summary: Add a list of nmethods to the RSet for a region that contain references into the region. Skip scanning the code cache during root scanning and scan the nmethod lists during RSet scanning instead. Reviewed-by: tschatzl, brutisso, mgerdin, twisti, kvn ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSetSummary.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/utilities/growableArray.hpp Changeset: 8088d93a63e6 Author: brutisso Date: 2013-08-15 13:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8088d93a63e6 Merge Changeset: 9720d338b1d5 Author: brutisso Date: 2013-08-16 11:26 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/9720d338b1d5 8023145: G1: G1CollectedHeap::mark_strong_code_roots() needs to handle ParallelGCThreads=0 Reviewed-by: stefank, mgerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: d0afbee540e0 Author: stefank Date: 2013-08-19 13:44 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/d0afbee540e0 8023227: Enhance layout_helper_log2_element_size assert Reviewed-by: mgerdin, jmasa ! src/share/vm/oops/klass.hpp Changeset: 422920730903 Author: ehelin Date: 2013-08-19 18:17 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/422920730903 8023219: NPG: MetaspaceMemoryPool should report statistics for all of metaspace Reviewed-by: stefank, sjohanss ! src/share/vm/services/memoryPool.cpp Changeset: 57600c4aeabe Author: jmasa Date: 2013-08-19 08:58 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/57600c4aeabe Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 31f220c1f789 Author: jmasa Date: 2013-08-20 10:02 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/31f220c1f789 Merge Changeset: 61521bd65100 Author: tschatzl Date: 2013-08-21 10:32 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/61521bd65100 8022784: TaskQueue misses minimal documentation and references for analysis Summary: Add appropriate documentation and references to publication to allow easier analysis of the TaskQueue implementation. Reviewed-by: dholmes, ehelin ! src/share/vm/utilities/taskqueue.hpp Changeset: cb9da55b1990 Author: jmasa Date: 2013-08-14 19:52 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cb9da55b1990 8021809: Partitioning based on eden sampling during allocation not reset correctly Reviewed-by: ysr, hiroshi ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: b51aee2dd8bb Author: jmasa Date: 2013-08-22 11:13 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b51aee2dd8bb Merge ! src/share/vm/oops/klass.hpp Changeset: 8009adb44523 Author: jmasa Date: 2013-08-22 14:03 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/8009adb44523 Merge Changeset: c1604d5885a6 Author: amurillo Date: 2013-08-23 03:01 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c1604d5885a6 Merge Changeset: acac3bde66b2 Author: amurillo Date: 2013-08-23 03:01 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/acac3bde66b2 Added tag hs25-b47 for changeset c1604d5885a6 ! .hgtags From alejandro.murillo at oracle.com Fri Aug 23 09:26:49 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 23 Aug 2013 16:26:49 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130823162701.8AF4848B0F@hg.openjdk.java.net> Changeset: c93e0a210e1b Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c93e0a210e1b Added tag jdk8-b104 for changeset 104743074675 ! .hgtags Changeset: c1604d5885a6 Author: amurillo Date: 2013-08-23 03:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c1604d5885a6 Merge Changeset: acac3bde66b2 Author: amurillo Date: 2013-08-23 03:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/acac3bde66b2 Added tag hs25-b47 for changeset c1604d5885a6 ! .hgtags Changeset: 73921c720b94 Author: amurillo Date: 2013-08-23 03:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/73921c720b94 8023635: new hotspot build - hs25-b48 Reviewed-by: jcoomes ! make/hotspot_version From coleen.phillimore at oracle.com Fri Aug 23 10:48:32 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 23 Aug 2013 13:48:32 -0400 Subject: Fwd: RR(S): 8009062 poor performance of JNI AttachCurrentThread after fix for 7017193 In-Reply-To: <5213B5C1.3000705@oracle.com> References: <5213B5C1.3000705@oracle.com> Message-ID: <5217A070.8010303@oracle.com> Dmitry, This looks good. Thank you! Coleen On 8/20/2013 2:30 PM, Dmitry Samersoff wrote: > Hi Everybody, > > Here is webrev of changes I'm about to integrate: > > http://cr.openjdk.java.net/~dsamersoff/8009062/webrev.13/ > > The problem: > > Under Linux stack of main thread is growable, so we have to make sure > that address we plan to put a guard pages to and below is not mapped. > > Historically we find bounds of the stack of main thread by seeking > /proc/self/maps for "[stack]" and parsing this line. > > But after intensive testing we figured out that it's not required to > re-read stack bounds after create_attached_thread() because we are > manually grow stack up to the bounds in create_attached_thread() > > > Solution: > > I use mincore(2) to check whether > the page is mapped or not. Typically mincore(2) is used to check whether > the page is resides in physical memory or not, but this function returns > -1 and set errno to ENOMEM if a region we are asking about contains not > mapped memory. > > Testing: > > Passed jprt, jck and and couple of ute tests. Wrote special regression test. > > -Dmitry > From jon.masamitsu at oracle.com Fri Aug 23 11:58:10 2013 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Fri, 23 Aug 2013 11:58:10 -0700 (PDT) Subject: RFR: 8016155: SIGBUS when running Kitchensink with ParallelScavenge and ParallelOld In-Reply-To: <521755CC.7040303@oracle.com> References: <521755CC.7040303@oracle.com> Message-ID: <5217B0C2.2070606@oracle.com> On 8/23/2013 5:30 AM, Stefan Johansson wrote: > Hi all, > > I would like some reviews on my fix for bug: > http://bugs.sun.com/view_bug.do?bug_id=8016155 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8016155/webrev.00 > > Summary: > On Linux we have a problem that we hit a SIGBUS when one NUMA node > runs out of large pages but the system as a whole has large pages > left. To avoid this we need to ease the requirement on which node the > memory should be allocated on. This can be done by using the memory > policy MPOL_PREFERRED, which prefers a certain node, instead of > MPOL_BIND, which requires a certain node. With your change what happens when the system as a whole runs out of large pages? Jon > > Testing: > To verify the fix I've run Kitchensink as describe in the bug report, > but also done some manual testing. To sanity test performance I've run > SPECjbb2005 with and without UseNUMA before and after the fix and I > haven't seen any problem. I also ran SPECjbb2005 on a system where one > NUMA node has been configured with no large pages while the other has > enough for the test. Without the fix this crashes immediately, but > with the fix the results are sane. > > Thanks, > Stefan From coleen.phillimore at oracle.com Fri Aug 23 12:55:46 2013 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 23 Aug 2013 15:55:46 -0400 Subject: RFR - Changes to address CCC 8014135: Support for statically linked agents In-Reply-To: <5215161B.4090504@oracle.com> References: <51D494E9.2020200@oracle.com> <51F164CF.50307@oracle.com> <51F23AC7.9050004@oracle.com> <51F8114B.2040302@oracle.com> <51FC58FF.6040600@oracle.com> <51FC74D5.70704@oracle.com> <52002372.2030302@oracle.com> <52139F64.2050906@oracle.com> <5213F0F1.4020800@oracle.com> <52141557.3020300@oracle.com> <52150103.1050507@oracle.com> <5215161B.4090504@oracle.com> Message-ID: <5217BE42.7020607@oracle.com> Hi Bill, This last version looks good to me. I went through my comments before and you've addressed all of them. Thanks! What testing did you run with these? Did you run linux/x64 nsk vm.quick.testlist to see if nothing broke in the non-embedded platforms? There are a lot of agent tests in this testset. I assume you tested the static library configuration. Thanks, coleen On 8/21/2013 3:33 PM, BILL PITTORE wrote: > On 8/21/2013 2:03 PM, serguei.spitsyn at oracle.com wrote: >> Bill, >> >> Thumbs up modulo the below comments. >> >> I've noticed a couple of more minor issues. >> Could you, please, make one more clean-up? >> >> src/os/windows/vm/os_windows.cpp >> >> There is still some inconsistency in the lines: >> 5401 // Builds a platform dependent Agent_OnLoad_ function name >> 5411 char* os::build_agent_function_name(const char *sym_name, const char *lib_name, >> 5454 // agent_entry_name == _Agent_OnLoad_libName at XX >> I'm not sure how to make it better but leave it up to you. >> Maybe the line 5454 is Ok as another style is required there. >> >> >> src/share/vm/prims/jvmti.xml >> >> The lines are still too long: 667, 10773, 10776 >> > All set, take a look at > http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.04/ > > bill > >> >> Thanks, >> Serguei >> >> >> On 8/20/13 6:18 PM, BILL PITTORE wrote: >>> Thanks Serguei for the detailed review. I think I captured all the >>> tweaks you mentioned and have new webrevs at: >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.03/ >>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.04/ >>> >>> also you can find the jvmti.html output file at >>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.03/jvmti.html >>> >>> and the javadoc from VirtualMachine.java at: >>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/ >>> >>> bill >>> >>> On 8/20/2013 6:42 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Bill, >>>> >>>> It looks good in general. >>>> >>>> Some minor comments. >>>> >>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java >>>> >>>> The copyright comment is out-of-date >>>> >>>> >>>> || src/os/posix/vm/os_posix.cpp >>>> >>>> symName => sym_name >>>> >>>> src/os/windows/vm/os_windows.cpp >>>> >>>> 5454 //agent_entry_name == _Agent_OnLoad_libName at XX >>>> >>>> Need a space after // >>>> >>>> ||src/share/vm/prims/jvmti.xml >>>> >>>> The copyright comment is out-of-date. >>>> The lines are too long: 520-523, 584, 593, 623, 654, 660, 679, 689. >>>> >>>> src/share/vm/prims/jvmtiExport.cpp >>>> src/share/vm/runtime/arguments.hpp >>>> >>>> No comments >>>> >>>> ||src/share/vm/runtime/os.cpp >>>> >>>> The indentation is incorrect: >>>> 456 const char *syms[], size_t syms_len) { >>>> >>>> The comments are cross-inconsistent (lib_name vs libname): >>>> >>>> 447 * Support for finding Agent_On(Un)Load/Attach<_lib_name> if it exists. >>>> . . . >>>> 449 * Agent_OnLoad_lib_name or Agent_OnAttach_lib_name function to determine if >>>> . . . >>>> 491 // Check for Agent_OnLoad/Attach_libname function >>>> . . . >>>> 498 // Found an entry point like Agent_OnLoad_libname so we have a static agent >>>> >>>> ||src/share/vm/runtime/os.hpp >>>> >>>> 542 // return the handle of this process >>>> 543 static void* get_default_process_handle(); >>>> 544 >>>> 545 // Check for static linked agent library >>>> 546 static bool find_builtin_agent(AgentLibrary *agent_lib, const char *syms[], >>>> 547 size_t syms_len); >>>> 548 >>>> 549 // Find agent entry point >>>> 550 static void *find_agent_function(AgentLibrary *agent_lib, bool check_lib, >>>> 551 const char *syms[], size_t syms_len); The comment at the line #542 should start from capital letter. >>>> Wrong indentation at the lines: #547, #551. >>>> >>>> ||src/share/vm/runtime/thread.cpp >>>> >>>> Wrong indentation: >>>> 3748 on_load_entry = CAST_TO_FN_PTR(OnLoadEntry_t, os::find_agent_function(agent, >>>> 3749 false, >>>> 3750 on_load_symbols, >>>> 3751 num_symbol_entries)); >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 8/20/13 9:55 AM, bill.pittore at oracle.com wrote: >>>>> I've updated the hotspot and jdk webrevs based on Coleen's and >>>>> Serguei's comments. >>>>> >>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.03/ >>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.02/ >>>>> >>>>> thanks, >>>>> bill >>>>> >>>>> >>>>> On 8/19/2013 1:13 PM, BILL PITTORE wrote: >>>>>> On 8/5/2013 6:13 PM, Coleen Phillimore wrote: >>>>>>> >>>>>>> Hi Bill, I have some high level comments and other comments. >>>>>>> This wasn't as easy to review as Bob promised me! >>>>>> :-P >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/src/share/classes/com/sun/tools/attach/VirtualMachine.java.udiff.html >>>>>>> >>>>>>> paramter (typo - two instances) >>>>>>> >>>>>>> * @throws AgentInitializationException >>>>>>> - * If the Agent_OnAttach function >>>>>>> returns an error >>>>>>> + * If the Agent_OnAttach[_L] function >>>>>>> returns an error. >>>>>>> + * an error. >>>>>>> * >>>>>> Fixed. >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/os/posix/vm/os_posix.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> nameLen, prefixLen, suffixLen - the JVM coding convention >>>>>>> (unlike Java) is to have variable names lower case and separated >>>>>>> by a _ (not camelcase). Same for all the new code here >>>>>>> buildAgentFunctionName. >>>>>> Fixed all names. Original code came from JDK which is why I had >>>>>> this scheme. >>>>>>> >>>>>>> Can you put a function above this function to say what it does? >>>>>>> So once it's code reviewed, we can quickly know what it does >>>>>>> without having to study this again - ie. Is name something like >>>>>>> libxxx.so and you're trying to extract lib and .so from it? >>>>>>> There's no verification of this at lines 286 and 287 but the >>>>>>> code is handling the case of other sorts of unexpected input (ie >>>>>>> line 283). Why don't you strip the lib and the .so if >>>>>>> !is_absolute_path? >>>>>> Added a comment to the above function to describe what's going >>>>>> on. For absolute path case, the lib_name is something like >>>>>> /a/b/libL.so so we need to strip off the path, the 'lib' prefix >>>>>> and the '.so' suffix to get the base name. >>>>>>> 291 agentEntryName = NEW_C_HEAP_ARRAY(char, len, mtThread); >>>>>>> 292 if (agentEntryName == NULL) { >>>>>>> 293 return NULL; >>>>>>> 294 } >>>>>>> If NEW_C_HEAP_ARRAY fails it terminates the JVM. I think you >>>>>>> might want this function instead NEW_C_HEAP_ARRAY_RETURN_NULL if >>>>>>> there's a reasonable recovery possible. >>>>>>> >>>>>> Ok, changed it to the above. >>>>>>> os_windows.cpp >>>>>>> >>>>>>> Same comments as above. Also: >>>>>>> >>>>>>> 5432 strncat(agentEntryName, name, nameLen); >>>>>>> 5433 strcat(agentEntryName, p); >>>>>>> 5434 //agentEntryName == _Agent_OnLoad_libName at 12 >>>>>>> 5435 } else { >>>>>>> You could say why 12 but shouldn't it be the length of the >>>>>>> resulting symbol instead and not 12? >>>>>> Changed it to '@XX'. It's really the length of the arguments >>>>>> which could change in the future, so XX should be fine. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/os.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> findAgentFunction - same comment about the coding conventions. >>>>>>> functions and variables are lower case with underscores. Class >>>>>>> names are CamelCase. It would be convenient if the jvm code >>>>>>> used the java coding convention but the rest of it doesn't so >>>>>>> this new code is inconsistent. This is hard to follow as it is! >>>>>>> >>>>>> Fixed. >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/runtime/thread.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> 3826 size_t num_symbol_entries = sizeof(on_unload_symbols) / >>>>>>> sizeof(char*); >>>>>>> Why not use ARRAY_SIZE macro? >>>>>>> >>>>>> Fixed. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/src/share/vm/prims/jvmtiExport.cpp.frames.html >>>>>>> >>>>>>> >>>>>>> 2208 // Check for builtin agent. If not then if the path is >>>>>>> absolute we attempt >>>>>>> 2209 // to load the library. Otherwise we try to load it from >>>>>>> the standard >>>>>>> 2210 // dll directory. >>>>>>> I think you are missing the word "found" in this sentence. You >>>>>>> are using builtin agent to mean agent defined in a statically >>>>>>> linked library, I believe. Can you say that instead? Builtin >>>>>>> means that the jvm knows about it and implements it but in this >>>>>>> case it doesn't. >>>>>> Re-worded this to be more explicit about statically linked in >>>>>>> >>>>>>> Maybe find_statically_linked_agent() would be a better name for >>>>>>> this function? >>>>>> I think builtin came from when we did original JNI builitin >>>>>> libraries. It might be documented as such in the JEP or CCC. >>>>>>> >>>>>>> Is the is_valid() function really mean has_been_loaded()? >>>>>>> 2236 if (agentLib->valid()) { >>>>>> Yes, either it was found statically linked into the executable or >>>>>> it was successfully loaded as a shared lib. >>>>>>> >>>>>>> >>>>>>> Did you run the Internal NSK vm.quick.testlist tests on this to >>>>>>> verify that nothing breaks? There are a lot of tests with >>>>>>> different agents and combinations in that suite and it >>>>>>> frequently holds some surprises in this area so best to run it >>>>>>> first. Let me know if you need help. >>>>>> Ran the vm/nsk tests using UTE. Also we have some new test code >>>>>> to test the statically linked agent functionality. >>>>>> >>>>>> Thanks so much for the excellent review. >>>>>> I'll update the webrev as soon as I rebuild and test. >>>>>> >>>>>> bill >>>>>> >>>>>>> >>>>>>> Coleen >>>>>>> >>>>>>> On 08/05/2013 10:41 AM, Bob Vandette wrote: >>>>>>>> On Aug 2, 2013, at 11:11 PM, Bill Pittore wrote: >>>>>>>> >>>>>>>>> On 8/2/2013 9:12 PM,serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Bill, >>>>>>>>>> >>>>>>>>>> A couple of more questions. >>>>>>>>>> >>>>>>>>>> webrev.01/jvmti.html >>>>>>>>>> >>>>>>>>>> An agent L whose image has been combined with the VM *is >>>>>>>>>> defined* as /statically linked/ >>>>>>>>>> if and only if the agent exports a function called >>>>>>>>>> Agent_OnLoad_L. >>>>>>>>>> >>>>>>>>>> A question to the above. >>>>>>>>>> Are we going to allow to link a library dynamically if it >>>>>>>>>> exports both >>>>>>>>>> the Agent_OnLoad and Agent_OnLoad_L functions? >>>>>>>>>> It can be convenient if a library exports both Agent_OnLoad >>>>>>>>>> and Agent_OnLoad_L >>>>>>>>>> as it can be linked statically or dynamically depending on >>>>>>>>>> the need without changes. >>>>>>>>>> >>>>>>>>> It would be nice but the problem is that you could only link >>>>>>>>> one agent into the VM if it exported Agent_OnLoad. Otherwise >>>>>>>>> there would be a symbol collision with the second agent you >>>>>>>>> linked in that also had Agent_OnLoad. As an agent developer >>>>>>>>> you will have to select one or the other at build time, either >>>>>>>>> statically linked in or dynamic. >>>>>>>>>> You already added the following statement to the JVMTI spec: >>>>>>>>>> If a /statically linked/ agent L exports a function called >>>>>>>>>> Agent_OnLoad_L and >>>>>>>>>> a function called Agent_OnLoad, the Agent_OnLoad function >>>>>>>>>> will be ignored. >>>>>>>>>> >>>>>>>>>> Could we say it in a shorter form?: >>>>>>>>>> If a /statically linked/ agent L exports a function called >>>>>>>>>> Agent_OnLoad, >>>>>>>>>> the Agent_OnLoad function will be ignored. >>>>>>>>> I believe I copied this from JNI static linking JEP. If so, >>>>>>>>> I'll probably leave it as is just for consistency with JNI >>>>>>>>> static spec. JVM TI static linking spec is closely related to >>>>>>>>> JNI static linking spec. >>>>>>>>>> In this context would it be reasonable to add another statement: >>>>>>>>>> If a /dynamically linked/ agent L exports a function called >>>>>>>>>> Agent_OnLoad_L, >>>>>>>>>> the Agent_OnLoad_L function will be ignored. >>>>>>>>>> >>>>>>>> I'd rather leave this undefined since the behavior is very >>>>>>>> platform specific. >>>>>>>> The way we determine if a library is statically linked is by >>>>>>>> the presence of the Agent_OnLoad_L function. >>>>>>>> If this function exists in a dynamically linked library, it >>>>>>>> will be treated as a static library if by some chance >>>>>>>> it's attempted to be loaded twice, since the symbol will may be >>>>>>>> visible in the running process. >>>>>>>> >>>>>>>> Bob. >>>>>>>> >>>>>>>> >>>>>>>>>> The same questions apply to the Agent_OnAttach and >>>>>>>>>> Agent_OnAttach_L entry points. >>>>>>>>>> >>>>>>>>> I'm out on vacation for a couple of weeks so I'll leave it up >>>>>>>>> to Bob V. and yourself if you guys want to hash out >>>>>>>>> better/different wording. >>>>>>>>> >>>>>>>>> bill >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/30/13 12:17 PM,bill.pittore at oracle.com wrote: >>>>>>>>>>> Thanks Serguei for the comments. Some comments inline. I >>>>>>>>>>> updated the webrevs at >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.02/ >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/javadoc/index.html >>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.01/jvmti.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 7/26/2013 5:00 AM,serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Hi Bill, >>>>>>>>>>>> >>>>>>>>>>>> Sorry for the big delay. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> src/share/classes/com/sun/tools/attach/VirtualMachine.java: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'm suggesting to use the reference >>>>>>>>>>>> *Agent_OnAttach[_L]**||* even more consistently. >>>>>>>>>>>> (If, in some cases, you prefer the longer form to underline >>>>>>>>>>>> the difference between >>>>>>>>>>>> dynamically and statically linked libraries then feel free >>>>>>>>>>>> to leave it as it is.) >>>>>>>>>>>> >>>>>>>>>>>> It would simplify the following fragments: >>>>>>>>>>>> >>>>>>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>>>>>> Agent_OnAttach function >>>>>>>>>>>> 305 * or, for a statically linked agent named 'L', the >>>>>>>>>>>> Agent_OnAttach_L function >>>>>>>>>>>> ==> >>>>>>>>>>>> >>>>>>>>>>>> 304 * It then causes the target VM to invoke the >>>>>>>>>>>> Agent_OnAttach[_L] function >>>>>>>>>>>> >>>>>>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>>>>>> Agent_OnAttach >>>>>>>>>>>> 410 * function or, for a statically linked agent named >>>>>>>>>>>> 'L', the >>>>>>>>>>>> 411 * Agent_OnAttach_L function as >>>>>>>>>>>> specified in the >>>>>>>>>>>> ==> >>>>>>>>>>>> 409 * It then causes the target VM to invoke the >>>>>>>>>>>> Agent_OnAttach[_L] >>>>>>>>>>>> 410 * function as specified in the >>>>>>>>>>>> >>>>>>>>>>> I left the above as is since it's part of the method >>>>>>>>>>> description. The following fragments below I simplified as >>>>>>>>>>> you suggested. >>>>>>>>>>> >>>>>>>>>>>> the following 4 identical fragments: >>>>>>>>>>>> >>>>>>>>>>>> 341 * If the Agent_OnAttach >>>>>>>>>>>> function returns an error >>>>>>>>>>>> 342 * or, for a statically linked agent >>>>>>>>>>>> named 'L', if the >>>>>>>>>>>> 343 * Agent_OnAttach_L function returns >>>>>>>>>>>> 344 * an error. >>>>>>>>>>>> 375 * If the Agent_OnAttach >>>>>>>>>>>> function returns an error >>>>>>>>>>>> 376 * or, for a statically linked agent >>>>>>>>>>>> named 'L', if the >>>>>>>>>>>> 377 * Agent_OnAttach_L function returns >>>>>>>>>>>> 378 * an error. >>>>>>>>>>>> 442 * If the Agent_OnAttach >>>>>>>>>>>> function returns an error >>>>>>>>>>>> 443 * or, for a statically linked agent >>>>>>>>>>>> named 'L', if the >>>>>>>>>>>> 444 * Agent_OnAttach_L function returns >>>>>>>>>>>> an error >>>>>>>>>>>> 475 * If the Agent_OnAttach >>>>>>>>>>>> function returns an error >>>>>>>>>>>> 476 * or, for a statically linked agent >>>>>>>>>>>> named 'L', if the >>>>>>>>>>>> 477 * Agent_OnAttach_L function returns >>>>>>>>>>>> 478 * an error. >>>>>>>>>>>> ==> >>>>>>>>>>>> >>>>>>>>>>>> 336 * If the Agent_OnAttach[_L] >>>>>>>>>>>> function returns an error. >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/prims/jvmti.xml >>>>>>>>>>>> >>>>>>>>>>>> Lines 442-462: many extra

's. The fragment does not >>>>>>>>>>>> look well. >>>>>>>>>>>> I'd suggest to remove most of them. >>>>>>>>>>>> Also, these lines are too long. Could you make them >>>>>>>>>>>> shorter, please? >>>>>>>>>>>> The same is applied to other long new lines in this file. >>>>>>>>>>> Cleaned this up a bit. >>>>>>>>>>>> Lines 490-491, 502-503, 505-506: >>>>>>>>>>>> The same sentence is repeated 3 times: "the agent >>>>>>>>>>>> library may be statically linked ..." >>>>>>>>>>>> >>>>>>>>>>>> 490 Note that the agent library may be statically >>>>>>>>>>>> linked into the executable >>>>>>>>>>>> 491 in which case no actual loading takes place. >>>>>>>>>>> Fixed. >>>>>>>>>>>> 501 -agentpath:c:\myLibs\foo.dll=opt1,opt2 is >>>>>>>>>>>> specified, the VM will attempt to >>>>>>>>>>>> 502 load the shared library >>>>>>>>>>>> c:\myLibs\foo.dll. As mentioned above, the >>>>>>>>>>>> agent library may be statically linked into the executable >>>>>>>>>>>> 503 in which case no actual loading takes place >>>>>>>>>>>> >>>>>>>>>>>> 505 Note that the agent library may be statically >>>>>>>>>>>> linked into the executable >>>>>>>>>>>> 506 in which case no actual loading takes place. >>>>>>>>>>>> >>>>>>>>>>> Tweaked the above a bit to make it less wordy. >>>>>>>>>>> >>>>>>>>>>>> Lines 677-678: The dot is missed at the end of line 677: >>>>>>>>>>>> >>>>>>>>>>>> 677 and enabled the event >>>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>>> src/os/posix/vm/os_posix.cpp >>>>>>>>>>>> >>>>>>>>>>>> - no comments >>>>>>>>>>>> >>>>>>>>>>>> src/os/windows/vm/os_windows.cpp >>>>>>>>>>>> >>>>>>>>>>>> - no comments >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/prims/jvmtiExport.cpp >>>>>>>>>>>> >>>>>>>>>>>> - no comments >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/runtime/arguments.hpp >>>>>>>>>>>> >>>>>>>>>>>> - no comments >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/runtime/os.cpp >>>>>>>>>>>> >>>>>>>>>>>> Space is missed after the 'if': >>>>>>>>>>>> 471 if(entryName != NULL) { >>>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>>> Extra space after the '*': >>>>>>>>>>>> 483 void * saveHandle; >>>>>>>>>>>> >>>>>>>>>>> Fixed. >>>>>>>>>>>> src/share/vm/runtime/os.hpp >>>>>>>>>>>> >>>>>>>>>>>> - no comments >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>> >>>>>>>>>>>> The line has been removed: >>>>>>>>>>>> 3866 break; >>>>>>>>>>>> >>>>>>>>>>> Correct, the inner for loop was removed so no need for the >>>>>>>>>>> break; >>>>>>>>>>>> I'm still in process of reading the code. >>>>>>>>>>>> Another pass is needed to make sure that nothing is missed. >>>>>>>>>>>> But in general, the code quality is pretty good. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 7/25/13 10:47 AM,bill.pittore at oracle.com wrote: >>>>>>>>>>>>> Still need an official reviewer for the hotspot changes >>>>>>>>>>>>> for statically linked agents. >>>>>>>>>>>>> >>>>>>>>>>>>> thanks, >>>>>>>>>>>>> bill >>>>>>>>>>>>> >>>>>>>>>>>>>> These changes address bug 8014135 which adds support for >>>>>>>>>>>>>> statically linked agents in the VM. This is a followup to >>>>>>>>>>>>>> the recent JNI spec changes that addressed statically >>>>>>>>>>>>>> linked JNI libraries( 8005716). >>>>>>>>>>>>>> The JEP for this change is the same JEP as the JNI changes: >>>>>>>>>>>>>> http://openjdk.java.net/jeps/178 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Webrevs are here: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/jdk/webrev.00/ >>>>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The changes to jvmti.xml can also be seen in the output >>>>>>>>>>>>>> file that I placed here: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~bpittore/8014135/hotspot/webrev.00/jvmti.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> bill >>>>>>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > From daniel.daugherty at oracle.com Fri Aug 23 15:51:05 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 23 Aug 2013 16:51:05 -0600 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: <5215F486.6050105@oracle.com> References: <51D3065C.6090401@oracle.com> <5215F486.6050105@oracle.com> Message-ID: <5217E759.1070206@oracle.com> On 8/22/13 5:22 AM, Stefan Karlsson wrote: > http://cr.openjdk.java.net/~stefank/8007074/webrev.01/ Thumbs up. src/share/vm/utilities/globalDefinitions.hpp No comments. src/share/vm/runtime/globals.hpp src/os/linux/vm/globals_linux.hpp No comments on either. src/share/vm/services/memTracker.hpp No comments. src/share/vm/memory/universe.hpp No comments. src/share/vm/memory/universe.cpp line 752: assert(is_ptr_aligned((char*)base, alignment), ""); How about "Must be" instead of empty? (like above) src/share/vm/runtime/virtualspace.hpp No comments. src/share/vm/runtime/virtualspace.cpp No comments. src/share/vm/prims/jni.cpp No comments. src/share/vm/memory/metaspace.cpp No comments. src/share/vm/runtime/os.hpp nit line 331: is now longer than 80 cols src/share/vm/memory/collectorPolicy.cpp No comments. src/share/vm/memory/genCollectedHeap.cpp No comments. src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp No comments. src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp No comments. src/os/bsd/vm/os_bsd.cpp No comments. src/os/linux/vm/os_linux.hpp No comments. src/os/linux/vm/os_linux.cpp line 3280: size_t default_page_size = (size_t)Linux::page_size(); Seems like this var could still be "const". Why did you change it to non-const? line 3610: // that was supposed to be committed will loose the old reservation typo: "loose" -> "lose" src/os/solaris/vm/os_solaris.cpp No comments. src/os/windows/vm/os_windows.cpp Any plans to add tests for reserve_memory_special() in the future? Dan > > Hi all, > > The original patch didn't make it in time for the hs24 release. So, > please review this patch that's now based on hs25 (JDK8) instead of hs24. > > The main difference between the two patches is the heap setup code, > which is different because of the permgen removal. > > thanks, > StefanK > > On 07/02/2013 06:57 PM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8007074/webrev.00/ >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007074 >> >> The default way of using Large Pages in HotSpot on Linux >> (UseHugeTLBFS) is broken. This is causing a number of crashes in >> different subsystems of the JVM. >> >> >> Bug Description >> =============== >> >> The main reason for this bug is that mmap(addr, size, ... >> MAP_FIXED|MAP_HUGETLB ...) will remove the previous mapping at [addr, >> addr+size) when we run out of large pages on Linux. >> >> This affects different parts of the JVM, but the most obvious is the >> allocation of the Java heap: >> >> When the JVM starts it reserves a memory area for the entire Java >> heap. We use mmap(...MAP_NORESERVE...) to reserve a contiguous chunk >> of memory that no other >> subsystem of the JVM, or Java program, will be allowed to mmap into. >> >> The reservation of the memory only reflects the maximum possible heap >> size, but often a smaller heap size is used if the memory pressure is >> low. The part of >> the heap that is actually used is committed with >> mmap(...MAP_FIXED...). When the heap is growing we commit a >> consecutive chunk of memory after the >> previously committed memory. We rely on the fact that no other thread >> will mmap into the reserved memory area for the Java heap. >> >> The actual committing of the memory is done by first trying to >> allocate large pages with mmap(...MAP_FIXED|MAP_HUGETLB...), and if >> that fails we call mmap with the same parameters but without the >> large pages flag (MAP_HUGETLB). >> >> Just after we have failed to mmap large pages and before the small >> pages have been mmapped, there's an unmapped memory region in the >> middle of the Java heap, where other threads might mmap into. When >> that happens we get memory trashing and crashes. >> >> >> Large Pages in HotSpot - on Linux >> ================================= >> >> Currently, before the bug fix, HotSpot supports three ways of >> allocating large pages on Linux. >> 1) -XX:+UseSHM - Commits the large pages upfront when the memory is >> reserved. >> >> 2) -XX:+UseHugeTLBFS - This is the broken implementation. It's also >> the default way large pages are allocated. If the OS is correctly >> configured, we get these kind of large pages for three different >> reasons: >> 2.1) The user has not specified any large pages flags >> 2.2) The user has specified -XX:+UseLargePages >> 2.3) The user has specified -XX:+UseHugeTLBFS >> >> 3) Transparent Huge Pages - is supported on recent Linux Kernels. The >> user can choose to configure the OS to: >> 3.1) completely handle the allocation of large pages, or >> 3.2) let the JVM advise where it would be good to allocate large >> pages. There exist code for this today, that is guarded by the (2) >> -XX:+UseHugeTLBFS flag. >> >> >> The Proposed Patch >> ================== >> >> 4) Create a new flag -XX:+UseTransparentHugePages, and move the >> transparent huge pages advise in (3.2) out from the (2) >> -XX:+UseHugeTLBFS code. >> >> 5) Make -XX:+UseTransparentHugePages the default way to allocate >> large pages if the OS supports them. It will be the only kind of >> large pages we'll use if the user has not specified any large pages >> flags. >> >> 6) Change the order of how we choose the kind of large pages when >> -XX:+UseLargePages has been specified. It used to be UseHugeTLBFS >> then UseSHM, now it's UseTransparentHugePages, then UseHugeTLBFS, >> then UseSHM. >> >> 7) Implement a workaround fix for the (2) -XX:+UseHugeTLBFS >> implementation. With the fix the large pages are committed upfront >> when they are reserved. It's mostly the same way we do it for the >> older (1) -XX:+UseSHM large pages. This change will fix the bug, but >> has a couple of drawbacks: >> 7.1) We have to allocate the entire large pages memory area when it >> is reserved instead of when parts of it are committed. >> 7.2) We can't dynamically shrink or grow the used memory in the large >> pages areas. >> If these restrictions are not suitable for the user, then (3) >> -XX:+UseTransparentHugePages could be used instead. >> >> 8) Ignore -XX:LargePageSizeInBytes on Linux since the OS doesn't >> support multiple large page sizes and both the old code and new code >> is broken if the user is allowed to set it to some other value then >> the OS chosen value. Warn if the user specifies a value different >> than the OS default value. >> >> >> Testing >> ======= >> >> New unit tests have been added. These can be run in a non-product >> build with: >> java -XX:+ExecuteInternalVMTests -XX:+VerboseInternalVMTests > pages flags> -version >> >> unit tests: with and without large pages on Linux, Windows, Solaris, >> x86, x64, sparcv9. >> jprt: default >> jprt: -XX:+UseLargePages >> jprt: -XX:+UseLargePages -XX:-UseCompressedOops >> vm.quick.testlist, vm.pcl.testlist, vm.gc.testlist: multiple >> platforms, with large pages on all major GCs with and without >> compressed oops. >> SPECjbb2005 performance runs: on Linux x64 with -XX:+UseHugeTLBFS >> before and after the patch. >> Kitchensink: 3 days on Linux x64 >> >> >> thanks, >> StefanK > From stefan.karlsson at oracle.com Fri Aug 23 22:43:12 2013 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Sat, 24 Aug 2013 07:43:12 +0200 Subject: Review request (hs24): 8007074: SIGSEGV at ParMarkBitMap::verify_clear() In-Reply-To: <5217E759.1070206@oracle.com> References: <51D3065C.6090401@oracle.com> <5215F486.6050105@oracle.com> <5217E759.1070206@oracle.com> Message-ID: <521847F0.6030108@oracle.com> On 2013-08-24 00:51, Daniel D. Daugherty wrote: > On 8/22/13 5:22 AM, Stefan Karlsson wrote: >> http://cr.openjdk.java.net/~stefank/8007074/webrev.01/ > > Thumbs up. Thanks! > > > src/share/vm/utilities/globalDefinitions.hpp > No comments. > > src/share/vm/runtime/globals.hpp > src/os/linux/vm/globals_linux.hpp > No comments on either. > > src/share/vm/services/memTracker.hpp > No comments. > > src/share/vm/memory/universe.hpp > No comments. > > src/share/vm/memory/universe.cpp > line 752: assert(is_ptr_aligned((char*)base, alignment), ""); > How about "Must be" instead of empty? (like above) Will fix. > > src/share/vm/runtime/virtualspace.hpp > No comments. > > src/share/vm/runtime/virtualspace.cpp > No comments. > > src/share/vm/prims/jni.cpp > No comments. > > src/share/vm/memory/metaspace.cpp > No comments. > > src/share/vm/runtime/os.hpp > nit line 331: is now longer than 80 cols Will break up the line. > > src/share/vm/memory/collectorPolicy.cpp > No comments. > > src/share/vm/memory/genCollectedHeap.cpp > No comments. > > src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > No comments. > > src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp > No comments. > > src/os/bsd/vm/os_bsd.cpp > No comments. > > src/os/linux/vm/os_linux.hpp > No comments. > > src/os/linux/vm/os_linux.cpp > line 3280: size_t default_page_size = (size_t)Linux::page_size(); > Seems like this var could still be "const". Why did you > change it to non-const? No reason. I'll add back the const. > > line 3610: // that was supposed to be committed will loose the old > reservation > typo: "loose" -> "lose" Will fix. > > > src/os/solaris/vm/os_solaris.cpp > No comments. > > src/os/windows/vm/os_windows.cpp > Any plans to add tests for reserve_memory_special() in the future? I'll make sure to add that item to the large pages testing plan. thanks, StefanK > > Dan > > >> >> Hi all, >> >> The original patch didn't make it in time for the hs24 release. So, >> please review this patch that's now based on hs25 (JDK8) instead of >> hs24. >> >> The main difference between the two patches is the heap setup code, >> which is different because of the permgen removal. >> >> thanks, >> StefanK >> >> On 07/02/2013 06:57 PM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/8007074/webrev.00/ >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007074 >>> >>> The default way of using Large Pages in HotSpot on Linux >>> (UseHugeTLBFS) is broken. This is causing a number of crashes in >>> different subsystems of the JVM. >>> >>> >>> Bug Description >>> =============== >>> >>> The main reason for this bug is that mmap(addr, size, ... >>> MAP_FIXED|MAP_HUGETLB ...) will remove the previous mapping at >>> [addr, addr+size) when we run out of large pages on Linux. >>> >>> This affects different parts of the JVM, but the most obvious is the >>> allocation of the Java heap: >>> >>> When the JVM starts it reserves a memory area for the entire Java >>> heap. We use mmap(...MAP_NORESERVE...) to reserve a contiguous chunk >>> of memory that no other >>> subsystem of the JVM, or Java program, will be allowed to mmap into. >>> >>> The reservation of the memory only reflects the maximum possible >>> heap size, but often a smaller heap size is used if the memory >>> pressure is low. The part of >>> the heap that is actually used is committed with >>> mmap(...MAP_FIXED...). When the heap is growing we commit a >>> consecutive chunk of memory after the >>> previously committed memory. We rely on the fact that no other >>> thread will mmap into the reserved memory area for the Java heap. >>> >>> The actual committing of the memory is done by first trying to >>> allocate large pages with mmap(...MAP_FIXED|MAP_HUGETLB...), and if >>> that fails we call mmap with the same parameters but without the >>> large pages flag (MAP_HUGETLB). >>> >>> Just after we have failed to mmap large pages and before the small >>> pages have been mmapped, there's an unmapped memory region in the >>> middle of the Java heap, where other threads might mmap into. When >>> that happens we get memory trashing and crashes. >>> >>> >>> Large Pages in HotSpot - on Linux >>> ================================= >>> >>> Currently, before the bug fix, HotSpot supports three ways of >>> allocating large pages on Linux. >>> 1) -XX:+UseSHM - Commits the large pages upfront when the memory is >>> reserved. >>> >>> 2) -XX:+UseHugeTLBFS - This is the broken implementation. It's also >>> the default way large pages are allocated. If the OS is correctly >>> configured, we get these kind of large pages for three different >>> reasons: >>> 2.1) The user has not specified any large pages flags >>> 2.2) The user has specified -XX:+UseLargePages >>> 2.3) The user has specified -XX:+UseHugeTLBFS >>> >>> 3) Transparent Huge Pages - is supported on recent Linux Kernels. >>> The user can choose to configure the OS to: >>> 3.1) completely handle the allocation of large pages, or >>> 3.2) let the JVM advise where it would be good to allocate large >>> pages. There exist code for this today, that is guarded by the (2) >>> -XX:+UseHugeTLBFS flag. >>> >>> >>> The Proposed Patch >>> ================== >>> >>> 4) Create a new flag -XX:+UseTransparentHugePages, and move the >>> transparent huge pages advise in (3.2) out from the (2) >>> -XX:+UseHugeTLBFS code. >>> >>> 5) Make -XX:+UseTransparentHugePages the default way to allocate >>> large pages if the OS supports them. It will be the only kind of >>> large pages we'll use if the user has not specified any large pages >>> flags. >>> >>> 6) Change the order of how we choose the kind of large pages when >>> -XX:+UseLargePages has been specified. It used to be UseHugeTLBFS >>> then UseSHM, now it's UseTransparentHugePages, then UseHugeTLBFS, >>> then UseSHM. >>> >>> 7) Implement a workaround fix for the (2) -XX:+UseHugeTLBFS >>> implementation. With the fix the large pages are committed upfront >>> when they are reserved. It's mostly the same way we do it for the >>> older (1) -XX:+UseSHM large pages. This change will fix the bug, but >>> has a couple of drawbacks: >>> 7.1) We have to allocate the entire large pages memory area when it >>> is reserved instead of when parts of it are committed. >>> 7.2) We can't dynamically shrink or grow the used memory in the >>> large pages areas. >>> If these restrictions are not suitable for the user, then (3) >>> -XX:+UseTransparentHugePages could be used instead. >>> >>> 8) Ignore -XX:LargePageSizeInBytes on Linux since the OS doesn't >>> support multiple large page sizes and both the old code and new code >>> is broken if the user is allowed to set it to some other value then >>> the OS chosen value. Warn if the user specifies a value different >>> than the OS default value. >>> >>> >>> Testing >>> ======= >>> >>> New unit tests have been added. These can be run in a non-product >>> build with: >>> java -XX:+ExecuteInternalVMTests -XX:+VerboseInternalVMTests >> pages flags> -version >>> >>> unit tests: with and without large pages on Linux, Windows, Solaris, >>> x86, x64, sparcv9. >>> jprt: default >>> jprt: -XX:+UseLargePages >>> jprt: -XX:+UseLargePages -XX:-UseCompressedOops >>> vm.quick.testlist, vm.pcl.testlist, vm.gc.testlist: multiple >>> platforms, with large pages on all major GCs with and without >>> compressed oops. >>> SPECjbb2005 performance runs: on Linux x64 with -XX:+UseHugeTLBFS >>> before and after the patch. >>> Kitchensink: 3 days on Linux x64 >>> >>> >>> thanks, >>> StefanK >> > From dawid.weiss at gmail.com Sun Aug 25 12:43:30 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Sun, 25 Aug 2013 21:43:30 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> <5212A647.10800@oracle.com> Message-ID: I know why the assertion is hit. I still don't know (and probably won't figure it out) why it is so difficult to reproduce or which optimization leads to it. In short, the following code in ByteSliceReader#readByte: public byte readByte() { assert !eof(); assert upto <= limit; if (upto == limit) { nextSlice(); } return buffer[upto++]; } is inlined in a number of places. If I include: public byte readByte() { assert !eof(); assert upto <= limit; if (upto == limit) { nextSlice(); baz = upto; } return buffer[upto++]; } static int baz; I see a number of assignments to 'baz'. This is because methods like readVInt fork out many conditional branches, as in: public int readVInt() throws IOException { byte b = readByte(); if (b >= 0) return b; int i = b & 0x7F; b = readByte(); i |= (b & 0x7F) << 7; if (b >= 0) return i; b = readByte(); i |= (b & 0x7F) << 14; if (b >= 0) return i; b = readByte(); i |= (b & 0x7F) << 21; if (b >= 0) return i; b = readByte(); // Warning: the next ands use 0x0F / 0xF0 - beware copy/paste errors: i |= (b & 0x0F) << 28; if ((b & 0xF0) == 0) return i; throw new IOException("Invalid vInt detected (too many bits)"); } One of these executions (when upto == limit, and possibly with some other upper condition) leads to missing increment on buffer[upto++] -- upto remains unmodified (but the value at buffer[upto] is returned properly). Because upto is moved to a register in many of those inlined methods I suspect either the register may be incremented and not saved or the increment may be removed due to some local escape analysis magic (that has to be incorrect, obviously). How G1GC interacts with all this (remember, it only happens with G1GC) I have no clue. Anyway, I've tried looking at -XX:+PrintEscapeAnalysis but I couldn't make much sense of it. I also dug into some of the opto assembly branches trying to map them back into the original bytecode, but it's a very long process -- had to map PcDesc manually to the assembly offset, then go to bytecode again. Then I fired visual studio and halted it like Vladimir mentioned: -XX:AbortVMOnException=java.lang.AssertionError -XX:+ShowMessageBoxOnError Once I attach to the halted JVM I "break all" and I see the reported thread's stack trace halted inside ntdll (with the closest JVM frame stopped at get_deopt_original_pc). The frames below it don't seem to make much sense to me -- they don't seem to point to any addresses reported in the compilation log (PcDesc clauses). I'm a complete newbie to this, so I apologize if it's a lame question, but how can I find out which part of the original jitted code this assertion was invoked from? An ideal scenario and what I want to achieve is I'd like to stop on an assertion somewhere in the jitted code and go back to it to follow the execution (so that I can see what code is responsible for the missing increment). I'll need to sync this up (manually or otherwise) with the optoassembly too, otherwise I'll probably lose any remaining hair trying to figure out what's what :) A hint (or any other pointer; RTFM) would be very welcome. Dawid On Tue, Aug 20, 2013 at 11:32 AM, Dawid Weiss wrote: > One follow-up with respect to those encoded integers -- I swapped the > correct and incorrect sequence in my last e-mail, sorry. I then also > added a sysout here: > > @@ -451,6 +453,7 @@ > termFreq = 1; > } else { > termFreq = freq.readVInt(); > + System.err.print("# (tf): " + termFreq + " "); > } > } > > With this the assertion is no longer hit but it shows where the > difference in numbers comes from: > > Correct sequence is: > > # (eof) > # (code): 0 > # (tf): 3 > # (code): 4 > # (tf): 3 > # (code): 2 > # (tf): 5 > # (code): 2 > # (tf): 2 > # (code): 3 > # (code): 5 > # (code): 2 > > And the incorrect, assertion-hit run shows: > > # (eof) > # (code): 0 > # (code): 3 > # (code): 4 > # (code): 3 > # (code): 2 > # (code): 5 > # (code): 2 > # (code): 2 > # (code): 3 > > So there's something odd happening after the first readvint which > returns 0 -- the next number that should be read by: > > termFreq = freq.readVInt(); > > is re-read as the next code. > > Dawid > > > On Tue, Aug 20, 2013 at 11:11 AM, Dawid Weiss wrote: >> Thanks for comments guys. >> >>> It is great that you can build fastdebug VM. I assume that if I give you a >>> patch to try you can also build with it. >> >> Yes, absolutely. >> >>> First, you can run with next options and then send zipped output (related >>> part before the method compilation and optoassembler output, don't use hsdis >>> for that) and hs_err file when test fails: >> >> I did that. Used the options you requested -- a full log of all I did >> is included in the ZIP file here: >> http://www.cs.put.poznan.pl/dweiss/tmp/debug-files.zip >> >> Cat debug-files\debug-log.txt. There are several runs included in that >> ZIP file, in short: >> >> - jdk18-fastdebug, b102, full run (no abort on assertion, explained in >> debug-log.txt): >> 001-no-abort-on-assertion >> 002-no-abort-on-assertion >> >> - jdk18-fastdebug, b102, abort on assertion (includes mem dumps) >> 003-with-abort-on-assertion >> 004-with-abort-on-assertion >> >> - jdk18-fastdebug, hsx tip, abort on assertion (includes mem dumps) >> 005-hsx-tip >> 006-hsx-tip >> >> - jdk18-fastdebug, hsx tip, excluded readvint method inlining (passed >> build, so only compilation logs available). >> 007-excluded-readvint >> >>> Looking on java code in FreqProxTermsWriterPerField::flush() and based on >>> LUCENE-5168 report generated code somehow missed EOF check. Am I right? This >>> is why the Assert is thrown? >> >> It's not the only method it trips on. Depending on the seed the >> problem shows up in different places. For the dumps I included the >> issue seems to be here: >> >>> } else { >>> final int code = freq.readVInt(); >>> if (!readTermFreq) { >>> docID += code; >>> termFreq = -1; >> >> If I add sysouts as in: >> >> Index: core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >> =================================================================== >> --- core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >> (revision 1512807) >> +++ core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >> (working copy) >> @@ -427,6 +427,7 @@ >> //System.out.println(" cycle"); >> final int termFreq; >> if (freq.eof()) { >> + System.err.print("# (eof)"); >> if (postings.lastDocCodes[termID] != -1) { >> // Return last doc >> docID = postings.lastDocIDs[termID]; >> @@ -442,6 +443,7 @@ >> } >> } else { >> final int code = freq.readVInt(); >> + System.err.print("# (code): " + code + " "); >> if (!readTermFreq) { >> docID += code; >> termFreq = -1; >> >> then for a constant seed you'll get an identical sequence of values. >> Once the assertion hits though, the sequence deviates. Comparing a >> passing run (excluding readvint) and a failing run I get a lot of >> initial aligned outputs and then a deviation: >> >> (correct run): >> # (eof) >> # (eof) >> # (eof) >> # (code): 0 >> # (code): 3 >> # (code): 4 >> # (code): 3 >> >> (incorrect run): >> # (eof) >> # (eof) >> # (eof) >> # (code): 0 >> # (code): 4 <- wtf? >> # (code): 2 >> # (code): 2 >> >> How can a variable encoded integer be misinterpreted from 3 to 4 is >> beyond me, sorry. But it's not an EOF condition I think, at least the >> deviation happens where the original run had was entering (code) >> branch. >> >>> Could you also send latest version of FreqProxTermsWriterPerField.java you >>> are testing? >> >> I'm testing against a fixed branch (the info is included in debug-log.txt). >> >> If there's anything else I can do, let me know. I'm also curious how >> you approach debugging this thing. It may be time-based so I don't >> think it'll reproduce on your machine out of the box, but who knows. >> All I know is that, for example, if you add one more sysout before the >> while loop it suddenly stops reproducing so probably something gets >> compiled differently... Wild :) >> >> Dawid From david.holmes at oracle.com Sun Aug 25 18:45:46 2013 From: david.holmes at oracle.com (David Holmes) Date: Mon, 26 Aug 2013 11:45:46 +1000 Subject: RFR: 8006164 [TESTBUG] compact profile hotspot test issues Message-ID: <521AB34A.8020801@oracle.com> This change introduces the TEST.groups file to allow jtreg to run regression tests by groups - where the groups are defined to support testing of compact profiles and the minimal VM. webrev: http://cr.openjdk.java.net/~dholmes/8006164/webrev/ The primary groups are: - jdk - jre - compact3 - compact2 - compact2_minimal - compact1 - compact1_minimal The minimal VM is only supported on compact1 and compact2. To select a group of tests you use : Eg to run only those tests that can run on compact1 use: jtreg :compact1 Of course you still need to point jtreg at the right kind of runtime image (and give it a full JDK as the compile-jdk!); and if testing the minimal VM you need to tell jtreg to select it using -javaoptions:-minimal The full jtreg group facility is only available in the most recent jtreg builds, so you will need to grab the latest nightly build, or latest sources. It is expected that these group definitions will need some tweaking. So far testing has been limited to linux, but we want to get this in ASAP to extend the testing. Note: once this is in place, anyone writing regression tests will need to be aware of whether that test is limited to certain profiles and update the group file accordingly. Sometimes it is not the item being tested that determines the minimum needed profile, but the test infrastructure eg if it uses XML. The changeset will be pushed via hotspot-embas that is what is used for profile testing. Thanks, David From stefan.johansson at oracle.com Mon Aug 26 04:40:11 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 26 Aug 2013 13:40:11 +0200 Subject: RFR: 8016155: SIGBUS when running Kitchensink with ParallelScavenge and ParallelOld In-Reply-To: <5217B0C2.2070606@oracle.com> References: <521755CC.7040303@oracle.com> <5217B0C2.2070606@oracle.com> Message-ID: <521B3E9B.7000902@oracle.com> On 2013-08-23 20:58, Jon Masamitsu wrote: > > On 8/23/2013 5:30 AM, Stefan Johansson wrote: >> Hi all, >> >> I would like some reviews on my fix for bug: >> http://bugs.sun.com/view_bug.do?bug_id=8016155 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8016155/webrev.00 >> >> Summary: >> On Linux we have a problem that we hit a SIGBUS when one NUMA node >> runs out of large pages but the system as a whole has large pages >> left. To avoid this we need to ease the requirement on which node the >> memory should be allocated on. This can be done by using the memory >> policy MPOL_PREFERRED, which prefers a certain node, instead of >> MPOL_BIND, which requires a certain node. > > With your change what happens when the system as a whole > runs out of large pages? The change doesn't do anything specific for large pages it just sets the memory policy to MPOL_PREFERRED to guarantee that we don't forcefully use a NUMA node that can't back the given mapping. If we run out of large pages this will still be handled in the same way, we prefer that the memory is allocated on a given NUMA node, but if it isn't possible we'll use another. I've verified that this is actually what happens by running SPEPjbb with an increasing heap and quite few large pages configured on the system. When the large pages are all used, we fall back on using regular sized pages and every thing runs along just fine. Thanks for highlighting this case, Jon. Stefan > > Jon > >> >> Testing: >> To verify the fix I've run Kitchensink as describe in the bug report, >> but also done some manual testing. To sanity test performance I've >> run SPECjbb2005 with and without UseNUMA before and after the fix and >> I haven't seen any problem. I also ran SPECjbb2005 on a system where >> one NUMA node has been configured with no large pages while the other >> has enough for the test. Without the fix this crashes immediately, >> but with the fix the results are sane. >> >> Thanks, >> Stefan > From vladimir.kozlov at oracle.com Mon Aug 26 10:14:49 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 26 Aug 2013 10:14:49 -0700 Subject: RFR: 8006164 [TESTBUG] compact profile hotspot test issues In-Reply-To: <521AB34A.8020801@oracle.com> References: <521AB34A.8020801@oracle.com> Message-ID: <521B8D09.7080101@oracle.com> Thank you, David For me it looks odd when you specify group as not other flags, like: -group:compact1 Why it was designed this way? Can ou add jprt group too (as template for now)? We want for long time to run in JPRT small subset of our jtreg tests which will take less 15min. I know, it is separate problem but can you add it as template which we can use and extend later? Thanks, Vladimir On 8/25/13 6:45 PM, David Holmes wrote: > This change introduces the TEST.groups file to allow jtreg to run > regression tests by groups - where the groups are defined to support > testing of compact profiles and the minimal VM. > > webrev: http://cr.openjdk.java.net/~dholmes/8006164/webrev/ > > The primary groups are: > - jdk > - jre > - compact3 > - compact2 > - compact2_minimal > - compact1 > - compact1_minimal > > The minimal VM is only supported on compact1 and compact2. > > To select a group of tests you use : > > Eg to run only those tests that can run on compact1 use: > > jtreg :compact1 > > Of course you still need to point jtreg at the right kind of runtime > image (and give it a full JDK as the compile-jdk!); and if testing the > minimal VM you need to tell jtreg to select it using -javaoptions:-minimal > > The full jtreg group facility is only available in the most recent jtreg > builds, so you will need to grab the latest nightly build, or latest > sources. > > It is expected that these group definitions will need some tweaking. So > far testing has been limited to linux, but we want to get this in ASAP > to extend the testing. > > Note: once this is in place, anyone writing regression tests will need > to be aware of whether that test is limited to certain profiles and > update the group file accordingly. Sometimes it is not the item being > tested that determines the minimum needed profile, but the test > infrastructure eg if it uses XML. > > The changeset will be pushed via hotspot-embas that is what is used for > profile testing. > > Thanks, > David From dawid.weiss at gmail.com Mon Aug 26 12:56:46 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Mon, 26 Aug 2013 21:56:46 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: <520B2AAF.2090609@oracle.com> <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> <5212A647.10800@oracle.com> Message-ID: > An ideal scenario and what I want to achieve is I'd like to stop on an assertion somewhere in the jitted code and go back to it to follow the execution (so that I can see what code is responsible for the issing increment). I'll need to sync this up (manually or otherwise) with the optoassembly too [...] Would somebody be so kind and provide some light on whether the above is feasible? I'm getting up to speed with visual studio -- haven't used assembly-level debugging in a longer while -- but I'm having troubles connecting the dots with verbose optoassembly output (the addresses don't seem to match). Thanks and again, apologies if it's something trivial but I couldn't find any helpful resources on the net. Dawid On Sun, Aug 25, 2013 at 9:43 PM, Dawid Weiss wrote: > I know why the assertion is hit. I still don't know (and probably > won't figure it out) why it is so difficult to reproduce or which > optimization leads to it. > > In short, the following code in ByteSliceReader#readByte: > > public byte readByte() { > assert !eof(); > assert upto <= limit; > if (upto == limit) { > nextSlice(); > } > return buffer[upto++]; > } > > is inlined in a number of places. If I include: > > public byte readByte() { > assert !eof(); > assert upto <= limit; > if (upto == limit) { > nextSlice(); > baz = upto; > } > return buffer[upto++]; > } > static int baz; > > I see a number of assignments to 'baz'. This is because methods like > readVInt fork out many conditional branches, as in: > > public int readVInt() throws IOException { > byte b = readByte(); > if (b >= 0) return b; > int i = b & 0x7F; > b = readByte(); > i |= (b & 0x7F) << 7; > if (b >= 0) return i; > b = readByte(); > i |= (b & 0x7F) << 14; > if (b >= 0) return i; > b = readByte(); > i |= (b & 0x7F) << 21; > if (b >= 0) return i; > b = readByte(); > // Warning: the next ands use 0x0F / 0xF0 - beware copy/paste errors: > i |= (b & 0x0F) << 28; > if ((b & 0xF0) == 0) return i; > throw new IOException("Invalid vInt detected (too many bits)"); > } > > One of these executions (when upto == limit, and possibly with some > other upper condition) leads to missing increment on buffer[upto++] -- > upto remains unmodified (but the value at buffer[upto] is returned > properly). Because upto is moved to a register in many of those > inlined methods I suspect either the register may be incremented and > not saved or the increment may be removed due to some local escape > analysis magic (that has to be incorrect, obviously). How G1GC > interacts with all this (remember, it only happens with G1GC) I have > no clue. > > Anyway, I've tried looking at -XX:+PrintEscapeAnalysis but I couldn't > make much sense of it. I also dug into some of the opto assembly > branches trying to map them back into the original bytecode, but it's > a very long process -- had to map PcDesc manually to the assembly > offset, then go to bytecode again. Then I fired visual studio and > halted it like Vladimir mentioned: > -XX:AbortVMOnException=java.lang.AssertionError > -XX:+ShowMessageBoxOnError > > Once I attach to the halted JVM I "break all" and I see the reported > thread's stack trace halted inside ntdll (with the closest JVM frame > stopped at get_deopt_original_pc). The frames below it don't seem to > make much sense to me -- they don't seem to point to any addresses > reported in the compilation log (PcDesc clauses). I'm a complete > newbie to this, so I apologize if it's a lame question, but how can I > find out which part of the original jitted code this assertion was > invoked from? > > An ideal scenario and what I want to achieve is I'd like to stop on an > assertion somewhere in the jitted code and go back to it to follow the > execution (so that I can see what code is responsible for the missing > increment). I'll need to sync this up (manually or otherwise) with the > optoassembly too, otherwise I'll probably lose any remaining hair > trying to figure out what's what :) > > A hint (or any other pointer; RTFM) would be very welcome. > > Dawid > > > On Tue, Aug 20, 2013 at 11:32 AM, Dawid Weiss wrote: >> One follow-up with respect to those encoded integers -- I swapped the >> correct and incorrect sequence in my last e-mail, sorry. I then also >> added a sysout here: >> >> @@ -451,6 +453,7 @@ >> termFreq = 1; >> } else { >> termFreq = freq.readVInt(); >> + System.err.print("# (tf): " + termFreq + " "); >> } >> } >> >> With this the assertion is no longer hit but it shows where the >> difference in numbers comes from: >> >> Correct sequence is: >> >> # (eof) >> # (code): 0 >> # (tf): 3 >> # (code): 4 >> # (tf): 3 >> # (code): 2 >> # (tf): 5 >> # (code): 2 >> # (tf): 2 >> # (code): 3 >> # (code): 5 >> # (code): 2 >> >> And the incorrect, assertion-hit run shows: >> >> # (eof) >> # (code): 0 >> # (code): 3 >> # (code): 4 >> # (code): 3 >> # (code): 2 >> # (code): 5 >> # (code): 2 >> # (code): 2 >> # (code): 3 >> >> So there's something odd happening after the first readvint which >> returns 0 -- the next number that should be read by: >> >> termFreq = freq.readVInt(); >> >> is re-read as the next code. >> >> Dawid >> >> >> On Tue, Aug 20, 2013 at 11:11 AM, Dawid Weiss wrote: >>> Thanks for comments guys. >>> >>>> It is great that you can build fastdebug VM. I assume that if I give you a >>>> patch to try you can also build with it. >>> >>> Yes, absolutely. >>> >>>> First, you can run with next options and then send zipped output (related >>>> part before the method compilation and optoassembler output, don't use hsdis >>>> for that) and hs_err file when test fails: >>> >>> I did that. Used the options you requested -- a full log of all I did >>> is included in the ZIP file here: >>> http://www.cs.put.poznan.pl/dweiss/tmp/debug-files.zip >>> >>> Cat debug-files\debug-log.txt. There are several runs included in that >>> ZIP file, in short: >>> >>> - jdk18-fastdebug, b102, full run (no abort on assertion, explained in >>> debug-log.txt): >>> 001-no-abort-on-assertion >>> 002-no-abort-on-assertion >>> >>> - jdk18-fastdebug, b102, abort on assertion (includes mem dumps) >>> 003-with-abort-on-assertion >>> 004-with-abort-on-assertion >>> >>> - jdk18-fastdebug, hsx tip, abort on assertion (includes mem dumps) >>> 005-hsx-tip >>> 006-hsx-tip >>> >>> - jdk18-fastdebug, hsx tip, excluded readvint method inlining (passed >>> build, so only compilation logs available). >>> 007-excluded-readvint >>> >>>> Looking on java code in FreqProxTermsWriterPerField::flush() and based on >>>> LUCENE-5168 report generated code somehow missed EOF check. Am I right? This >>>> is why the Assert is thrown? >>> >>> It's not the only method it trips on. Depending on the seed the >>> problem shows up in different places. For the dumps I included the >>> issue seems to be here: >>> >>>> } else { >>>> final int code = freq.readVInt(); >>>> if (!readTermFreq) { >>>> docID += code; >>>> termFreq = -1; >>> >>> If I add sysouts as in: >>> >>> Index: core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>> =================================================================== >>> --- core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>> (revision 1512807) >>> +++ core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>> (working copy) >>> @@ -427,6 +427,7 @@ >>> //System.out.println(" cycle"); >>> final int termFreq; >>> if (freq.eof()) { >>> + System.err.print("# (eof)"); >>> if (postings.lastDocCodes[termID] != -1) { >>> // Return last doc >>> docID = postings.lastDocIDs[termID]; >>> @@ -442,6 +443,7 @@ >>> } >>> } else { >>> final int code = freq.readVInt(); >>> + System.err.print("# (code): " + code + " "); >>> if (!readTermFreq) { >>> docID += code; >>> termFreq = -1; >>> >>> then for a constant seed you'll get an identical sequence of values. >>> Once the assertion hits though, the sequence deviates. Comparing a >>> passing run (excluding readvint) and a failing run I get a lot of >>> initial aligned outputs and then a deviation: >>> >>> (correct run): >>> # (eof) >>> # (eof) >>> # (eof) >>> # (code): 0 >>> # (code): 3 >>> # (code): 4 >>> # (code): 3 >>> >>> (incorrect run): >>> # (eof) >>> # (eof) >>> # (eof) >>> # (code): 0 >>> # (code): 4 <- wtf? >>> # (code): 2 >>> # (code): 2 >>> >>> How can a variable encoded integer be misinterpreted from 3 to 4 is >>> beyond me, sorry. But it's not an EOF condition I think, at least the >>> deviation happens where the original run had was entering (code) >>> branch. >>> >>>> Could you also send latest version of FreqProxTermsWriterPerField.java you >>>> are testing? >>> >>> I'm testing against a fixed branch (the info is included in debug-log.txt). >>> >>> If there's anything else I can do, let me know. I'm also curious how >>> you approach debugging this thing. It may be time-based so I don't >>> think it'll reproduce on your machine out of the box, but who knows. >>> All I know is that, for example, if you add one more sysout before the >>> while loop it suddenly stops reproducing so probably something gets >>> compiled differently... Wild :) >>> >>> Dawid From vladimir.kozlov at oracle.com Mon Aug 26 18:07:32 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 26 Aug 2013 18:07:32 -0700 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: References: <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> <5212A647.10800@oracle.com> Message-ID: <521BFBD4.7090800@oracle.com> Dawid, Let it crush with AbortVMOnException (without ShowMessageBoxOnError) and look on call stack in hs_err_pidxxx.log file. Jited code usually have uncommon trap for exceptions so the method most likely was deoptimized and you will see interpeter frames on call stack instead of compiled/jited. There should be deoptimization event listed down in hs_err_pidxxx.log which may say in which address in jited code it hit uncommon trap. You can look on it in optoassembly output. Then during method compilation (-XX:+PrintCompilation -Xbatch -XX:CICompilerCount=1 should give you info when the method is compiled, you can verify it in Compile() by this->method()->print()) in debugger stop in ciEnv::register_method() after call to nmethod::new_nmethod(). nm->insts_begin() shows where instructions start. Add instruction offset from optoassembly and set breakepoint at that address. This way you can stop in jited code. G1 affects inlining since its write barriers code size is larger then other collectors (it has pre and post barriers for oop stores). I still did not have time to look on your logs. Vladimir On 8/26/13 12:56 PM, Dawid Weiss wrote: >> An ideal scenario and what I want to achieve is I'd like to stop on an assertion somewhere in the jitted code and go back to it to follow the execution (so that I can see what code is responsible for the issing > increment). I'll need to sync this up (manually or otherwise) with the > optoassembly too [...] > > Would somebody be so kind and provide some light on whether the above > is feasible? I'm getting up to speed with visual studio -- haven't > used assembly-level debugging in a longer while -- but I'm having > troubles connecting the dots with verbose optoassembly output (the > addresses don't seem to match). Thanks and again, apologies if it's > something trivial but I couldn't find any helpful resources on the > net. > > Dawid > > On Sun, Aug 25, 2013 at 9:43 PM, Dawid Weiss wrote: >> I know why the assertion is hit. I still don't know (and probably >> won't figure it out) why it is so difficult to reproduce or which >> optimization leads to it. >> >> In short, the following code in ByteSliceReader#readByte: >> >> public byte readByte() { >> assert !eof(); >> assert upto <= limit; >> if (upto == limit) { >> nextSlice(); >> } >> return buffer[upto++]; >> } >> >> is inlined in a number of places. If I include: >> >> public byte readByte() { >> assert !eof(); >> assert upto <= limit; >> if (upto == limit) { >> nextSlice(); >> baz = upto; >> } >> return buffer[upto++]; >> } >> static int baz; >> >> I see a number of assignments to 'baz'. This is because methods like >> readVInt fork out many conditional branches, as in: >> >> public int readVInt() throws IOException { >> byte b = readByte(); >> if (b >= 0) return b; >> int i = b & 0x7F; >> b = readByte(); >> i |= (b & 0x7F) << 7; >> if (b >= 0) return i; >> b = readByte(); >> i |= (b & 0x7F) << 14; >> if (b >= 0) return i; >> b = readByte(); >> i |= (b & 0x7F) << 21; >> if (b >= 0) return i; >> b = readByte(); >> // Warning: the next ands use 0x0F / 0xF0 - beware copy/paste errors: >> i |= (b & 0x0F) << 28; >> if ((b & 0xF0) == 0) return i; >> throw new IOException("Invalid vInt detected (too many bits)"); >> } >> >> One of these executions (when upto == limit, and possibly with some >> other upper condition) leads to missing increment on buffer[upto++] -- >> upto remains unmodified (but the value at buffer[upto] is returned >> properly). Because upto is moved to a register in many of those >> inlined methods I suspect either the register may be incremented and >> not saved or the increment may be removed due to some local escape >> analysis magic (that has to be incorrect, obviously). How G1GC >> interacts with all this (remember, it only happens with G1GC) I have >> no clue. >> >> Anyway, I've tried looking at -XX:+PrintEscapeAnalysis but I couldn't >> make much sense of it. I also dug into some of the opto assembly >> branches trying to map them back into the original bytecode, but it's >> a very long process -- had to map PcDesc manually to the assembly >> offset, then go to bytecode again. Then I fired visual studio and >> halted it like Vladimir mentioned: >> -XX:AbortVMOnException=java.lang.AssertionError >> -XX:+ShowMessageBoxOnError >> >> Once I attach to the halted JVM I "break all" and I see the reported >> thread's stack trace halted inside ntdll (with the closest JVM frame >> stopped at get_deopt_original_pc). The frames below it don't seem to >> make much sense to me -- they don't seem to point to any addresses >> reported in the compilation log (PcDesc clauses). I'm a complete >> newbie to this, so I apologize if it's a lame question, but how can I >> find out which part of the original jitted code this assertion was >> invoked from? >> >> An ideal scenario and what I want to achieve is I'd like to stop on an >> assertion somewhere in the jitted code and go back to it to follow the >> execution (so that I can see what code is responsible for the missing >> increment). I'll need to sync this up (manually or otherwise) with the >> optoassembly too, otherwise I'll probably lose any remaining hair >> trying to figure out what's what :) >> >> A hint (or any other pointer; RTFM) would be very welcome. >> >> Dawid >> >> >> On Tue, Aug 20, 2013 at 11:32 AM, Dawid Weiss wrote: >>> One follow-up with respect to those encoded integers -- I swapped the >>> correct and incorrect sequence in my last e-mail, sorry. I then also >>> added a sysout here: >>> >>> @@ -451,6 +453,7 @@ >>> termFreq = 1; >>> } else { >>> termFreq = freq.readVInt(); >>> + System.err.print("# (tf): " + termFreq + " "); >>> } >>> } >>> >>> With this the assertion is no longer hit but it shows where the >>> difference in numbers comes from: >>> >>> Correct sequence is: >>> >>> # (eof) >>> # (code): 0 >>> # (tf): 3 >>> # (code): 4 >>> # (tf): 3 >>> # (code): 2 >>> # (tf): 5 >>> # (code): 2 >>> # (tf): 2 >>> # (code): 3 >>> # (code): 5 >>> # (code): 2 >>> >>> And the incorrect, assertion-hit run shows: >>> >>> # (eof) >>> # (code): 0 >>> # (code): 3 >>> # (code): 4 >>> # (code): 3 >>> # (code): 2 >>> # (code): 5 >>> # (code): 2 >>> # (code): 2 >>> # (code): 3 >>> >>> So there's something odd happening after the first readvint which >>> returns 0 -- the next number that should be read by: >>> >>> termFreq = freq.readVInt(); >>> >>> is re-read as the next code. >>> >>> Dawid >>> >>> >>> On Tue, Aug 20, 2013 at 11:11 AM, Dawid Weiss wrote: >>>> Thanks for comments guys. >>>> >>>>> It is great that you can build fastdebug VM. I assume that if I give you a >>>>> patch to try you can also build with it. >>>> >>>> Yes, absolutely. >>>> >>>>> First, you can run with next options and then send zipped output (related >>>>> part before the method compilation and optoassembler output, don't use hsdis >>>>> for that) and hs_err file when test fails: >>>> >>>> I did that. Used the options you requested -- a full log of all I did >>>> is included in the ZIP file here: >>>> http://www.cs.put.poznan.pl/dweiss/tmp/debug-files.zip >>>> >>>> Cat debug-files\debug-log.txt. There are several runs included in that >>>> ZIP file, in short: >>>> >>>> - jdk18-fastdebug, b102, full run (no abort on assertion, explained in >>>> debug-log.txt): >>>> 001-no-abort-on-assertion >>>> 002-no-abort-on-assertion >>>> >>>> - jdk18-fastdebug, b102, abort on assertion (includes mem dumps) >>>> 003-with-abort-on-assertion >>>> 004-with-abort-on-assertion >>>> >>>> - jdk18-fastdebug, hsx tip, abort on assertion (includes mem dumps) >>>> 005-hsx-tip >>>> 006-hsx-tip >>>> >>>> - jdk18-fastdebug, hsx tip, excluded readvint method inlining (passed >>>> build, so only compilation logs available). >>>> 007-excluded-readvint >>>> >>>>> Looking on java code in FreqProxTermsWriterPerField::flush() and based on >>>>> LUCENE-5168 report generated code somehow missed EOF check. Am I right? This >>>>> is why the Assert is thrown? >>>> >>>> It's not the only method it trips on. Depending on the seed the >>>> problem shows up in different places. For the dumps I included the >>>> issue seems to be here: >>>> >>>>> } else { >>>>> final int code = freq.readVInt(); >>>>> if (!readTermFreq) { >>>>> docID += code; >>>>> termFreq = -1; >>>> >>>> If I add sysouts as in: >>>> >>>> Index: core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>> =================================================================== >>>> --- core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>> (revision 1512807) >>>> +++ core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>> (working copy) >>>> @@ -427,6 +427,7 @@ >>>> //System.out.println(" cycle"); >>>> final int termFreq; >>>> if (freq.eof()) { >>>> + System.err.print("# (eof)"); >>>> if (postings.lastDocCodes[termID] != -1) { >>>> // Return last doc >>>> docID = postings.lastDocIDs[termID]; >>>> @@ -442,6 +443,7 @@ >>>> } >>>> } else { >>>> final int code = freq.readVInt(); >>>> + System.err.print("# (code): " + code + " "); >>>> if (!readTermFreq) { >>>> docID += code; >>>> termFreq = -1; >>>> >>>> then for a constant seed you'll get an identical sequence of values. >>>> Once the assertion hits though, the sequence deviates. Comparing a >>>> passing run (excluding readvint) and a failing run I get a lot of >>>> initial aligned outputs and then a deviation: >>>> >>>> (correct run): >>>> # (eof) >>>> # (eof) >>>> # (eof) >>>> # (code): 0 >>>> # (code): 3 >>>> # (code): 4 >>>> # (code): 3 >>>> >>>> (incorrect run): >>>> # (eof) >>>> # (eof) >>>> # (eof) >>>> # (code): 0 >>>> # (code): 4 <- wtf? >>>> # (code): 2 >>>> # (code): 2 >>>> >>>> How can a variable encoded integer be misinterpreted from 3 to 4 is >>>> beyond me, sorry. But it's not an EOF condition I think, at least the >>>> deviation happens where the original run had was entering (code) >>>> branch. >>>> >>>>> Could you also send latest version of FreqProxTermsWriterPerField.java you >>>>> are testing? >>>> >>>> I'm testing against a fixed branch (the info is included in debug-log.txt). >>>> >>>> If there's anything else I can do, let me know. I'm also curious how >>>> you approach debugging this thing. It may be time-based so I don't >>>> think it'll reproduce on your machine out of the box, but who knows. >>>> All I know is that, for example, if you add one more sysout before the >>>> while loop it suddenly stops reproducing so probably something gets >>>> compiled differently... Wild :) >>>> >>>> Dawid From alejandro.murillo at oracle.com Mon Aug 26 18:21:57 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Tue, 27 Aug 2013 01:21:57 +0000 Subject: hg: hsx/hsx24/hotspot: 13 new changesets Message-ID: <20130827012303.303CA48B98@hg.openjdk.java.net> Changeset: b5c3f432e953 Author: jeff Date: 2013-07-25 12:30 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b5c3f432e953 8014850: Third Party License Readme updates for 7u40 Reviewed-by: lana, tbell ! THIRD_PARTY_README Changeset: 6ff570d6cca7 Author: lana Date: 2013-07-25 14:12 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/6ff570d6cca7 Merge Changeset: 13edc330a937 Author: amurillo Date: 2013-07-29 15:11 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/13edc330a937 Merge Changeset: 295528bfcdd1 Author: cl Date: 2013-07-31 21:27 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/295528bfcdd1 Added tag jdk7u40-b36 for changeset 13edc330a937 ! .hgtags Changeset: 1f3b0ff9649c Author: asaha Date: 2013-08-02 13:10 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1f3b0ff9649c Added tag jdk7u40-b37 for changeset 295528bfcdd1 ! .hgtags Changeset: 74de360e3415 Author: asaha Date: 2013-08-07 12:09 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/74de360e3415 Added tag jdk7u40-b38 for changeset 1f3b0ff9649c ! .hgtags Changeset: 86673506aeb6 Author: katleman Date: 2013-08-12 12:07 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/86673506aeb6 Added tag jdk7u40-b39 for changeset 74de360e3415 ! .hgtags Changeset: 4445f65c4793 Author: asaha Date: 2013-08-19 12:18 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4445f65c4793 Added tag jdk7u40-b40 for changeset 86673506aeb6 ! .hgtags Changeset: 4e779305ed58 Author: katleman Date: 2013-08-21 12:11 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/4e779305ed58 Added tag jdk7u40-b41 for changeset 4445f65c4793 ! .hgtags Changeset: 48193a76dc3a Author: katleman Date: 2013-08-26 07:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/48193a76dc3a Added tag jdk7u40-b42 for changeset 4e779305ed58 ! .hgtags Changeset: 2bf38259b945 Author: amurillo Date: 2013-08-26 11:51 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/2bf38259b945 8023751: Need to backout 8020943, was pushed to hs24 without approval Reviewed-by: jcoomes ! src/share/vm/services/gcNotifier.cpp Changeset: b8d8caf6df74 Author: amurillo Date: 2013-08-26 11:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/b8d8caf6df74 Merge Changeset: eceae0478243 Author: amurillo Date: 2013-08-26 11:56 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/eceae0478243 Added tag hs24-b56 for changeset b8d8caf6df74 ! .hgtags From david.holmes at oracle.com Mon Aug 26 19:13:41 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Aug 2013 12:13:41 +1000 Subject: RFR: 8006164 [TESTBUG] compact profile hotspot test issues In-Reply-To: <521B8D09.7080101@oracle.com> References: <521AB34A.8020801@oracle.com> <521B8D09.7080101@oracle.com> Message-ID: <521C0B55.5060205@oracle.com> Hi Vladimir, On 27/08/2013 3:14 AM, Vladimir Kozlov wrote: > Thank you, David > > For me it looks odd when you specify group as not other flags, like: > > -group:compact1 > > Why it was designed this way? Are you referring to the jtreg usage? ie jtreg -jdk:xxx -v -r reportdir :compact1 The group is not an option it is a test designator similar to doing: jtreg -jdk:xxx -v -r reportdir runtime/NMT gc/ > Can ou add jprt group too (as template for now)? We want for long time > to run in JPRT small subset of our jtreg tests which will take less > 15min. I know, it is separate problem but can you add it as template > which we can use and extend later? Adding this is trivial. The "template" would be: jprt = There doesn't seem much point in me adding that at this time though. Better to leave it until we know how it needs to be defined. Thanks, David > Thanks, > Vladimir > > On 8/25/13 6:45 PM, David Holmes wrote: >> This change introduces the TEST.groups file to allow jtreg to run >> regression tests by groups - where the groups are defined to support >> testing of compact profiles and the minimal VM. >> >> webrev: http://cr.openjdk.java.net/~dholmes/8006164/webrev/ >> >> The primary groups are: >> - jdk >> - jre >> - compact3 >> - compact2 >> - compact2_minimal >> - compact1 >> - compact1_minimal >> >> The minimal VM is only supported on compact1 and compact2. >> >> To select a group of tests you use : >> >> Eg to run only those tests that can run on compact1 use: >> >> jtreg :compact1 >> >> Of course you still need to point jtreg at the right kind of runtime >> image (and give it a full JDK as the compile-jdk!); and if testing the >> minimal VM you need to tell jtreg to select it using >> -javaoptions:-minimal >> >> The full jtreg group facility is only available in the most recent jtreg >> builds, so you will need to grab the latest nightly build, or latest >> sources. >> >> It is expected that these group definitions will need some tweaking. So >> far testing has been limited to linux, but we want to get this in ASAP >> to extend the testing. >> >> Note: once this is in place, anyone writing regression tests will need >> to be aware of whether that test is limited to certain profiles and >> update the group file accordingly. Sometimes it is not the item being >> tested that determines the minimum needed profile, but the test >> infrastructure eg if it uses XML. >> >> The changeset will be pushed via hotspot-embas that is what is used for >> profile testing. >> >> Thanks, >> David From vladimir.kozlov at oracle.com Mon Aug 26 20:14:16 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 26 Aug 2013 20:14:16 -0700 Subject: RFR: 8006164 [TESTBUG] compact profile hotspot test issues In-Reply-To: <521C0B55.5060205@oracle.com> References: <521AB34A.8020801@oracle.com> <521B8D09.7080101@oracle.com> <521C0B55.5060205@oracle.com> Message-ID: <521C1988.2040009@oracle.com> On 8/26/13 7:13 PM, David Holmes wrote: > Hi Vladimir, > > On 27/08/2013 3:14 AM, Vladimir Kozlov wrote: >> Thank you, David >> >> For me it looks odd when you specify group as not other flags, like: >> >> -group:compact1 >> >> Why it was designed this way? > > Are you referring to the jtreg usage? ie > > jtreg -jdk:xxx -v -r reportdir :compact1 Yes, I asked about that. From the examples in TEST.groups it was not clear how to use them. > > The group is not an option it is a test designator similar to doing: It is not destination from my understanding - it is named list of tests. So I don't see why we can't use it as flag. I understand that I am late and the feature already implemented in jtreg and it is only a matter how jtreg parses command line. But it is unusual to have command parameter starting with :. > > jtreg -jdk:xxx -v -r reportdir runtime/NMT gc/ Can you run subsets of tests from a group?: jtreg -jdk:xxx -v -r reportdir :needs_jdk gc > >> Can ou add jprt group too (as template for now)? We want for long time >> to run in JPRT small subset of our jtreg tests which will take less >> 15min. I know, it is separate problem but can you add it as template >> which we can use and extend later? > > Adding this is trivial. The "template" would be: > > jprt = > > There doesn't seem much point in me adding that at this time though. Better to leave it until we know how it needs to be > defined. Okay. Thanks, Vladimir > > Thanks, > David > >> Thanks, >> Vladimir >> >> On 8/25/13 6:45 PM, David Holmes wrote: >>> This change introduces the TEST.groups file to allow jtreg to run >>> regression tests by groups - where the groups are defined to support >>> testing of compact profiles and the minimal VM. >>> >>> webrev: http://cr.openjdk.java.net/~dholmes/8006164/webrev/ >>> >>> The primary groups are: >>> - jdk >>> - jre >>> - compact3 >>> - compact2 >>> - compact2_minimal >>> - compact1 >>> - compact1_minimal >>> >>> The minimal VM is only supported on compact1 and compact2. >>> >>> To select a group of tests you use : >>> >>> Eg to run only those tests that can run on compact1 use: >>> >>> jtreg :compact1 >>> >>> Of course you still need to point jtreg at the right kind of runtime >>> image (and give it a full JDK as the compile-jdk!); and if testing the >>> minimal VM you need to tell jtreg to select it using >>> -javaoptions:-minimal >>> >>> The full jtreg group facility is only available in the most recent jtreg >>> builds, so you will need to grab the latest nightly build, or latest >>> sources. >>> >>> It is expected that these group definitions will need some tweaking. So >>> far testing has been limited to linux, but we want to get this in ASAP >>> to extend the testing. >>> >>> Note: once this is in place, anyone writing regression tests will need >>> to be aware of whether that test is limited to certain profiles and >>> update the group file accordingly. Sometimes it is not the item being >>> tested that determines the minimum needed profile, but the test >>> infrastructure eg if it uses XML. >>> >>> The changeset will be pushed via hotspot-embas that is what is used for >>> profile testing. >>> >>> Thanks, >>> David From david.holmes at oracle.com Mon Aug 26 20:36:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Aug 2013 13:36:48 +1000 Subject: RFR: 8006164 [TESTBUG] compact profile hotspot test issues In-Reply-To: <521C1988.2040009@oracle.com> References: <521AB34A.8020801@oracle.com> <521B8D09.7080101@oracle.com> <521C0B55.5060205@oracle.com> <521C1988.2040009@oracle.com> Message-ID: <521C1ED0.8050306@oracle.com> On 27/08/2013 1:14 PM, Vladimir Kozlov wrote: > On 8/26/13 7:13 PM, David Holmes wrote: >> Hi Vladimir, >> >> On 27/08/2013 3:14 AM, Vladimir Kozlov wrote: >>> Thank you, David >>> >>> For me it looks odd when you specify group as not other flags, like: >>> >>> -group:compact1 >>> >>> Why it was designed this way? >> >> Are you referring to the jtreg usage? ie >> >> jtreg -jdk:xxx -v -r reportdir :compact1 > > Yes, I asked about that. From the examples in TEST.groups it was not > clear how to use them. > >> >> The group is not an option it is a test designator similar to doing: > > It is not destination from my understanding - it is named list of tests. Right, a group defines an explicit named list of tests, while gc/ "names" a list of tests implicitly by their location in the directory structure. Both form the "here are the tests to run" arguments to jtreg. > So I don't see why we can't use it as flag. I understand that I am late > and the feature already implemented in jtreg and it is only a matter how > jtreg parses command line. But it is unusual to have command parameter > starting with :. jtreg needs to be able to distinguish between the name of a test and the name of a group hence : is a group name delimiter. Actually the complete syntax allows another designator in front of the : testdir:group which I believe supports the fact that any testdir can contain a TEST.ROOT file which among other things can define the group file in which the group definition can be found. But this is all jtreg stuff :) >> >> jtreg -jdk:xxx -v -r reportdir runtime/NMT gc/ > > Can you run subsets of tests from a group?: > > jtreg -jdk:xxx -v -r reportdir :needs_jdk gc Not at present. A group defines a set of tests, so the above would be a union of the tests in group :needs_jdk and the tests under directory gc. I am currently arguing for a way to exclude a group on the command line so that you can "subset" to some degree eg: jtreg gc -:needs_jdk would run all gc tests except those listed in the needs_jdk group. This avoids the need to define composite groups for all permutations of tests that you might want to run. BTW the way jtreg produces the set of tests in a group is to first do the union of all included tests and groups, then do a union of the excluded tests and groups, and then subtract the second set from the first. And each group is evaluated in isolation before being used in another group (as opposed to logically being inlined and then the result evaluated). >> >>> Can ou add jprt group too (as template for now)? We want for long time >>> to run in JPRT small subset of our jtreg tests which will take less >>> 15min. I know, it is separate problem but can you add it as template >>> which we can use and extend later? >> >> Adding this is trivial. The "template" would be: >> >> jprt = >> >> There doesn't seem much point in me adding that at this time though. >> Better to leave it until we know how it needs to be >> defined. > > Okay. Thanks. I assume you don't mind being the Reviewer for this? It would be nice to get a second reviewer too. :) David > Thanks, > Vladimir > >> >> Thanks, >> David >> >>> Thanks, >>> Vladimir >>> >>> On 8/25/13 6:45 PM, David Holmes wrote: >>>> This change introduces the TEST.groups file to allow jtreg to run >>>> regression tests by groups - where the groups are defined to support >>>> testing of compact profiles and the minimal VM. >>>> >>>> webrev: http://cr.openjdk.java.net/~dholmes/8006164/webrev/ >>>> >>>> The primary groups are: >>>> - jdk >>>> - jre >>>> - compact3 >>>> - compact2 >>>> - compact2_minimal >>>> - compact1 >>>> - compact1_minimal >>>> >>>> The minimal VM is only supported on compact1 and compact2. >>>> >>>> To select a group of tests you use : >>>> >>>> Eg to run only those tests that can run on compact1 use: >>>> >>>> jtreg :compact1 >>>> >>>> Of course you still need to point jtreg at the right kind of runtime >>>> image (and give it a full JDK as the compile-jdk!); and if testing the >>>> minimal VM you need to tell jtreg to select it using >>>> -javaoptions:-minimal >>>> >>>> The full jtreg group facility is only available in the most recent >>>> jtreg >>>> builds, so you will need to grab the latest nightly build, or latest >>>> sources. >>>> >>>> It is expected that these group definitions will need some tweaking. So >>>> far testing has been limited to linux, but we want to get this in ASAP >>>> to extend the testing. >>>> >>>> Note: once this is in place, anyone writing regression tests will need >>>> to be aware of whether that test is limited to certain profiles and >>>> update the group file accordingly. Sometimes it is not the item being >>>> tested that determines the minimum needed profile, but the test >>>> infrastructure eg if it uses XML. >>>> >>>> The changeset will be pushed via hotspot-embas that is what is used for >>>> profile testing. >>>> >>>> Thanks, >>>> David From dawid.weiss at gmail.com Tue Aug 27 00:15:50 2013 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Tue, 27 Aug 2013 09:15:50 +0200 Subject: G1GC/ JIT compilation bug hunt. In-Reply-To: <521BFBD4.7090800@oracle.com> References: <03a701ce98ec$8be46cf0$a3ad46d0$@apache.org> <520D1AFC.7050505@Oracle.COM> <520D25EB.7030005@oracle.com> <520DD9C1.1030303@oracle.com> <1309FF7B-3330-4859-9384-7D90AB095CA2@oracle.com> <5212A647.10800@oracle.com> <521BFBD4.7090800@oracle.com> Message-ID: Thanks Vladimir. I had the impression I may be looking at the interpreter. Just for completeness, I also thought/tried the following ways to stop at the jitted code: 1) call Windows debugger API endpoints from kernel32 -- http://msdn.microsoft.com/en-us/library/windows/desktop/ms679297(v=vs.85).aspx via JNI/ JNA. This worked surprisingly well -- you can even wait for the debugger to attached to the code in a loop, works like a charm. :) Although once you break into the debugger I again couldn't make sense of the stack -- probably the infrequent call causes a deopt again and we're back in the interpreter. 2) use Unsafe to force a null pointer dereference :) This should send a debugger signal, right? I didn't try it though, didn't have the time yet. I suspect it may be moved to an infrequent trap too and we're back where we started, eh. > I still did not have time to look on your logs. No worries, it's been a very very educational experience for me. Besides, I used to write tons of assembly (not on x86) and it actually feels very good to be back at the assembly mnemonic level ;) Don't spoil my weekend pet project :) And seriously -- if you want to check out those logs let me know in advance and I'll prepare an update with hsx-tip if needed. Dawid On Tue, Aug 27, 2013 at 3:07 AM, Vladimir Kozlov wrote: > Dawid, > > Let it crush with AbortVMOnException (without ShowMessageBoxOnError) and > look on call stack in hs_err_pidxxx.log file. Jited code usually have > uncommon trap for exceptions so the method most likely was deoptimized and > you will see interpeter frames on call stack instead of compiled/jited. > There should be deoptimization event listed down in hs_err_pidxxx.log which > may say in which address in jited code it hit uncommon trap. You can look on > it in optoassembly output. Then during method compilation > (-XX:+PrintCompilation -Xbatch -XX:CICompilerCount=1 should give you info > when the method is compiled, you can verify it in Compile() by > this->method()->print()) in debugger stop in ciEnv::register_method() after > call to nmethod::new_nmethod(). nm->insts_begin() shows where instructions > start. Add instruction offset from optoassembly and set breakepoint at that > address. This way you can stop in jited code. > > G1 affects inlining since its write barriers code size is larger then other > collectors (it has pre and post barriers for oop stores). > > I still did not have time to look on your logs. > > Vladimir > > > On 8/26/13 12:56 PM, Dawid Weiss wrote: >>> >>> An ideal scenario and what I want to achieve is I'd like to stop on an >>> assertion somewhere in the jitted code and go back to it to follow the >>> execution (so that I can see what code is responsible for the issing >> >> increment). I'll need to sync this up (manually or otherwise) with the >> optoassembly too [...] >> >> Would somebody be so kind and provide some light on whether the above >> is feasible? I'm getting up to speed with visual studio -- haven't >> used assembly-level debugging in a longer while -- but I'm having >> troubles connecting the dots with verbose optoassembly output (the >> addresses don't seem to match). Thanks and again, apologies if it's >> something trivial but I couldn't find any helpful resources on the >> net. >> >> Dawid >> >> On Sun, Aug 25, 2013 at 9:43 PM, Dawid Weiss >> wrote: >>> >>> I know why the assertion is hit. I still don't know (and probably >>> won't figure it out) why it is so difficult to reproduce or which >>> optimization leads to it. >>> >>> In short, the following code in ByteSliceReader#readByte: >>> >>> public byte readByte() { >>> assert !eof(); >>> assert upto <= limit; >>> if (upto == limit) { >>> nextSlice(); >>> } >>> return buffer[upto++]; >>> } >>> >>> is inlined in a number of places. If I include: >>> >>> public byte readByte() { >>> assert !eof(); >>> assert upto <= limit; >>> if (upto == limit) { >>> nextSlice(); >>> baz = upto; >>> } >>> return buffer[upto++]; >>> } >>> static int baz; >>> >>> I see a number of assignments to 'baz'. This is because methods like >>> readVInt fork out many conditional branches, as in: >>> >>> public int readVInt() throws IOException { >>> byte b = readByte(); >>> if (b >= 0) return b; >>> int i = b & 0x7F; >>> b = readByte(); >>> i |= (b & 0x7F) << 7; >>> if (b >= 0) return i; >>> b = readByte(); >>> i |= (b & 0x7F) << 14; >>> if (b >= 0) return i; >>> b = readByte(); >>> i |= (b & 0x7F) << 21; >>> if (b >= 0) return i; >>> b = readByte(); >>> // Warning: the next ands use 0x0F / 0xF0 - beware copy/paste >>> errors: >>> i |= (b & 0x0F) << 28; >>> if ((b & 0xF0) == 0) return i; >>> throw new IOException("Invalid vInt detected (too many bits)"); >>> } >>> >>> One of these executions (when upto == limit, and possibly with some >>> other upper condition) leads to missing increment on buffer[upto++] -- >>> upto remains unmodified (but the value at buffer[upto] is returned >>> properly). Because upto is moved to a register in many of those >>> inlined methods I suspect either the register may be incremented and >>> not saved or the increment may be removed due to some local escape >>> analysis magic (that has to be incorrect, obviously). How G1GC >>> interacts with all this (remember, it only happens with G1GC) I have >>> no clue. >>> >>> Anyway, I've tried looking at -XX:+PrintEscapeAnalysis but I couldn't >>> make much sense of it. I also dug into some of the opto assembly >>> branches trying to map them back into the original bytecode, but it's >>> a very long process -- had to map PcDesc manually to the assembly >>> offset, then go to bytecode again. Then I fired visual studio and >>> halted it like Vladimir mentioned: >>> -XX:AbortVMOnException=java.lang.AssertionError >>> -XX:+ShowMessageBoxOnError >>> >>> Once I attach to the halted JVM I "break all" and I see the reported >>> thread's stack trace halted inside ntdll (with the closest JVM frame >>> stopped at get_deopt_original_pc). The frames below it don't seem to >>> make much sense to me -- they don't seem to point to any addresses >>> reported in the compilation log (PcDesc clauses). I'm a complete >>> newbie to this, so I apologize if it's a lame question, but how can I >>> find out which part of the original jitted code this assertion was >>> invoked from? >>> >>> An ideal scenario and what I want to achieve is I'd like to stop on an >>> assertion somewhere in the jitted code and go back to it to follow the >>> execution (so that I can see what code is responsible for the missing >>> increment). I'll need to sync this up (manually or otherwise) with the >>> optoassembly too, otherwise I'll probably lose any remaining hair >>> trying to figure out what's what :) >>> >>> A hint (or any other pointer; RTFM) would be very welcome. >>> >>> Dawid >>> >>> >>> On Tue, Aug 20, 2013 at 11:32 AM, Dawid Weiss >>> wrote: >>>> >>>> One follow-up with respect to those encoded integers -- I swapped the >>>> correct and incorrect sequence in my last e-mail, sorry. I then also >>>> added a sysout here: >>>> >>>> @@ -451,6 +453,7 @@ >>>> termFreq = 1; >>>> } else { >>>> termFreq = freq.readVInt(); >>>> + System.err.print("# (tf): " + termFreq + " "); >>>> } >>>> } >>>> >>>> With this the assertion is no longer hit but it shows where the >>>> difference in numbers comes from: >>>> >>>> Correct sequence is: >>>> >>>> # (eof) >>>> # (code): 0 >>>> # (tf): 3 >>>> # (code): 4 >>>> # (tf): 3 >>>> # (code): 2 >>>> # (tf): 5 >>>> # (code): 2 >>>> # (tf): 2 >>>> # (code): 3 >>>> # (code): 5 >>>> # (code): 2 >>>> >>>> And the incorrect, assertion-hit run shows: >>>> >>>> # (eof) >>>> # (code): 0 >>>> # (code): 3 >>>> # (code): 4 >>>> # (code): 3 >>>> # (code): 2 >>>> # (code): 5 >>>> # (code): 2 >>>> # (code): 2 >>>> # (code): 3 >>>> >>>> So there's something odd happening after the first readvint which >>>> returns 0 -- the next number that should be read by: >>>> >>>> termFreq = freq.readVInt(); >>>> >>>> is re-read as the next code. >>>> >>>> Dawid >>>> >>>> >>>> On Tue, Aug 20, 2013 at 11:11 AM, Dawid Weiss >>>> wrote: >>>>> >>>>> Thanks for comments guys. >>>>> >>>>>> It is great that you can build fastdebug VM. I assume that if I give >>>>>> you a >>>>>> patch to try you can also build with it. >>>>> >>>>> >>>>> Yes, absolutely. >>>>> >>>>>> First, you can run with next options and then send zipped output >>>>>> (related >>>>>> part before the method compilation and optoassembler output, don't use >>>>>> hsdis >>>>>> for that) and hs_err file when test fails: >>>>> >>>>> >>>>> I did that. Used the options you requested -- a full log of all I did >>>>> is included in the ZIP file here: >>>>> http://www.cs.put.poznan.pl/dweiss/tmp/debug-files.zip >>>>> >>>>> Cat debug-files\debug-log.txt. There are several runs included in that >>>>> ZIP file, in short: >>>>> >>>>> - jdk18-fastdebug, b102, full run (no abort on assertion, explained in >>>>> debug-log.txt): >>>>> 001-no-abort-on-assertion >>>>> 002-no-abort-on-assertion >>>>> >>>>> - jdk18-fastdebug, b102, abort on assertion (includes mem dumps) >>>>> 003-with-abort-on-assertion >>>>> 004-with-abort-on-assertion >>>>> >>>>> - jdk18-fastdebug, hsx tip, abort on assertion (includes mem dumps) >>>>> 005-hsx-tip >>>>> 006-hsx-tip >>>>> >>>>> - jdk18-fastdebug, hsx tip, excluded readvint method inlining (passed >>>>> build, so only compilation logs available). >>>>> 007-excluded-readvint >>>>> >>>>>> Looking on java code in FreqProxTermsWriterPerField::flush() and based >>>>>> on >>>>>> LUCENE-5168 report generated code somehow missed EOF check. Am I >>>>>> right? This >>>>>> is why the Assert is thrown? >>>>> >>>>> >>>>> It's not the only method it trips on. Depending on the seed the >>>>> problem shows up in different places. For the dumps I included the >>>>> issue seems to be here: >>>>> >>>>>> } else { >>>>>> final int code = freq.readVInt(); >>>>>> if (!readTermFreq) { >>>>>> docID += code; >>>>>> termFreq = -1; >>>>> >>>>> >>>>> If I add sysouts as in: >>>>> >>>>> Index: >>>>> core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>>> =================================================================== >>>>> --- >>>>> core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>>> (revision 1512807) >>>>> +++ >>>>> core/src/java/org/apache/lucene/index/FreqProxTermsWriterPerField.java >>>>> (working copy) >>>>> @@ -427,6 +427,7 @@ >>>>> //System.out.println(" cycle"); >>>>> final int termFreq; >>>>> if (freq.eof()) { >>>>> + System.err.print("# (eof)"); >>>>> if (postings.lastDocCodes[termID] != -1) { >>>>> // Return last doc >>>>> docID = postings.lastDocIDs[termID]; >>>>> @@ -442,6 +443,7 @@ >>>>> } >>>>> } else { >>>>> final int code = freq.readVInt(); >>>>> + System.err.print("# (code): " + code + " "); >>>>> if (!readTermFreq) { >>>>> docID += code; >>>>> termFreq = -1; >>>>> >>>>> then for a constant seed you'll get an identical sequence of values. >>>>> Once the assertion hits though, the sequence deviates. Comparing a >>>>> passing run (excluding readvint) and a failing run I get a lot of >>>>> initial aligned outputs and then a deviation: >>>>> >>>>> (correct run): >>>>> # (eof) >>>>> # (eof) >>>>> # (eof) >>>>> # (code): 0 >>>>> # (code): 3 >>>>> # (code): 4 >>>>> # (code): 3 >>>>> >>>>> (incorrect run): >>>>> # (eof) >>>>> # (eof) >>>>> # (eof) >>>>> # (code): 0 >>>>> # (code): 4 <- wtf? >>>>> # (code): 2 >>>>> # (code): 2 >>>>> >>>>> How can a variable encoded integer be misinterpreted from 3 to 4 is >>>>> beyond me, sorry. But it's not an EOF condition I think, at least the >>>>> deviation happens where the original run had was entering (code) >>>>> branch. >>>>> >>>>>> Could you also send latest version of FreqProxTermsWriterPerField.java >>>>>> you >>>>>> are testing? >>>>> >>>>> >>>>> I'm testing against a fixed branch (the info is included in >>>>> debug-log.txt). >>>>> >>>>> If there's anything else I can do, let me know. I'm also curious how >>>>> you approach debugging this thing. It may be time-based so I don't >>>>> think it'll reproduce on your machine out of the box, but who knows. >>>>> All I know is that, for example, if you add one more sysout before the >>>>> while loop it suddenly stops reproducing so probably something gets >>>>> compiled differently... Wild :) >>>>> >>>>> Dawid From vladimir.kozlov at oracle.com Tue Aug 27 01:55:29 2013 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 27 Aug 2013 01:55:29 -0700 Subject: RFR: 8006164 [TESTBUG] compact profile hotspot test issues In-Reply-To: <521C1ED0.8050306@oracle.com> References: <521AB34A.8020801@oracle.com> <521B8D09.7080101@oracle.com> <521C0B55.5060205@oracle.com> <521C1988.2040009@oracle.com> <521C1ED0.8050306@oracle.com> Message-ID: <521C6981.4030004@oracle.com> > Thanks. I assume you don't mind being the Reviewer for this? Yes, it is reviewed. Thanks, Vladimir On 8/26/13 8:36 PM, David Holmes wrote: > On 27/08/2013 1:14 PM, Vladimir Kozlov wrote: >> On 8/26/13 7:13 PM, David Holmes wrote: >>> Hi Vladimir, >>> >>> On 27/08/2013 3:14 AM, Vladimir Kozlov wrote: >>>> Thank you, David >>>> >>>> For me it looks odd when you specify group as not other flags, like: >>>> >>>> -group:compact1 >>>> >>>> Why it was designed this way? >>> >>> Are you referring to the jtreg usage? ie >>> >>> jtreg -jdk:xxx -v -r reportdir :compact1 >> >> Yes, I asked about that. From the examples in TEST.groups it was not >> clear how to use them. >> >>> >>> The group is not an option it is a test designator similar to doing: >> >> It is not destination from my understanding - it is named list of tests. > > Right, a group defines an explicit named list of tests, while gc/ "names" a list of tests implicitly by their location > in the directory structure. Both form the "here are the tests to run" arguments to jtreg. > >> So I don't see why we can't use it as flag. I understand that I am late >> and the feature already implemented in jtreg and it is only a matter how >> jtreg parses command line. But it is unusual to have command parameter >> starting with :. > > jtreg needs to be able to distinguish between the name of a test and the name of a group hence : is a group name > delimiter. Actually the complete syntax allows another designator in front of the : > > testdir:group > > which I believe supports the fact that any testdir can contain a TEST.ROOT file which among other things can define the > group file in which the group definition can be found. > > But this is all jtreg stuff :) > >>> >>> jtreg -jdk:xxx -v -r reportdir runtime/NMT gc/ >> >> Can you run subsets of tests from a group?: >> >> jtreg -jdk:xxx -v -r reportdir :needs_jdk gc > > Not at present. A group defines a set of tests, so the above would be a union of the tests in group :needs_jdk and the > tests under directory gc. > > I am currently arguing for a way to exclude a group on the command line so that you can "subset" to some degree eg: > > jtreg gc -:needs_jdk > > would run all gc tests except those listed in the needs_jdk group. This avoids the need to define composite groups for > all permutations of tests that you might want to run. > > BTW the way jtreg produces the set of tests in a group is to first do the union of all included tests and groups, then > do a union of the excluded tests and groups, and then subtract the second set from the first. And each group is > evaluated in isolation before being used in another group (as opposed to logically being inlined and then the result > evaluated). > >>> >>>> Can ou add jprt group too (as template for now)? We want for long time >>>> to run in JPRT small subset of our jtreg tests which will take less >>>> 15min. I know, it is separate problem but can you add it as template >>>> which we can use and extend later? >>> >>> Adding this is trivial. The "template" would be: >>> >>> jprt = >>> >>> There doesn't seem much point in me adding that at this time though. >>> Better to leave it until we know how it needs to be >>> defined. >> >> Okay. > > Thanks. I assume you don't mind being the Reviewer for this? > > It would be nice to get a second reviewer too. :) > > David > >> Thanks, >> Vladimir >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/25/13 6:45 PM, David Holmes wrote: >>>>> This change introduces the TEST.groups file to allow jtreg to run >>>>> regression tests by groups - where the groups are defined to support >>>>> testing of compact profiles and the minimal VM. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8006164/webrev/ >>>>> >>>>> The primary groups are: >>>>> - jdk >>>>> - jre >>>>> - compact3 >>>>> - compact2 >>>>> - compact2_minimal >>>>> - compact1 >>>>> - compact1_minimal >>>>> >>>>> The minimal VM is only supported on compact1 and compact2. >>>>> >>>>> To select a group of tests you use : >>>>> >>>>> Eg to run only those tests that can run on compact1 use: >>>>> >>>>> jtreg :compact1 >>>>> >>>>> Of course you still need to point jtreg at the right kind of runtime >>>>> image (and give it a full JDK as the compile-jdk!); and if testing the >>>>> minimal VM you need to tell jtreg to select it using >>>>> -javaoptions:-minimal >>>>> >>>>> The full jtreg group facility is only available in the most recent >>>>> jtreg >>>>> builds, so you will need to grab the latest nightly build, or latest >>>>> sources. >>>>> >>>>> It is expected that these group definitions will need some tweaking. So >>>>> far testing has been limited to linux, but we want to get this in ASAP >>>>> to extend the testing. >>>>> >>>>> Note: once this is in place, anyone writing regression tests will need >>>>> to be aware of whether that test is limited to certain profiles and >>>>> update the group file accordingly. Sometimes it is not the item being >>>>> tested that determines the minimum needed profile, but the test >>>>> infrastructure eg if it uses XML. >>>>> >>>>> The changeset will be pushed via hotspot-embas that is what is used for >>>>> profile testing. >>>>> >>>>> Thanks, >>>>> David From stefan.johansson at oracle.com Tue Aug 27 06:34:11 2013 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 27 Aug 2013 15:34:11 +0200 Subject: RFR: 8016155: SIGBUS when running Kitchensink with ParallelScavenge and ParallelOld In-Reply-To: <521B3E9B.7000902@oracle.com> References: <521755CC.7040303@oracle.com> <5217B0C2.2070606@oracle.com> <521B3E9B.7000902@oracle.com> Message-ID: <521CAAD3.1070107@oracle.com> Thanks Per and Jon for the reviews. Stefan On 2013-08-26 13:40, Stefan Johansson wrote: > On 2013-08-23 20:58, Jon Masamitsu wrote: >> >> On 8/23/2013 5:30 AM, Stefan Johansson wrote: >>> Hi all, >>> >>> I would like some reviews on my fix for bug: >>> http://bugs.sun.com/view_bug.do?bug_id=8016155 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sjohanss/8016155/webrev.00 >>> >>> Summary: >>> On Linux we have a problem that we hit a SIGBUS when one NUMA node >>> runs out of large pages but the system as a whole has large pages >>> left. To avoid this we need to ease the requirement on which node >>> the memory should be allocated on. This can be done by using the >>> memory policy MPOL_PREFERRED, which prefers a certain node, instead >>> of MPOL_BIND, which requires a certain node. >> >> With your change what happens when the system as a whole >> runs out of large pages? > > The change doesn't do anything specific for large pages it just sets > the memory policy to MPOL_PREFERRED to guarantee that we don't > forcefully use a NUMA node that can't back the given mapping. If we > run out of large pages this will still be handled in the same way, we > prefer that the memory is allocated on a given NUMA node, but if it > isn't possible we'll use another. > > I've verified that this is actually what happens by running SPEPjbb > with an increasing heap and quite few large pages configured on the > system. When the large pages are all used, we fall back on using > regular sized pages and every thing runs along just fine. > > Thanks for highlighting this case, Jon. > > Stefan > >> >> Jon >> >>> >>> Testing: >>> To verify the fix I've run Kitchensink as describe in the bug >>> report, but also done some manual testing. To sanity test >>> performance I've run SPECjbb2005 with and without UseNUMA before and >>> after the fix and I haven't seen any problem. I also ran SPECjbb2005 >>> on a system where one NUMA node has been configured with no large >>> pages while the other has enough for the test. Without the fix this >>> crashes immediately, but with the fix the results are sane. >>> >>> Thanks, >>> Stefan >> > From alejandro.murillo at oracle.com Tue Aug 27 15:51:39 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Tue, 27 Aug 2013 22:51:39 +0000 Subject: hg: hsx/hsx24/hotspot: 8023730: new hotspot build - hs24-b57 Message-ID: <20130827225147.2825E48BFB@hg.openjdk.java.net> Changeset: 1f114331df92 Author: amurillo Date: 2013-08-26 12:06 -0700 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/1f114331df92 8023730: new hotspot build - hs24-b57 Reviewed-by: jcoomes ! make/hotspot_version From mandy.chung at oracle.com Tue Aug 27 18:48:38 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 27 Aug 2013 18:48:38 -0700 Subject: RFR: 8006164 [TESTBUG] compact profile hotspot test issues In-Reply-To: <521AB34A.8020801@oracle.com> References: <521AB34A.8020801@oracle.com> Message-ID: <521D56F6.2060909@oracle.com> Looks fine to me. Similar change has made into jdk [1]. Mandy [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb18a483e772 On 8/25/2013 6:45 PM, David Holmes wrote: > This change introduces the TEST.groups file to allow jtreg to run > regression tests by groups - where the groups are defined to support > testing of compact profiles and the minimal VM. > > webrev: http://cr.openjdk.java.net/~dholmes/8006164/webrev/ > > The primary groups are: > - jdk > - jre > - compact3 > - compact2 > - compact2_minimal > - compact1 > - compact1_minimal > > The minimal VM is only supported on compact1 and compact2. > > To select a group of tests you use : > > Eg to run only those tests that can run on compact1 use: > > jtreg :compact1 > > Of course you still need to point jtreg at the right kind of runtime > image (and give it a full JDK as the compile-jdk!); and if testing the > minimal VM you need to tell jtreg to select it using > -javaoptions:-minimal > > The full jtreg group facility is only available in the most recent > jtreg builds, so you will need to grab the latest nightly build, or > latest sources. > > It is expected that these group definitions will need some tweaking. > So far testing has been limited to linux, but we want to get this in > ASAP to extend the testing. > > Note: once this is in place, anyone writing regression tests will need > to be aware of whether that test is limited to certain profiles and > update the group file accordingly. Sometimes it is not the item being > tested that determines the minimum needed profile, but the test > infrastructure eg if it uses XML. > > The changeset will be pushed via hotspot-embas that is what is used > for profile testing. > > Thanks, > David From daniel.daugherty at oracle.com Tue Aug 27 18:49:09 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 27 Aug 2013 19:49:09 -0600 Subject: RFR: 8006164 [TESTBUG] compact profile hotspot test issues In-Reply-To: <521C6981.4030004@oracle.com> References: <521AB34A.8020801@oracle.com> <521B8D09.7080101@oracle.com> <521C0B55.5060205@oracle.com> <521C1988.2040009@oracle.com> <521C1ED0.8050306@oracle.com> <521C6981.4030004@oracle.com> Message-ID: <521D5715.5010606@oracle.com> > http://cr.openjdk.java.net/~dholmes/8006164/webrev/ test/TEST.ROOT No comments. test/TEST.groups Just to be clear: The addition of any new test will require this file to updated? If so, then we'll have to be careful during reviews. What happens if a test isn't listed? Is it by default in the 'jdk' group? Thumbs up. Dan On 8/27/13 2:55 AM, Vladimir Kozlov wrote: > > Thanks. I assume you don't mind being the Reviewer for this? > > Yes, it is reviewed. > > Thanks, > Vladimir > > On 8/26/13 8:36 PM, David Holmes wrote: >> On 27/08/2013 1:14 PM, Vladimir Kozlov wrote: >>> On 8/26/13 7:13 PM, David Holmes wrote: >>>> Hi Vladimir, >>>> >>>> On 27/08/2013 3:14 AM, Vladimir Kozlov wrote: >>>>> Thank you, David >>>>> >>>>> For me it looks odd when you specify group as not other flags, like: >>>>> >>>>> -group:compact1 >>>>> >>>>> Why it was designed this way? >>>> >>>> Are you referring to the jtreg usage? ie >>>> >>>> jtreg -jdk:xxx -v -r reportdir :compact1 >>> >>> Yes, I asked about that. From the examples in TEST.groups it was not >>> clear how to use them. >>> >>>> >>>> The group is not an option it is a test designator similar to doing: >>> >>> It is not destination from my understanding - it is named list of >>> tests. >> >> Right, a group defines an explicit named list of tests, while gc/ >> "names" a list of tests implicitly by their location >> in the directory structure. Both form the "here are the tests to run" >> arguments to jtreg. >> >>> So I don't see why we can't use it as flag. I understand that I am late >>> and the feature already implemented in jtreg and it is only a matter >>> how >>> jtreg parses command line. But it is unusual to have command parameter >>> starting with :. >> >> jtreg needs to be able to distinguish between the name of a test and >> the name of a group hence : is a group name >> delimiter. Actually the complete syntax allows another designator in >> front of the : >> >> testdir:group >> >> which I believe supports the fact that any testdir can contain a >> TEST.ROOT file which among other things can define the >> group file in which the group definition can be found. >> >> But this is all jtreg stuff :) >> >>>> >>>> jtreg -jdk:xxx -v -r reportdir runtime/NMT gc/ >>> >>> Can you run subsets of tests from a group?: >>> >>> jtreg -jdk:xxx -v -r reportdir :needs_jdk gc >> >> Not at present. A group defines a set of tests, so the above would be >> a union of the tests in group :needs_jdk and the >> tests under directory gc. >> >> I am currently arguing for a way to exclude a group on the command >> line so that you can "subset" to some degree eg: >> >> jtreg gc -:needs_jdk >> >> would run all gc tests except those listed in the needs_jdk group. >> This avoids the need to define composite groups for >> all permutations of tests that you might want to run. >> >> BTW the way jtreg produces the set of tests in a group is to first do >> the union of all included tests and groups, then >> do a union of the excluded tests and groups, and then subtract the >> second set from the first. And each group is >> evaluated in isolation before being used in another group (as opposed >> to logically being inlined and then the result >> evaluated). >> >>>> >>>>> Can ou add jprt group too (as template for now)? We want for long >>>>> time >>>>> to run in JPRT small subset of our jtreg tests which will take less >>>>> 15min. I know, it is separate problem but can you add it as template >>>>> which we can use and extend later? >>>> >>>> Adding this is trivial. The "template" would be: >>>> >>>> jprt = >>>> >>>> There doesn't seem much point in me adding that at this time though. >>>> Better to leave it until we know how it needs to be >>>> defined. >>> >>> Okay. >> >> Thanks. I assume you don't mind being the Reviewer for this? >> >> It would be nice to get a second reviewer too. :) >> >> David >> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 8/25/13 6:45 PM, David Holmes wrote: >>>>>> This change introduces the TEST.groups file to allow jtreg to run >>>>>> regression tests by groups - where the groups are defined to support >>>>>> testing of compact profiles and the minimal VM. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8006164/webrev/ >>>>>> >>>>>> The primary groups are: >>>>>> - jdk >>>>>> - jre >>>>>> - compact3 >>>>>> - compact2 >>>>>> - compact2_minimal >>>>>> - compact1 >>>>>> - compact1_minimal >>>>>> >>>>>> The minimal VM is only supported on compact1 and compact2. >>>>>> >>>>>> To select a group of tests you use : >>>>>> >>>>>> Eg to run only those tests that can run on compact1 use: >>>>>> >>>>>> jtreg :compact1 >>>>>> >>>>>> Of course you still need to point jtreg at the right kind of runtime >>>>>> image (and give it a full JDK as the compile-jdk!); and if >>>>>> testing the >>>>>> minimal VM you need to tell jtreg to select it using >>>>>> -javaoptions:-minimal >>>>>> >>>>>> The full jtreg group facility is only available in the most recent >>>>>> jtreg >>>>>> builds, so you will need to grab the latest nightly build, or latest >>>>>> sources. >>>>>> >>>>>> It is expected that these group definitions will need some >>>>>> tweaking. So >>>>>> far testing has been limited to linux, but we want to get this in >>>>>> ASAP >>>>>> to extend the testing. >>>>>> >>>>>> Note: once this is in place, anyone writing regression tests will >>>>>> need >>>>>> to be aware of whether that test is limited to certain profiles and >>>>>> update the group file accordingly. Sometimes it is not the item >>>>>> being >>>>>> tested that determines the minimum needed profile, but the test >>>>>> infrastructure eg if it uses XML. >>>>>> >>>>>> The changeset will be pushed via hotspot-embas that is what is >>>>>> used for >>>>>> profile testing. >>>>>> >>>>>> Thanks, >>>>>> David > > From daniel.daugherty at oracle.com Tue Aug 27 18:49:57 2013 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 28 Aug 2013 01:49:57 +0000 Subject: hg: hsx/hotspot-main/hotspot: 17 new changesets Message-ID: <20130828015037.4E85F48C04@hg.openjdk.java.net> Changeset: c6ec0a97b30a Author: sla Date: 2013-08-21 13:18 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c6ec0a97b30a 8022808: Kitchensink hangs on macos Summary: Use pthread_mach_thread_np() instead of mach_thread_self() to avoid leaking resources Reviewed-by: dholmes, rbackman ! src/os/bsd/vm/os_bsd.cpp Changeset: 3a57fa7a4cd0 Author: hseigel Date: 2013-08-22 11:52 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/3a57fa7a4cd0 7121403: [TESTBUG] runtime/7051189/Xchecksig.sh fails on 64bit solaris 8023393: Need to suppress info message if -Xcheck:jni used with libjsig.dylab on Mac OSX Summary: Rewrite 7051189 test in Java, port Linux fix for 7051189 to Mac OSX. Reviewed-by: coleenp, dholmes, mseledtsov, ccheung ! src/os/bsd/vm/os_bsd.cpp - test/runtime/7051189/Xchecksig.sh + test/runtime/XCheckJniJsig/XCheckJSig.java Changeset: e37ab280bbce Author: allwin Date: 2013-07-23 14:32 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/e37ab280bbce 8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__" Reviewed-by: sla, sundar, kmo Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js Changeset: 669d9a235486 Author: sla Date: 2013-08-22 14:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/669d9a235486 Merge Changeset: c062a6e1fa33 Author: iklam Date: 2013-08-22 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c062a6e1fa33 8023406: make/windows/build_vm_def.sh takes too long even when BUILD_WIN_SA != 1 Summary: Avoid dumping C++ vtable when BUILD_WIN_SA != 1 Reviewed-by: dcubed, sla, tbell ! make/windows/build_vm_def.sh ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make Changeset: 811aea34d5e7 Author: iklam Date: 2013-08-22 13:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/811aea34d5e7 Merge Changeset: ff2520b97b00 Author: jiangli Date: 2013-08-22 19:27 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ff2520b97b00 8023547: com/sun/jdi/RedefineMulti.sh fails with IllegalArgumentException after JDK-8021948 . Summary: Need to check if the constant pool mapping returns 0. Reviewed-by: coleenp, sspitsyn ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 887db75613f8 Author: jiangli Date: 2013-08-22 17:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/887db75613f8 Merge Changeset: a70566600baf Author: poonam Date: 2013-08-21 22:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/a70566600baf 8020530: Non heap memory size calculated incorrectly Reviewed-by: coleenp, sla Contributed-by: vladimir.kempik at oracle.com ! src/share/vm/services/management.cpp Changeset: 730210728146 Author: poonam Date: 2013-08-22 18:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/730210728146 Merge - test/runtime/7051189/Xchecksig.sh Changeset: 817e46dd5864 Author: poonam Date: 2013-08-22 21:23 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/817e46dd5864 Merge Changeset: 739c309fd729 Author: mgronlun Date: 2013-08-23 10:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/739c309fd729 8023457: Event based tracing framework needs a mutex for thread groups Reviewed-by: acorn, sla ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: cacc421f39d7 Author: dcubed Date: 2013-08-23 10:39 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/cacc421f39d7 Merge - test/runtime/7051189/Xchecksig.sh Changeset: badf4244ceae Author: hseigel Date: 2013-08-25 21:21 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/badf4244ceae 8022183: GCC 4.6 change sdefault setting for omit-frame-pointer which breaks hotspot stack walking Summary: Explicitly specify -fno-omit-frame-pointer. Reviewed-by: coleenp, dholmes, dcubed ! make/linux/makefiles/amd64.make ! make/linux/makefiles/gcc.make Changeset: faf2631b9334 Author: dsimms Date: 2013-08-26 09:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/faf2631b9334 8022683: JNI GetStringUTFChars should return NULL on allocation failure not abort the VM Summary: Return NULL on OOM from GetStringChars, GetStringUTFChars and GetArrayElements family of functions. Reviewed-by: dholmes, coleenp ! src/share/vm/memory/allocation.hpp ! src/share/vm/prims/jni.cpp Changeset: 4c84d351cca9 Author: stefank Date: 2013-08-16 13:22 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/4c84d351cca9 8007074: SIGSEGV at ParMarkBitMap::verify_clear() Summary: Replace the broken large pages implementation on Linux. New flag: -XX:+UseTransparentHugePages - Linux specific flag to turn on transparent huge page hinting with madvise(..., MAP_HUGETLB). Changed behavior: -XX:+UseLargePages - tries to use -XX:+UseTransparentHugePages before trying other large pages implementations (on Linux). Changed behavior: -XX:+UseHugeTLBFS - Use upfront allocation of Large Pages instead of using the broken implementation to dynamically committing large pages. Changed behavior: -XX:LargePageSizeInBytes - Turned off the ability to use this flag on Linux and provides warning to user if set to a value different than the OS chosen large page size. Changed behavior: Setting no large page size - Now defaults to use -XX:UseTransparentHugePages if the OS supports it. Previously, -XX:+UseHugeTLBFS was chosen if the OS was configured to use large pages. Reviewed-by: tschatzl, dcubed, brutisso ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 21ffbaa691b5 Author: stefank Date: 2013-08-26 07:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/21ffbaa691b5 Merge ! src/share/vm/prims/jni.cpp From david.holmes at oracle.com Tue Aug 27 19:01:03 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Aug 2013 12:01:03 +1000 Subject: RFR: 8006164 [TESTBUG] compact profile hotspot test issues In-Reply-To: <521D5715.5010606@oracle.com> References: <521AB34A.8020801@oracle.com> <521B8D09.7080101@oracle.com> <521C0B55.5060205@oracle.com> <521C1988.2040009@oracle.com> <521C1ED0.8050306@oracle.com> <521C6981.4030004@oracle.com> <521D5715.5010606@oracle.com> Message-ID: <521D59DF.7020708@oracle.com> On 28/08/2013 11:49 AM, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~dholmes/8006164/webrev/ > > test/TEST.ROOT > No comments. > > test/TEST.groups > Just to be clear: The addition of any new test will require this file > to updated? If so, then we'll have to be careful during reviews. What > happens if a test isn't listed? Is it by default in the 'jdk' group? A new test only has to be explicitly listed if it requires a specific profile, or full JRE or full JDK to run - in which case it must be added to the appropriate needs_xxx group. All tests are initially in the compact1_minimal group (and hence all the 'higher' groups) unless explicitly excluded by being a member of a needs_xxx group. Effective use of this requires some discipline but regardless of the mechanism (groups or tags) when you add a regression test you must now ask yourself "does this test have specific API or VM service dependencies?" - and then answer the question :) One way to answer the API part is to compile the test using the javac -profile option. Eg if: javac -profile compact1 MyTest.java compiles, then it doesn't require a specific profile/jre to run on. The minimal VM issue is harder to determine without actually running on the minimal VM (which by default we don't build for SE). Tests that require the full JDK tend to do so because they use tools (jcmd, jps, etc) that are only in the full JDK - though if such tools can be accessed from the compile-jdk instead then that dependency is removed. > Thumbs up. Thanks! David > Dan > > > On 8/27/13 2:55 AM, Vladimir Kozlov wrote: >> > Thanks. I assume you don't mind being the Reviewer for this? >> >> Yes, it is reviewed. >> >> Thanks, >> Vladimir >> >> On 8/26/13 8:36 PM, David Holmes wrote: >>> On 27/08/2013 1:14 PM, Vladimir Kozlov wrote: >>>> On 8/26/13 7:13 PM, David Holmes wrote: >>>>> Hi Vladimir, >>>>> >>>>> On 27/08/2013 3:14 AM, Vladimir Kozlov wrote: >>>>>> Thank you, David >>>>>> >>>>>> For me it looks odd when you specify group as not other flags, like: >>>>>> >>>>>> -group:compact1 >>>>>> >>>>>> Why it was designed this way? >>>>> >>>>> Are you referring to the jtreg usage? ie >>>>> >>>>> jtreg -jdk:xxx -v -r reportdir :compact1 >>>> >>>> Yes, I asked about that. From the examples in TEST.groups it was not >>>> clear how to use them. >>>> >>>>> >>>>> The group is not an option it is a test designator similar to doing: >>>> >>>> It is not destination from my understanding - it is named list of >>>> tests. >>> >>> Right, a group defines an explicit named list of tests, while gc/ >>> "names" a list of tests implicitly by their location >>> in the directory structure. Both form the "here are the tests to run" >>> arguments to jtreg. >>> >>>> So I don't see why we can't use it as flag. I understand that I am late >>>> and the feature already implemented in jtreg and it is only a matter >>>> how >>>> jtreg parses command line. But it is unusual to have command parameter >>>> starting with :. >>> >>> jtreg needs to be able to distinguish between the name of a test and >>> the name of a group hence : is a group name >>> delimiter. Actually the complete syntax allows another designator in >>> front of the : >>> >>> testdir:group >>> >>> which I believe supports the fact that any testdir can contain a >>> TEST.ROOT file which among other things can define the >>> group file in which the group definition can be found. >>> >>> But this is all jtreg stuff :) >>> >>>>> >>>>> jtreg -jdk:xxx -v -r reportdir runtime/NMT gc/ >>>> >>>> Can you run subsets of tests from a group?: >>>> >>>> jtreg -jdk:xxx -v -r reportdir :needs_jdk gc >>> >>> Not at present. A group defines a set of tests, so the above would be >>> a union of the tests in group :needs_jdk and the >>> tests under directory gc. >>> >>> I am currently arguing for a way to exclude a group on the command >>> line so that you can "subset" to some degree eg: >>> >>> jtreg gc -:needs_jdk >>> >>> would run all gc tests except those listed in the needs_jdk group. >>> This avoids the need to define composite groups for >>> all permutations of tests that you might want to run. >>> >>> BTW the way jtreg produces the set of tests in a group is to first do >>> the union of all included tests and groups, then >>> do a union of the excluded tests and groups, and then subtract the >>> second set from the first. And each group is >>> evaluated in isolation before being used in another group (as opposed >>> to logically being inlined and then the result >>> evaluated). >>> >>>>> >>>>>> Can ou add jprt group too (as template for now)? We want for long >>>>>> time >>>>>> to run in JPRT small subset of our jtreg tests which will take less >>>>>> 15min. I know, it is separate problem but can you add it as template >>>>>> which we can use and extend later? >>>>> >>>>> Adding this is trivial. The "template" would be: >>>>> >>>>> jprt = >>>>> >>>>> There doesn't seem much point in me adding that at this time though. >>>>> Better to leave it until we know how it needs to be >>>>> defined. >>>> >>>> Okay. >>> >>> Thanks. I assume you don't mind being the Reviewer for this? >>> >>> It would be nice to get a second reviewer too. :) >>> >>> David >>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 8/25/13 6:45 PM, David Holmes wrote: >>>>>>> This change introduces the TEST.groups file to allow jtreg to run >>>>>>> regression tests by groups - where the groups are defined to support >>>>>>> testing of compact profiles and the minimal VM. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8006164/webrev/ >>>>>>> >>>>>>> The primary groups are: >>>>>>> - jdk >>>>>>> - jre >>>>>>> - compact3 >>>>>>> - compact2 >>>>>>> - compact2_minimal >>>>>>> - compact1 >>>>>>> - compact1_minimal >>>>>>> >>>>>>> The minimal VM is only supported on compact1 and compact2. >>>>>>> >>>>>>> To select a group of tests you use : >>>>>>> >>>>>>> Eg to run only those tests that can run on compact1 use: >>>>>>> >>>>>>> jtreg :compact1 >>>>>>> >>>>>>> Of course you still need to point jtreg at the right kind of runtime >>>>>>> image (and give it a full JDK as the compile-jdk!); and if >>>>>>> testing the >>>>>>> minimal VM you need to tell jtreg to select it using >>>>>>> -javaoptions:-minimal >>>>>>> >>>>>>> The full jtreg group facility is only available in the most recent >>>>>>> jtreg >>>>>>> builds, so you will need to grab the latest nightly build, or latest >>>>>>> sources. >>>>>>> >>>>>>> It is expected that these group definitions will need some >>>>>>> tweaking. So >>>>>>> far testing has been limited to linux, but we want to get this in >>>>>>> ASAP >>>>>>> to extend the testing. >>>>>>> >>>>>>> Note: once this is in place, anyone writing regression tests will >>>>>>> need >>>>>>> to be aware of whether that test is limited to certain profiles and >>>>>>> update the group file accordingly. Sometimes it is not the item >>>>>>> being >>>>>>> tested that determines the minimum needed profile, but the test >>>>>>> infrastructure eg if it uses XML. >>>>>>> >>>>>>> The changeset will be pushed via hotspot-embas that is what is >>>>>>> used for >>>>>>> profile testing. >>>>>>> >>>>>>> Thanks, >>>>>>> David >> >> > From jon.masamitsu at oracle.com Tue Aug 27 21:22:47 2013 From: jon.masamitsu at oracle.com (jon.masamitsu at oracle.com) Date: Wed, 28 Aug 2013 04:22:47 +0000 Subject: hg: hsx/hotspot-main/hotspot: 5 new changesets Message-ID: <20130828042313.1BECF48C06@hg.openjdk.java.net> Changeset: 1bb10d3170fa Author: jmasa Date: 2013-08-16 06:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1bb10d3170fa 8022817: CMS should not shrink if compaction was not done Reviewed-by: ysr, mgerdin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: f7d3b4387a16 Author: brutisso Date: 2013-08-21 22:35 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f7d3b4387a16 8022872: G1: Use correct GC cause for young GC triggered by humongous allocations Reviewed-by: tonyp, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: c31eb8c86a50 Author: brutisso Date: 2013-08-22 04:14 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c31eb8c86a50 Merge Changeset: ec145d04eda8 Author: jmasa Date: 2013-08-23 15:59 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/ec145d04eda8 Merge Changeset: 1624a68007bd Author: jmasa Date: 2013-08-27 18:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1624a68007bd Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp From Alan.Bateman at oracle.com Wed Aug 28 03:35:03 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 28 Aug 2013 11:35:03 +0100 Subject: RFR: 8006164 [TESTBUG] compact profile hotspot test issues In-Reply-To: <521D56F6.2060909@oracle.com> References: <521AB34A.8020801@oracle.com> <521D56F6.2060909@oracle.com> Message-ID: <521DD257.3010702@oracle.com> On 28/08/2013 02:48, Mandy Chung wrote: > Looks fine to me. Similar change has made into jdk [1]. > > Mandy > [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb18a483e772 Yes although the test groups that we have defined initially in jdk/test/TEST.groups don't cover profiles yet. As to whether to the approach used for the hotspot tests (to list specific tests in the groups file) will scale or be maintainable/acceptable in the jdk repository remains to be seen. -Alan. From david.holmes at oracle.com Wed Aug 28 04:01:14 2013 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Aug 2013 21:01:14 +1000 Subject: RFR 8023900 [TESTBUG] Initial compact profile test groups need adjusting Message-ID: <521DD87A.4060006@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8023900/webrev/ I discovered while working on the JDK test group definitions taht the initial groups defined under 8006164 didn't quite aggregate the primary groups in the right way. The following changes are needed: diff -r 7aa0c1fb6fdb test/TEST.groups --- a/test/TEST.groups +++ b/test/TEST.groups @@ -131,6 +131,7 @@ # Compact 2 adds full VM tests compact2 = \ :compact2_minimal \ + :compact1 \ :needs_full_vm_compact2 \ -:needs_compact3 \ -:needs_jre \ @@ -165,6 +166,7 @@ compact2_minimal = \ :compact1_minimal \ :needs_compact2 \ + -:needs_full_vm_compact2 \ -:needs_compact3 \ -:needs_jre \ -:needs_jdk Because of the minimal groups there is a fork in the dependency tree - so compact2 has to combine with compact1 to ensure it picks up the compact1 tests that require a full VM. And compact2_minimal has to explicitly exclude needs_full_vm_compact2 otherwise it can pull in full VM tests from the needs_compact2 group. Thanks, David From harold.seigel at oracle.com Wed Aug 28 04:51:26 2013 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 28 Aug 2013 07:51:26 -0400 Subject: RFR 8023900 [TESTBUG] Initial compact profile test groups need adjusting In-Reply-To: <521DD87A.4060006@oracle.com> References: <521DD87A.4060006@oracle.com> Message-ID: <521DE43E.3080508@oracle.com> It looks good. Harold On 8/28/2013 7:01 AM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8023900/webrev/ > > I discovered while working on the JDK test group definitions taht the > initial groups defined under 8006164 didn't quite aggregate the > primary groups in the right way. The following changes are needed: > > diff -r 7aa0c1fb6fdb test/TEST.groups > --- a/test/TEST.groups > +++ b/test/TEST.groups > @@ -131,6 +131,7 @@ > # Compact 2 adds full VM tests > compact2 = \ > :compact2_minimal \ > + :compact1 \ > :needs_full_vm_compact2 \ > -:needs_compact3 \ > -:needs_jre \ > @@ -165,6 +166,7 @@ > compact2_minimal = \ > :compact1_minimal \ > :needs_compact2 \ > + -:needs_full_vm_compact2 \ > -:needs_compact3 \ > -:needs_jre \ > -:needs_jdk > > Because of the minimal groups there is a fork in the dependency tree - > so compact2 has to combine with compact1 to ensure it picks up the > compact1 tests that require a full VM. And compact2_minimal has to > explicitly exclude needs_full_vm_compact2 otherwise it can pull in > full VM tests from the needs_compact2 group. > > Thanks, > David From daniel.daugherty at oracle.com Wed Aug 28 07:15:49 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 28 Aug 2013 08:15:49 -0600 Subject: RFR 8023900 [TESTBUG] Initial compact profile test groups need adjusting In-Reply-To: <521DD87A.4060006@oracle.com> References: <521DD87A.4060006@oracle.com> Message-ID: <521E0615.1080209@oracle.com> Thumbs up. Dan On 8/28/13 5:01 AM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8023900/webrev/ > > I discovered while working on the JDK test group definitions taht the > initial groups defined under 8006164 didn't quite aggregate the > primary groups in the right way. The following changes are needed: > > diff -r 7aa0c1fb6fdb test/TEST.groups > --- a/test/TEST.groups > +++ b/test/TEST.groups > @@ -131,6 +131,7 @@ > # Compact 2 adds full VM tests > compact2 = \ > :compact2_minimal \ > + :compact1 \ > :needs_full_vm_compact2 \ > -:needs_compact3 \ > -:needs_jre \ > @@ -165,6 +166,7 @@ > compact2_minimal = \ > :compact1_minimal \ > :needs_compact2 \ > + -:needs_full_vm_compact2 \ > -:needs_compact3 \ > -:needs_jre \ > -:needs_jdk > > Because of the minimal groups there is a fork in the dependency tree - > so compact2 has to combine with compact1 to ensure it picks up the > compact1 tests that require a full VM. And compact2_minimal has to > explicitly exclude needs_full_vm_compact2 otherwise it can pull in > full VM tests from the needs_compact2 group. > > Thanks, > David From mandy.chung at oracle.com Wed Aug 28 10:03:37 2013 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 28 Aug 2013 10:03:37 -0700 Subject: RFR 8023900 [TESTBUG] Initial compact profile test groups need adjusting In-Reply-To: <521DD87A.4060006@oracle.com> References: <521DD87A.4060006@oracle.com> Message-ID: <521E2D69.7000509@oracle.com> Looks good. Mandy On 8/28/2013 4:01 AM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8023900/webrev/ > > I discovered while working on the JDK test group definitions taht the > initial groups defined under 8006164 didn't quite aggregate the > primary groups in the right way. The following changes are needed: > > diff -r 7aa0c1fb6fdb test/TEST.groups > --- a/test/TEST.groups > +++ b/test/TEST.groups > @@ -131,6 +131,7 @@ > # Compact 2 adds full VM tests > compact2 = \ > :compact2_minimal \ > + :compact1 \ > :needs_full_vm_compact2 \ > -:needs_compact3 \ > -:needs_jre \ > @@ -165,6 +166,7 @@ > compact2_minimal = \ > :compact1_minimal \ > :needs_compact2 \ > + -:needs_full_vm_compact2 \ > -:needs_compact3 \ > -:needs_jre \ > -:needs_jdk > > Because of the minimal groups there is a fork in the dependency tree - > so compact2 has to combine with compact1 to ensure it picks up the > compact1 tests that require a full VM. And compact2_minimal has to > explicitly exclude needs_full_vm_compact2 otherwise it can pull in > full VM tests from the needs_compact2 group. > > Thanks, > David From david.holmes at oracle.com Wed Aug 28 23:55:23 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 29 Aug 2013 06:55:23 +0000 Subject: hg: hsx/hotspot-main/hotspot: 8 new changesets Message-ID: <20130829065543.4724362397@hg.openjdk.java.net> Changeset: f92b82d454fa Author: bpittore Date: 2013-08-23 20:33 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/f92b82d454fa 8014135: The JVMTI specification does not conform to recent changes in JNI specification Summary: Added support for statically linked agents Reviewed-by: sspitsyn, bobv, coleenp ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp Changeset: 5fd8e2fbafd4 Author: cjplummer Date: 2013-08-23 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/5fd8e2fbafd4 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not supported Summary: Make tests query a new WhiteBox API to see if NMT detail is supported, and behave properly if it is not supported. Reviewed-by: dholmes, coleenp ! src/share/vm/prims/whitebox.cpp ! test/runtime/NMT/ThreadedVirtualAllocTestType.java ! test/runtime/NMT/VirtualAllocTestType.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 7aa0c1fb6fdb Author: dholmes Date: 2013-08-27 22:05 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/7aa0c1fb6fdb 8006164: [TESTBUG] compact profile hotspot test issues Summary: Define profile-based test groups. Reviewed-by: dcubed, mchung ! test/TEST.ROOT + test/TEST.groups Changeset: 1fedf3c7f923 Author: bpittore Date: 2013-08-28 14:44 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/1fedf3c7f923 8023580: Add jtreg test for 8004051 and 8005722 Summary: Tests checks an assertion dealing with the number of args passed in registers Reviewed-by: mseledtsov, kvn + test/compiler/8004051/Test8004051.java Changeset: b1fb293d92c4 Author: jiangli Date: 2013-08-28 12:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b1fb293d92c4 Merge Changeset: 2b113b65a051 Author: dholmes Date: 2013-08-28 19:25 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/2b113b65a051 8023900: [TESTBUG] Initial compact profile test groups need adjusting Reviewed-by: dcubed, mchung, hseigel ! test/TEST.groups Changeset: 54dfd798deaf Author: dholmes Date: 2013-08-28 21:42 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/54dfd798deaf Merge Changeset: 62f527c674d2 Author: dholmes Date: 2013-08-29 00:22 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/62f527c674d2 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp From dmitry.samersoff at oracle.com Thu Aug 29 04:47:10 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 29 Aug 2013 15:47:10 +0400 Subject: RR(XS): JDK-8022617 Openjdk hotspot build is broken on BSD platforms using gcc In-Reply-To: <521F2746.1010507@oracle.com> References: <521E0031.3050604@oracle.com> <521E98AE.3020206@oracle.com> <521F0FD8.5040008@oracle.com> <521F2746.1010507@oracle.com> Message-ID: <521F34BE.1060209@oracle.com> David, On 2013-08-29 14:49, David Holmes wrote: > This needs to be reviewed by the hotspot group. Added to CC > > I don't understand your change given we already had: > > AS = $(CC) -c -x assembler-with-cpp It's guarded by: >> # If a SPEC is not set already, then use these defaults. >> ifeq ($(SPEC),) as configure sets SPEC, this line is ignored. > Isn't this something that was fixed very recently? > > Your change, as far as I can see, will also add the assembler-with-cpp > to clang not just gcc. It's intentional, according to my experiments clang supports this option as well. -Dmitry > > ??? > > David > > On 29/08/2013 7:09 PM, Dmitry Samersoff wrote: >> David, >> >> Thank you for the comments. >> >> Please, take a look to updated webrev: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.03/ >> >> -Dmitry >> >> On 2013-08-29 04:41, David Holmes wrote: >>> Dmitry, >>> >>> I don't think this is something that should be handled at the configure >>> level. Hotspot compiler flags are handled in the hotspot makefiles. This >>> should be in gcc.make. >>> >>> BTW your changeset should include the generated-configure.sh file not >>> configure. And you would also need to regenerate and push the closed >>> generated-configure.sh file. >>> >>> David >>> >>> On 28/08/2013 11:50 PM, Dmitry Samersoff wrote: >>>> Hi Everyone, >>>> >>>> Please review small fix >>>> >>>> webrev: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.02/ >>>> >>>> CR: >>>> >>>> http://bugs.sun.com/view_bug.do?bug_id=8022617 >>>> >>>> >>>> Gory details: >>>> >>>> bsd_x86_64.s use macro to deal with OS X specific things. >>>> >>>> llvm-gcc preprocess .s and .S files and doesn't support .sx extension >>>> recommended by GNU for case insensitive filesystem. >>>> >>>> Other operating systems doesn't preprocess .s files, so >>>> bsd_x86_64.s >>>> couldn't be compiled on other bsd systems. >>>> >>>> This patch enforce of preprocessing of all assembly sources by >>>> command line options (-x assembler-with-cpp). >>>> >>>> -Dmitry >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From john.coomes at oracle.com Thu Aug 29 10:32:38 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 29 Aug 2013 17:32:38 +0000 Subject: hg: hsx/hotspot-main: 6 new changesets Message-ID: <20130829173238.D6033623C3@hg.openjdk.java.net> Changeset: 00dcfaa6bc01 Author: aefimov Date: 2013-08-16 18:40 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/00dcfaa6bc01 8021820: Number of opened files used in select() is limited to 1024 [macosx] Reviewed-by: alanb, chegar, tbell, smarks ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 Changeset: e8a3edda1f60 Author: lana Date: 2013-08-20 17:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/e8a3edda1f60 Merge Changeset: 056398db9dcb Author: lana Date: 2013-08-23 14:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/056398db9dcb Merge ! common/autoconf/generated-configure.sh Changeset: f8405a0fa69c Author: erikj Date: 2013-08-26 13:43 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/f8405a0fa69c 8023216: Feedback on README-builds.html Reviewed-by: anthony, robilad, tbell ! README-builds.html Changeset: 5166118c5917 Author: katleman Date: 2013-08-26 17:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/5166118c5917 Merge Changeset: 246cdbaa6c62 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/rev/246cdbaa6c62 Added tag jdk8-b105 for changeset 5166118c5917 ! .hgtags From john.coomes at oracle.com Thu Aug 29 10:32:47 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 29 Aug 2013 17:32:47 +0000 Subject: hg: hsx/hotspot-main/corba: Added tag jdk8-b105 for changeset 4e38de7c767e Message-ID: <20130829173251.03804623C4@hg.openjdk.java.net> Changeset: 2e3a056c84a7 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/corba/rev/2e3a056c84a7 Added tag jdk8-b105 for changeset 4e38de7c767e ! .hgtags From john.coomes at oracle.com Thu Aug 29 10:33:01 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 29 Aug 2013 17:33:01 +0000 Subject: hg: hsx/hotspot-main/jaxp: 5 new changesets Message-ID: <20130829173321.0063F623C5@hg.openjdk.java.net> Changeset: 4e23bc205d9d Author: joehw Date: 2013-08-09 12:10 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/4e23bc205d9d 8022548: SPECJVM2008 has errors introduced in 7u40-b34 Reviewed-by: chegar, lancea ! src/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java Changeset: 9800647936dd Author: lana Date: 2013-08-13 18:28 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/9800647936dd Merge Changeset: d4d6422ec564 Author: lana Date: 2013-08-20 17:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/d4d6422ec564 Merge Changeset: 09a46ec11f88 Author: lana Date: 2013-08-23 14:09 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/09a46ec11f88 Merge Changeset: d3be8e3b429d Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxp/rev/d3be8e3b429d Added tag jdk8-b105 for changeset 09a46ec11f88 ! .hgtags From john.coomes at oracle.com Thu Aug 29 10:33:32 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 29 Aug 2013 17:33:32 +0000 Subject: hg: hsx/hotspot-main/jaxws: Added tag jdk8-b105 for changeset 88390df7ed2c Message-ID: <20130829173340.90B28623C6@hg.openjdk.java.net> Changeset: 01be6f93d0a4 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jaxws/rev/01be6f93d0a4 Added tag jdk8-b105 for changeset 88390df7ed2c ! .hgtags From john.coomes at oracle.com Thu Aug 29 10:36:37 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 29 Aug 2013 17:36:37 +0000 Subject: hg: hsx/hotspot-main/jdk: 98 new changesets Message-ID: <20130829180607.AABC2623C8@hg.openjdk.java.net> Changeset: 2722f4000b65 Author: jgodinez Date: 2013-08-15 11:56 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2722f4000b65 8023045: [MacOSX] PrinterIOException when printing a JComponent Reviewed-by: bae, jchen ! src/share/classes/sun/print/PSPrinterJob.java Changeset: b44ce67c0565 Author: vadim Date: 2013-08-16 15:57 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b44ce67c0565 8013446: [parfait] Memory leak in jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c Reviewed-by: bae, prr ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c Changeset: dadd43e02a79 Author: prr Date: 2013-08-19 03:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/dadd43e02a79 8017580: Crash in font loading code on Linux (due to use of reflection) Reviewed-by: bae, vadim ! src/share/native/sun/font/sunFont.c ! src/share/native/sun/font/sunfontids.h Changeset: 0c950b2be7ab Author: jgodinez Date: 2013-08-19 11:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0c950b2be7ab 8022241: [macosx] [PIT] lookupPrintServices() returns one too long array Reviewed-by: prr, jchen ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: 64be71ae6185 Author: lana Date: 2013-08-20 17:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/64be71ae6185 Merge Changeset: 903a279f1fce Author: ant Date: 2013-08-09 05:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/903a279f1fce 8013611: Modal dialog fails to obtain keyboard focus Reviewed-by: leonidr ! src/share/classes/java/awt/KeyboardFocusManager.java + test/java/awt/Focus/8013611/JDK8013611.java Changeset: 2cd1a041381b Author: alexsch Date: 2013-08-09 14:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2cd1a041381b 7121409: Two conformance tests for AccessibleText.getCharacterBounds(int i) fail Reviewed-by: serb ! src/share/classes/javax/swing/JLabel.java Changeset: 4702ab74b70a Author: serb Date: 2013-08-13 15:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/4702ab74b70a 7027045: (doc) java/awt/Window.java has several typos in javadoc Reviewed-by: art, serb Contributed-by: konstantin.perikov at gmail.com ! src/share/classes/java/awt/Window.java Changeset: 149bf2400fa1 Author: lana Date: 2013-08-13 15:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/149bf2400fa1 Merge - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh Changeset: c5db3ec83cba Author: pchelko Date: 2013-08-14 16:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c5db3ec83cba 8013454: [parfait] Memory leak in jdk/src/windows/native/sun/windows/awt_Cursor.cpp 8012079: [parfait] possible null pointer dereference in jdk/src/windows/native/sun/windows/awt_Font.cpp Reviewed-by: art, serb ! src/windows/native/sun/windows/awt_Cursor.cpp ! src/windows/native/sun/windows/awt_Font.cpp Changeset: 1d6ce0070fd3 Author: pchelko Date: 2013-08-14 17:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1d6ce0070fd3 7173464: Clipboard.getAvailableDataFlavors: Comparison method violates contract Reviewed-by: anthony, art, serb ! src/share/classes/sun/awt/datatransfer/ClipboardTransferable.java ! src/share/classes/sun/awt/datatransfer/DataTransferer.java + test/sun/awt/datatransfer/DataFlavorComparatorTest.java Changeset: 3930a827160a Author: leonidr Date: 2013-08-15 01:17 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3930a827160a 8022997: [macosx] Remaining duplicated key events Reviewed-by: anthony, serb ! src/macosx/native/sun/awt/CMenuItem.m ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: d7a34d7e7f22 Author: alitvinov Date: 2013-08-15 14:20 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d7a34d7e7f22 7191018: Manual test closed/java/awt/JAWT causes JVM to crash starting from JDK 5 Reviewed-by: anthony, serb ! src/solaris/native/sun/awt/awt_DrawingSurface.c Changeset: c089e93e6444 Author: serb Date: 2013-08-16 16:52 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c089e93e6444 8020051: [TEST_BUG] Testcase for 8004859 has a typo Reviewed-by: anthony ! test/java/awt/Graphics2D/Test8004859/Test8004859.java Changeset: e3316cd6ca47 Author: serb Date: 2013-08-16 20:56 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e3316cd6ca47 8006085: [findbugs] a warning on javax.sound.sampled.DataLine$Info constructor Reviewed-by: art, prr ! src/share/classes/javax/sound/sampled/DataLine.java Changeset: 64dc24e0d577 Author: serb Date: 2013-08-16 21:18 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/64dc24e0d577 8005980: [findbugs] More com.sun.media.sound.* warnings Reviewed-by: art, prr ! src/share/classes/com/sun/media/sound/DataPusher.java ! src/share/classes/com/sun/media/sound/ModelStandardDirector.java ! src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java ! src/share/classes/com/sun/media/sound/SoftMixingClip.java ! src/share/classes/sun/audio/AudioData.java Changeset: fefa29e15a14 Author: lana Date: 2013-08-20 17:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/fefa29e15a14 Merge Changeset: 0beaa65c90c8 Author: okutsu Date: 2013-08-08 13:51 +0900 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0beaa65c90c8 8015986: Incorrect Localization of HijrahChronology Reviewed-by: naoto Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/CalendarType.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java Changeset: 2c4f1081a0fa Author: uta Date: 2013-08-08 09:16 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2c4f1081a0fa 7147084: (process) appA hangs when read output stream of appB which starts appC that runs forever Reviewed-by: alanb, robm, martin ! src/windows/classes/java/lang/ProcessImpl.java ! src/windows/native/java/lang/ProcessImpl_md.c + test/java/lang/ProcessBuilder/InheritIOEHandle.java + test/java/lang/ProcessBuilder/SiblingIOEHandle.java Changeset: b7d594716f86 Author: weijun Date: 2013-08-08 21:13 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b7d594716f86 8016594: Native Windows ccache still reads DES tickets Reviewed-by: dsamersoff, xuelei ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/native/sun/security/krb5/nativeccache.c ! src/windows/native/sun/security/krb5/NativeCreds.c Changeset: a388263a7287 Author: sherman Date: 2013-08-08 12:03 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a388263a7287 8015666: test/tools/pack200/TimeStamp.java failing Summary: to keep the default behavior of ZOS unchanged, if ze extra time not explicitly set Reviewed-by: alanb, ksrini ! src/share/classes/java/util/zip/ZipConstants.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/java/util/zip/ZipUtils.java ! test/ProblemList.txt ! test/java/util/zip/TestExtraTime.java ! test/tools/pack200/TimeStamp.java Changeset: 67edbf7e6b26 Author: juh Date: 2013-08-08 17:06 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/67edbf7e6b26 8022461: Fix lint warnings in sun.security.{provider,rsa,x509} Reviewed-by: darcy, weijun, xuelei, mullan ! src/share/classes/sun/security/provider/DSAPublicKey.java ! src/share/classes/sun/security/rsa/RSAPublicKeyImpl.java ! src/share/classes/sun/security/rsa/RSASignature.java ! src/share/classes/sun/security/x509/AlgIdDSA.java ! src/share/classes/sun/security/x509/X509Key.java Changeset: 758e3117899c Author: weijun Date: 2013-08-09 11:41 +0800 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/758e3117899c 8021788: JarInputStream doesn't provide certificates for some file under META-INF Reviewed-by: chegar, sherman ! src/share/classes/java/util/jar/JarVerifier.java + test/java/util/jar/JarInputStream/ExtraFileInMetaInf.java Changeset: 54f0ccdd9ad7 Author: sherman Date: 2013-08-08 23:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/54f0ccdd9ad7 6614237: missing codepage Cp290 at java runtime Summary: to add charset Cp290 and Cp300 Reviewed-by: okutsu + make/tools/CharsetMapping/IBM290.c2b + make/tools/CharsetMapping/IBM290.map + make/tools/CharsetMapping/IBM300.c2b + make/tools/CharsetMapping/IBM300.map ! make/tools/CharsetMapping/dbcs ! make/tools/CharsetMapping/extsbcs ! make/tools/src/build/tools/charsetmapping/DBCS.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java Changeset: c29ca19cb816 Author: psandoz Date: 2013-08-09 11:44 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c29ca19cb816 8022326: Spliterator for values of j.u.c.ConcurrentSkipListMap does not report ORDERED Reviewed-by: martin, chegar ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java Changeset: 84004d0e3fdd Author: chegar Date: 2013-08-09 13:50 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/84004d0e3fdd 8022661: InetAddress.writeObject() performs flush() on object output stream Reviewed-by: michaelm, alanb ! src/share/classes/java/net/InetAddress.java Changeset: ce1c874903cb Author: dl Date: 2013-08-09 17:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ce1c874903cb 8022724: lint warnings in j.u.concurrent packages Reviewed-by: chegar, lancea, darcy ! src/share/classes/java/util/concurrent/CompletableFuture.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/atomic/Striped64.java Changeset: 03822f2389bf Author: dxu Date: 2013-08-09 10:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/03822f2389bf 8021977: Opening a file using java.io can throw IOException on Windows Summary: Remove IOException related error-handling code for backward compatibility Reviewed-by: alanb, lancea, mr ! src/windows/native/java/io/io_util_md.c Changeset: a7c341f30747 Author: sherman Date: 2013-08-09 12:40 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a7c341f30747 8020054: (tz) Support tzdata2013d Summary: update the jdk8 tz data to version 2013d Reviewed-by: coffeys, peytoia ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/factory ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/pacificnew ! make/sun/javazic/tzdata/solar87 ! make/sun/javazic/tzdata/solar88 ! make/sun/javazic/tzdata/solar89 ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/systemv ! make/sun/javazic/tzdata/zone.tab ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/backward ! test/sun/util/calendar/zi/tzdata/etcetera ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/factory ! test/sun/util/calendar/zi/tzdata/iso3166.tab ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/pacificnew ! test/sun/util/calendar/zi/tzdata/solar87 ! test/sun/util/calendar/zi/tzdata/solar88 ! test/sun/util/calendar/zi/tzdata/solar89 ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/systemv ! test/sun/util/calendar/zi/tzdata/zone.tab Changeset: 8f01ccb0c981 Author: joehw Date: 2013-08-09 12:53 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8f01ccb0c981 8022548: SPECJVM2008 has errors introduced in 7u40-b34 Reviewed-by: chegar, lancea + test/javax/xml/jaxp/parsers/8022548/JDK8022548.xml + test/javax/xml/jaxp/parsers/8022548/JDK8022548.xsl + test/javax/xml/jaxp/parsers/8022548/TestBase.java + test/javax/xml/jaxp/parsers/8022548/XOMParserTest.java Changeset: ea4f4164422e Author: xuelei Date: 2013-08-11 18:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ea4f4164422e 8022487: DEREncodedKeyValue.supportedKeyTypes should be private Reviewed-by: mullan ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/DEREncodedKeyValue.java Changeset: ffacf3e7a130 Author: mullan Date: 2013-08-12 09:03 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/ffacf3e7a130 8016848: javax_security/auth/login tests fail in compact 1 and 2 profiles Summary: Change the default value of the "login.configuration.provider" security property to sun.security.provider.ConfigFile Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/javax/security/auth/login/Configuration.java + src/share/classes/sun/security/provider/ConfigFile.java - src/share/classes/sun/security/provider/ConfigSpiFile.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: d73fbf005f5f Author: mullan Date: 2013-08-12 09:29 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d73fbf005f5f Merge - src/share/classes/java/net/package.html - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh Changeset: 70c8f4a4b8d6 Author: vromero Date: 2013-08-12 17:40 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/70c8f4a4b8d6 8015780: java/lang/reflect/Method/GenericStringTest.java failing Reviewed-by: darcy, jfranck ! test/ProblemList.txt ! test/java/lang/reflect/Method/GenericStringTest.java Changeset: 7758bcf0ab6b Author: henryjen Date: 2013-08-12 12:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7758bcf0ab6b 8022749: Convert junit tests to testng in test/java/lang/invoke Reviewed-by: mduigou, alanb Contributed-by: Mani Sarkar ! test/java/lang/invoke/AccessControlTest.java ! test/java/lang/invoke/ClassValueTest.java ! test/java/lang/invoke/InvokeGenericTest.java ! test/java/lang/invoke/JavaDocExamplesTest.java ! test/java/lang/invoke/MethodTypeTest.java ! test/java/lang/invoke/PermuteArgsTest.java ! test/java/lang/invoke/ThrowExceptionsTest.java Changeset: cc64a05836a7 Author: lancea Date: 2013-08-12 16:09 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cc64a05836a7 8022753: SQLXML javadoc example typo Reviewed-by: alanb, mchung ! src/share/classes/java/sql/SQLXML.java Changeset: 5b14d702b0b8 Author: ascarpino Date: 2013-08-12 11:25 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5b14d702b0b8 8020081: Cipher with OAEPPadding and OAEPParameterSpec can't be created Reviewed-by: mullan ! src/share/classes/com/sun/crypto/provider/SunJCE.java + test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java Changeset: 818c3f82269c Author: vinnie Date: 2013-08-13 14:15 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/818c3f82269c 8013170: Spec for PBEParameterSpec does not specify behavior when paramSpec is null Reviewed-by: mullan ! src/share/classes/javax/crypto/spec/PBEParameterSpec.java Changeset: 26753a05859a Author: vinnie Date: 2013-08-13 14:18 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/26753a05859a Merge Changeset: 834faf2081b3 Author: bpb Date: 2013-08-12 16:21 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/834faf2081b3 8022180: BigInteger Burnikel-Ziegler quotient and remainder calculation assumes quotient parameter is zero Summary: Clear the quotient in divideAndRemainderBurnikelZiegler() if the divisor is larger than the dividend. Reviewed-by: alanb, bpb Contributed-by: Timothy Buktu ! src/share/classes/java/math/MutableBigInteger.java ! test/java/math/BigInteger/BigIntegerTest.java Changeset: 18e15d92610b Author: chegar Date: 2013-08-13 14:57 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/18e15d92610b 8022779: ProblemList.txt updates (8/2013) Summary: Update ProblemList and remove AggressiveOpts MOAT test run Reviewed-by: chegar, alanb Contributed-by: Amy Lu ! test/ProblemList.txt ! test/java/util/Collection/MOAT.java Changeset: 78c102c3eefc Author: dfuchs Date: 2013-08-13 16:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/78c102c3eefc 8019948: java/util/logging/bundlesearch/ResourceBundleSearchTest.java is failing intermittently Reviewed-by: mchung, dholmes ! test/java/util/logging/bundlesearch/ResourceBundleSearchTest.java Changeset: 412b2f0950a9 Author: mullan Date: 2013-08-13 10:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/412b2f0950a9 8022897: Add test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java to ProblemList Reviewed-by: vinnie, chegar ! test/ProblemList.txt Changeset: 19133b3af95f Author: mullan Date: 2013-08-13 10:07 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/19133b3af95f Merge ! test/ProblemList.txt Changeset: cd9379e348d0 Author: darcy Date: 2013-08-13 10:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cd9379e348d0 8022959: Fix new doclint issues in java.util.zip Reviewed-by: chegar ! src/share/classes/java/util/zip/ZipEntry.java Changeset: a4b0be7341ef Author: robm Date: 2013-08-13 19:10 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a4b0be7341ef 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion Reviewed-by: alanb, dholmes, martin, erikj, coffeys ! make/java/java/Exportedfiles.gmk ! make/java/java/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! src/solaris/classes/java/lang/UNIXProcess.java.bsd ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! src/solaris/classes/java/lang/UNIXProcess.java.solaris ! src/solaris/native/java/lang/UNIXProcess_md.c + src/solaris/native/java/lang/childproc.c + src/solaris/native/java/lang/childproc.h + src/solaris/native/java/lang/jspawnhelper.c ! test/java/lang/ProcessBuilder/Basic.java Changeset: 18ce880b5fb4 Author: lana Date: 2013-08-13 18:33 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/18ce880b5fb4 Merge ! makefiles/CompileNativeLibraries.gmk Changeset: cb74d71fd02f Author: hseigel Date: 2013-08-13 10:56 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/cb74d71fd02f 8022259: MakeClasslist is buggy and its README is out of date. Summary: Fixed bug in FOR loop and updated comments and README Reviewed-by: dholmes, alanb ! make/tools/sharing/README.txt ! make/tools/src/build/tools/makeclasslist/MakeClasslist.java Changeset: f9cf6ecf596c Author: coleenp Date: 2013-08-14 10:14 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f9cf6ecf596c Merge Changeset: bc3cafb17c09 Author: ksrini Date: 2013-08-14 08:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bc3cafb17c09 8022547: [verifier] move DefaultMethodRegressionTests.java to jdk Reviewed-by: acorn + test/vm/verifier/defaultMethods/DefaultMethodRegressionTests.java + test/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java Changeset: 444a7edcf367 Author: darcy Date: 2013-08-14 11:26 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/444a7edcf367 8022990: Fix dep_ann lint warnings in swing code Reviewed-by: alexsch ! src/share/classes/com/sun/java/swing/Painter.java ! src/share/classes/com/sun/java/swing/plaf/nimbus/AbstractRegionPainter.java ! src/share/classes/com/sun/java/swing/plaf/nimbus/NimbusLookAndFeel.java Changeset: c138d1b608e0 Author: sherman Date: 2013-08-14 11:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c138d1b608e0 8022178: System.console() throws IOE on some Windows Summary: to remove the IOE throwing code Reviewed-by: alanb ! src/windows/native/java/io/Console_md.c Changeset: 17dfbb3f60d3 Author: bpb Date: 2013-08-12 10:35 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/17dfbb3f60d3 8022109: Evaluate adding incrementExact, decrementExact, negateExact to java.lang.Math Summary: Add the methods for parameter types int and long. Reviewed-by: mduigou Contributed-by: Brian Burkhalter ! src/share/classes/java/lang/Math.java ! test/java/lang/Math/ExactArithTests.java Changeset: f8af3499c1fb Author: wetmore Date: 2013-08-14 19:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f8af3499c1fb 8023075: JDK-5049299 has broken old make in jdk8 Reviewed-by: katleman ! make/java/java/Makefile Changeset: 2f6523abab08 Author: yhuang Date: 2013-08-14 22:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2f6523abab08 8021121: ISO 4217 Amendment Number 156 Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/sun/util/resources/lv/CurrencyNames_lv_LV.properties ! test/java/util/Currency/tablea1.txt ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 5ff3b55df2d4 Author: alanb Date: 2013-08-15 11:54 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5ff3b55df2d4 8022921: Remove experimental Profile attribute Reviewed-by: mchung, chegar ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java - src/share/classes/java/util/jar/UnsupportedProfileException.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/misc/URLClassPath.java ! src/share/classes/sun/misc/Version.java.template ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/resources/jar.properties - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: b7b0beef5ded Author: alanb Date: 2013-08-15 13:42 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b7b0beef5ded 8015765: TEST_BUG: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failing intermittently Reviewed-by: chegar, dholmes, alanb Contributed-by: yiming.wang at oracle.com ! test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java Changeset: 7d7d553a8c61 Author: igerasim Date: 2013-08-13 13:04 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/7d7d553a8c61 8022584: Memory leak in some NetworkInterface methods Reviewed-by: alanb, dholmes, chegar, michaelm ! src/solaris/native/java/net/NetworkInterface.c + test/java/net/NetworkInterface/MemLeakTest.java Changeset: 3223342fb76e Author: dl Date: 2013-08-15 15:01 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3223342fb76e 8023103: FJ parallelism zero 8020537: java/util/concurrent/forkjoin/ThrowingRunnable.java Reviewed-by: chegar, mduigou, alanb ! src/share/classes/java/util/concurrent/ForkJoinPool.java Changeset: b07b19182e40 Author: dl Date: 2013-08-15 15:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b07b19182e40 8023104: ConcurrentHashMap typo Reviewed-by: chegar, mduigou ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java Changeset: e7137695dce3 Author: chegar Date: 2013-08-15 15:16 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e7137695dce3 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress Reviewed-by: smarks, alanb, michaelm, darcy ! src/share/classes/java/net/DatagramPacket.java Changeset: 6c307b4d0dd8 Author: sherman Date: 2013-08-15 10:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/6c307b4d0dd8 7154662: {CRC32, Adler32}.update(byte[] b, int off, int len): undocumented ArrayIndexOutOfBoundsException Summary: to add the throws clause Reviewed-by: alanb, chegar ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java Changeset: b4645069238a Author: vinnie Date: 2013-08-15 19:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b4645069238a 8023108: Remove ShortRSAKey1024.sh from ProblemList.txt Reviewed-by: mullan ! test/ProblemList.txt Changeset: 3211caab58ba Author: vinnie Date: 2013-08-15 19:56 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3211caab58ba Merge Changeset: 5bb196aa183c Author: dxu Date: 2013-08-15 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5bb196aa183c 4858457: File.getCanonicalPath() throws IOException when invoked with "nul" (win) Reviewed-by: alanb ! src/windows/native/java/io/canonicalize_md.c ! test/java/io/File/WinDeviceName.java Changeset: 0d27309a87e0 Author: dxu Date: 2013-08-15 14:11 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0d27309a87e0 8017109: Cleanup overrides warning in src/solaris/classes/sun/print/AttributeClass.java Reviewed-by: jgodinez ! src/solaris/classes/sun/print/AttributeClass.java Changeset: 5649837a4cfa Author: briangoetz Date: 2013-08-12 12:06 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5649837a4cfa 8019401: Collectors.collectingAndThen Reviewed-by: mduigou Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/util/stream/Collectors.java ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java Changeset: 5fe19566b6f0 Author: psandoz Date: 2013-08-16 12:29 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/5fe19566b6f0 8023150: java/util/stream tests no longer compiling following JDK-8019401 Reviewed-by: alanb ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java Changeset: 2eebaff52a94 Author: psandoz Date: 2013-08-16 12:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2eebaff52a94 8012940: More than 50 tests failed in Serialization/DeSerialization testing (test-mangled) Reviewed-by: ksrini + test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java ! test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java Changeset: 02ce5a0e4b98 Author: psandoz Date: 2013-08-16 12:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/02ce5a0e4b98 8022898: java/util/Spliterator/SpliteratorCollisions.java fails in HashableIntSpliteratorWithNull data provider Reviewed-by: henryjen, alanb, rriggs ! test/java/util/Spliterator/SpliteratorCollisions.java Changeset: 737b6c298d81 Author: psandoz Date: 2013-08-13 11:16 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/737b6c298d81 8022797: Clarify spliterator characteristics for collections containing no elements Reviewed-by: alanb, mduigou ! src/share/classes/java/util/Collection.java Changeset: 53819fd0ab61 Author: rriggs Date: 2013-08-16 11:28 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/53819fd0ab61 8022770: java/time/tck/java/time/chrono/TCKChronology.java start failing 8022766: java/time/test/java/time/chrono/TestUmmAlQuraChronology.java failed. Summary: TCKChronology: corrected display name to match update from JDK-8015986 Reviewed-by: alanb ! test/java/time/tck/java/time/chrono/TCKChronology.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java Changeset: d7fc4e149bb8 Author: rriggs Date: 2013-08-16 11:11 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/d7fc4e149bb8 8022193: java/time/test/java/util/TestFormatter.java failed in th locale. Summary: Tests corrected to use fixed locale and not dependent on the environment Reviewed-by: sherman ! src/share/classes/java/util/Formatter.java ! test/java/time/test/java/util/TestFormatter.java Changeset: acaa256e3f7c Author: rriggs Date: 2013-08-16 13:58 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/acaa256e3f7c 8019185: Inconsistency between JapaneseEra start dates and java.util.JapaneseImperialDate Summary: align Meiji start date with lib/calendar.properties to avoid any confusion Reviewed-by: sherman ! src/share/classes/java/time/chrono/JapaneseEra.java Changeset: 9e9f5713b26d Author: psandoz Date: 2013-08-06 14:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9e9f5713b26d 8022318: Document Spliterator characteristics and binding policy of java util concurrent collection impls Reviewed-by: chegar Contributed-by: Martin Buchholz , Paul Sandoz ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.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/DelayQueue.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/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! src/share/classes/java/util/concurrent/package-info.java Changeset: 8e098a29ecd8 Author: egahlin Date: 2013-08-16 17:02 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/8e098a29ecd8 6417702: Graph in Memory tab is not redrawn immediately if changed via 'Chart' combo box Reviewed-by: alanb, jbachorik, sjiang ! src/share/classes/sun/tools/jconsole/MemoryTab.java Changeset: c67cb9d4d51a Author: egahlin Date: 2013-08-16 17:11 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c67cb9d4d51a 6721425: jconsole Makefile clean rule is missing rm of generated Version.java Reviewed-by: alanb, jbachorik ! make/sun/jconsole/Makefile Changeset: 89ef4bcf7b0e Author: egahlin Date: 2013-08-16 16:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/89ef4bcf7b0e 7015157: String "Tabular Navigation" should be rephrased for avoiding mistranslation Reviewed-by: alanb, jbachorik, sjiang ! src/share/classes/sun/tools/jconsole/resources/messages.properties Changeset: 71bad9540825 Author: egahlin Date: 2013-08-16 18:58 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/71bad9540825 6696970: Jconsole becomes unusable if a plugin throws an exception Reviewed-by: mchung, jbachorik + src/share/classes/sun/tools/jconsole/ExceptionSafePlugin.java ! src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/VMPanel.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties Changeset: 11ccaabdb2a8 Author: aefimov Date: 2013-08-16 18:41 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/11ccaabdb2a8 8021820: Number of opened files used in select() is limited to 1024 [macosx] Reviewed-by: alanb, chegar, tbell, smarks + test/java/net/ServerSocket/SelectFdsLimit.java Changeset: f580728b08b4 Author: alanb Date: 2013-08-19 11:04 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f580728b08b4 8023215: test/java/util/Comparator/TypeTest.java not running (failing but reported as passing) Reviewed-by: psandoz ! test/java/util/Comparator/TypeTest.java Changeset: 3647aab7b1d5 Author: psandoz Date: 2013-08-06 14:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/3647aab7b1d5 8014824: Document Spliterator characteristics and binding policy of java util collection impls Reviewed-by: chegar ! src/share/classes/java/util/ArrayDeque.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/LinkedHashSet.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedSet.java ! src/share/classes/java/util/Spliterator.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/Vector.java Changeset: bce5205dbe84 Author: ascarpino Date: 2013-08-14 10:50 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/bce5205dbe84 8022669: OAEPParameterSpec does not work if MGF1ParameterSpec is set to SHA2 algorithms Reviewed-by: mullan ! src/share/classes/sun/security/rsa/RSAPadding.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java Changeset: b40d246d4d81 Author: ascarpino Date: 2013-08-16 12:31 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/b40d246d4d81 8022896: test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java fails Reviewed-by: mullan ! test/ProblemList.txt Changeset: 2fd841fccb2e Author: dxu Date: 2013-08-19 12:38 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/2fd841fccb2e 8023203: Wrap RandomAccessFile.seek native method into a Java helper method Reviewed-by: alanb, chegar ! make/java/java/mapfile-vers ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/io/RandomAccessFile.java ! src/share/native/java/io/RandomAccessFile.c Changeset: f120e2c4b4b1 Author: mullan Date: 2013-08-19 17:17 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/f120e2c4b4b1 8016850: JCK javax.security.auth.Policy tests fail when run in Profiles mode Summary: Move default javax.security.auth.Policy implementation to compact1 profile Reviewed-by: vinnie ! src/share/classes/com/sun/security/auth/PolicyFile.java - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java ! src/share/classes/javax/security/auth/Policy.java + src/share/classes/sun/security/provider/AuthPolicyFile.java + src/share/classes/sun/security/provider/SubjectCodeSource.java Changeset: 096e7c665857 Author: xuelei Date: 2013-08-19 17:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/096e7c665857 8020842: IDN do not throw IAE when hostname ends with a trailing dot Reviewed-by: weijun, michaelm ! src/share/classes/java/net/IDN.java + test/java/net/IDN/IllegalArg.java + test/sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java Changeset: 21a25911f7f7 Author: xuelei Date: 2013-08-19 18:49 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/21a25911f7f7 8023230: The impl of KerberosClientKeyExchange maybe not exist Reviewed-by: weijun ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java Changeset: 53ea4b5cef9b Author: sla Date: 2013-08-20 08:59 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/53ea4b5cef9b 8022071: Some vm/jvmti tests fail because cannot attach to the Java virtual machine Reviewed-by: erikj, sspitsyn ! makefiles/CompileNativeLibraries.gmk + makefiles/mapfiles/libattach/reorder-windows-x86 + makefiles/mapfiles/libattach/reorder-windows-x86_64 ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c Changeset: e17da8b09f5e Author: dholmes Date: 2013-08-20 03:18 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/e17da8b09f5e 8023311: Clean up profile-includes.txt Reviewed-by: alanb ! makefiles/profile-includes.txt Changeset: 961cdea684b5 Author: sla Date: 2013-08-20 16:53 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/961cdea684b5 8016727: test/com/sun/jdi/sde/TemperatureTableTest.java failing intermittently Reviewed-by: alanb ! test/com/sun/jdi/sde/TemperatureTableTest.java Changeset: c17d6543b30f Author: psandoz Date: 2013-08-20 17:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/c17d6543b30f 8023367: Collections.emptyList().sort((Comparator)null) throws NPE Reviewed-by: alanb, mduigou ! src/share/classes/java/util/Collections.java ! test/java/util/Collection/ListDefaults.java Changeset: 1ccc7bbee0bb Author: attila Date: 2013-08-20 11:15 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1ccc7bbee0bb 8023250: Update JavaScript code in JDK for changes in iteration over Java arrays Reviewed-by: sundar, sla ! src/share/classes/com/sun/tools/hat/resources/hat.js Changeset: a79fcf53195f Author: lana Date: 2013-08-20 17:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/a79fcf53195f Merge - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java - src/share/classes/java/util/jar/UnsupportedProfileException.java - src/share/classes/sun/security/provider/ConfigSpiFile.java - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: 9626ba160e3d Author: lana Date: 2013-08-23 14:14 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/9626ba160e3d Merge - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java - src/share/classes/java/util/jar/UnsupportedProfileException.java - src/share/classes/sun/security/provider/ConfigSpiFile.java - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: 0417358184a1 Author: omajid Date: 2013-08-22 16:00 -0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/0417358184a1 8023480: Create a jvm.cfg for zero on 32 bit architectures Reviewed-by: dholmes, erikj ! makefiles/CopyFiles.gmk Changeset: 1fe211ae3d2b Author: katleman Date: 2013-08-26 17:36 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1fe211ae3d2b Merge Changeset: 1a2a8d143583 Author: cl Date: 2013-08-29 09:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/1a2a8d143583 Added tag jdk8-b105 for changeset 1fe211ae3d2b ! .hgtags From john.coomes at oracle.com Thu Aug 29 11:09:52 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 29 Aug 2013 18:09:52 +0000 Subject: hg: hsx/hotspot-main/langtools: 29 new changesets Message-ID: <20130829181141.ADD15623C9@hg.openjdk.java.net> Changeset: b8610a65fbf9 Author: vromero Date: 2013-08-08 11:49 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b8610a65fbf9 8019486: javac, generates erroneous LVT for a test case with lambda code Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/T8019486/WrongLVTForLambdaTest.java Changeset: d601238641e6 Author: ksrini Date: 2013-08-09 15:01 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/d601238641e6 8022161: javac Null Pointer Exception in Enter.visitTopLevel Reviewed-by: jjg, vromero, jlahoda ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! test/tools/javac/TestPkgInfo.java Changeset: 0d9bc764cac7 Author: vromero Date: 2013-08-10 13:27 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0d9bc764cac7 8009640: -profile does not work when -bootclasspath specified Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java Changeset: 8f282dc58dfc Author: vromero Date: 2013-08-10 16:26 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/8f282dc58dfc 8022622: javac, two tests are failing with compile time error after class Collector was modified Reviewed-by: mcimadamore ! test/tools/javac/lambda/TargetType59.java ! test/tools/javac/lambda/TargetType62.java Changeset: aa6c6f8b5622 Author: vromero Date: 2013-08-10 16:29 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/aa6c6f8b5622 6983297: methods missing from NewArrayTree Reviewed-by: jjg ! src/share/classes/com/sun/source/tree/NewArrayTree.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! test/tools/javac/tree/SourceTreeScannerTest.java Changeset: f7f271bd74a2 Author: mcimadamore Date: 2013-08-12 17:25 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f7f271bd74a2 6537020: JCK tests: a compile-time error should be given in case of ambiguously imported fields (types, methods) Summary: Hiding check does not support interface multiple inheritance Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.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/comp/Resolve.java ! test/tools/javac/4980495/static/Test.out ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java + test/tools/javac/staticImport/6537020/T6537020.java + test/tools/javac/staticImport/6537020/T6537020.out Changeset: af80273f630a Author: mcimadamore Date: 2013-08-12 17:28 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/af80273f630a 8021567: Javac doesn't report \"java: reference to method is ambiguous\" any more Summary: Javac incorrectly forgets about constant folding results within lambdas Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/8021567/T8021567.java + test/tools/javac/lambda/8021567/T8021567.out + test/tools/javac/lambda/8021567/T8021567b.java Changeset: 32b6a99cc74e Author: lana Date: 2013-08-13 18:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/32b6a99cc74e Merge Changeset: 0ad781399706 Author: vromero Date: 2013-08-14 10:53 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0ad781399706 8013394: compile of iterator use fails with error \"defined in an inaccessible class or interface\" Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T8013394/CompileErrorWithIteratorTest.java Changeset: 3ab468194f11 Author: ksrini Date: 2013-08-14 07:07 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3ab468194f11 8007517: DefaultMethodRegressionTests.java fail in TL Reviewed-by: jjg, vromero - test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java Changeset: 14faef2b51eb Author: jjg Date: 2013-08-14 16:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/14faef2b51eb 8017191: Javadoc is confused by @link to imported classes outside of the set of generated packages Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java + test/com/sun/javadoc/testSeeTag/TestSeeTag.java + test/com/sun/javadoc/testSeeTag/pkg/Test.java Changeset: fac0d1bb87f2 Author: ksrini Date: 2013-08-14 18:58 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/fac0d1bb87f2 6840442: JavaCompiler.getTask() has incomplete specification for IllegalArgumentException Reviewed-by: jjg ! src/share/classes/javax/tools/JavaCompiler.java Changeset: 3d4f0fa2ad05 Author: bpatel Date: 2013-08-14 21:44 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/3d4f0fa2ad05 8016921: Change the profiles table on overview-summary.html page to a list Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java Changeset: 71b0089b146f Author: erikj Date: 2013-08-15 17:24 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/71b0089b146f 8015145: Smartjavac needs more flexibility with linking to sources Reviewed-by: jjg, ohrstrom ! src/share/classes/com/sun/tools/sjavac/JavacState.java ! src/share/classes/com/sun/tools/sjavac/Main.java ! test/tools/sjavac/SJavac.java Changeset: a6378c19836b Author: vromero Date: 2013-08-16 10:32 +0100 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a6378c19836b 8022053: javac generates unverifiable initializer for nested subclass of local class Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T8022053/UnverifiableInitForNestedLocalClassTest.java Changeset: ec77c7b46c37 Author: jlahoda Date: 2013-08-15 22:33 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/ec77c7b46c37 8015809: More user friendly compile-time errors for uncaught exceptions in lambda expression Summary: Producing individual errors for uncaught undeclared exceptions inside lambda expressions, rather than one error for the whole lambda Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java - test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java + test/tools/javac/lambda/ExceptionsInLambda.java + test/tools/javac/lambda/ExceptionsInLambda.out ! test/tools/javac/lambda/TargetType21.out Changeset: f657d400c736 Author: jlahoda Date: 2013-08-15 22:36 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/f657d400c736 8022508: javac crashes if the generics arity of a base class is wrong Reviewed-by: mcimadamore, vromero ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/generics/8016640/T8016640.java Changeset: 4300c2f5fb1b Author: erikj Date: 2013-08-16 16:00 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/4300c2f5fb1b 8023146: Sjavac test failes in langtools nightly Reviewed-by: mcimadamore, jfranck ! test/tools/sjavac/SJavac.java Changeset: 389eaf6ed973 Author: ksrini Date: 2013-08-19 07:47 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/389eaf6ed973 7071377: Exception when javac -processor is given a class name with invalid postfix Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/processing/errors/TestClassNames.java Changeset: 55da6b3a6940 Author: kizune Date: 2013-08-20 17:34 +0400 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/55da6b3a6940 7182350: Regression in wording of unchecked warning message Reviewed-by: mcimadamore, jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/6758789/T6758789b.out + test/tools/javac/7182350/T7182350.java + test/tools/javac/7182350/T7182350.out ! test/tools/javac/generics/7015430/T7015430_1.out ! test/tools/javac/generics/7015430/T7015430_2.out ! test/tools/javac/generics/7151802/T7151802.out ! test/tools/javac/generics/inference/6718364/T6718364.out ! test/tools/javac/generics/inference/7177306/T7177306a.out Changeset: e811fb09a1dc Author: jfranck Date: 2013-08-20 17:21 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e811fb09a1dc 8019243: AnnotationTypeMismatchException instead of MirroredTypeException Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java + test/tools/javac/processing/errors/EnsureMirroredTypeException/Processor.java + test/tools/javac/processing/errors/EnsureMirroredTypeException/Source.java + test/tools/javac/processing/errors/EnsureMirroredTypeException/Source.out Changeset: 58da1296c6b3 Author: darcy Date: 2013-08-20 12:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/58da1296c6b3 8011043: Warn about use of 1.5 and earlier source and target values Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javadoc/Start.java + test/tools/javac/diags/examples/ObsoleteSourceAndTarget.java Changeset: 0f88e3d3d250 Author: ksrini Date: 2013-08-20 14:15 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/0f88e3d3d250 7179455: tools/javac/processing/model/testgetallmembers/Main.java fails against JDK 7 and JDK 8 Reviewed-by: jjg ! test/tools/javac/processing/model/testgetallmembers/Main.java Changeset: a76dc1b4c299 Author: jjg Date: 2013-08-20 14:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/a76dc1b4c299 8020663: Restructure some properties to facilitate better translation Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java Changeset: 79e341614c50 Author: jjg Date: 2013-08-20 14:55 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/79e341614c50 8022080: javadoc generates invalid HTML in Turkish locale Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclint/HtmlTag.java Changeset: 720992953d43 Author: jjg Date: 2013-08-20 15:12 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/720992953d43 8013887: In class use, some tables are randomly unsorted Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java Changeset: b59a0b4675c9 Author: lana Date: 2013-08-20 17:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/b59a0b4675c9 Merge - test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java Changeset: 375834b5cf08 Author: lana Date: 2013-08-23 14:17 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/375834b5cf08 Merge - test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java Changeset: e431c9bfb171 Author: cl Date: 2013-08-29 09:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/langtools/rev/e431c9bfb171 Added tag jdk8-b105 for changeset 375834b5cf08 ! .hgtags From john.coomes at oracle.com Thu Aug 29 11:12:06 2013 From: john.coomes at oracle.com (john.coomes at oracle.com) Date: Thu, 29 Aug 2013 18:12:06 +0000 Subject: hg: hsx/hotspot-main/nashorn: 23 new changesets Message-ID: <20130829181228.7D9AD623CA@hg.openjdk.java.net> Changeset: 9a3e3bb30db3 Author: attila Date: 2013-08-07 16:38 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/9a3e3bb30db3 8022509: Various Dynalink security enhancements Reviewed-by: jlaskey, hannesw ! src/jdk/internal/dynalink/ChainedCallSite.java ! src/jdk/internal/dynalink/DynamicLinkerFactory.java ! src/jdk/internal/dynalink/beans/ClassString.java ! src/jdk/internal/dynalink/beans/StaticClassLinker.java - src/jdk/internal/dynalink/support/Backport.java ! src/jdk/internal/dynalink/support/ClassMap.java ! src/jdk/internal/dynalink/support/Guards.java ! src/jdk/internal/dynalink/support/Lookup.java ! src/jdk/internal/dynalink/support/TypeConverterFactory.java ! src/jdk/nashorn/internal/runtime/linker/Bootstrap.java Changeset: dd79c04ef7df Author: sundar Date: 2013-08-08 16:38 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/dd79c04ef7df 8022524: Memory leaks in nashorn sources and tests found by jhat analysis Reviewed-by: attila, hannesw ! make/project.properties ! src/jdk/nashorn/internal/codegen/CompileUnit.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/objects/NativeDate.java ! src/jdk/nashorn/internal/objects/NativeJSON.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/runtime/GlobalObject.java ! src/jdk/nashorn/internal/runtime/JSONFunctions.java ! src/jdk/nashorn/internal/runtime/ListAdapter.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/UserAccessorProperty.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! test/script/basic/JDK-8020357.js ! test/src/jdk/nashorn/api/javaaccess/BooleanAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/MethodAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/NumberBoxingTest.java ! test/src/jdk/nashorn/api/javaaccess/ObjectAccessTest.java ! test/src/jdk/nashorn/api/javaaccess/StringAccessTest.java ! test/src/jdk/nashorn/internal/codegen/CompilerTest.java ! test/src/jdk/nashorn/internal/parser/ParserTest.java Changeset: 0d7484bf8597 Author: sundar Date: 2013-08-08 18:19 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0d7484bf8597 Merge - src/jdk/internal/dynalink/support/Backport.java Changeset: 14ea21d58f83 Author: jlaskey Date: 2013-08-08 11:20 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/14ea21d58f83 Merge - src/jdk/internal/dynalink/support/Backport.java Changeset: 47e2b609fe31 Author: sundar Date: 2013-08-09 20:48 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/47e2b609fe31 8022707: Revisit all doPrivileged blocks Reviewed-by: jlaskey, hannesw ! make/project.properties ! src/jdk/nashorn/api/scripting/NashornScriptEngine.java ! src/jdk/nashorn/api/scripting/NashornScriptEngineFactory.java ! src/jdk/nashorn/api/scripting/ScriptObjectMirror.java ! src/jdk/nashorn/internal/objects/Global.java ! src/jdk/nashorn/internal/objects/NativeDebug.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/ECMAErrors.java ! src/jdk/nashorn/internal/runtime/Logging.java ! src/jdk/nashorn/internal/runtime/linker/ClassAndLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterBytecodeGenerator.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterFactory.java ! src/jdk/nashorn/internal/runtime/linker/ReflectionCheckLinker.java ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java Changeset: 01304b0550fb Author: sundar Date: 2013-08-12 14:43 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/01304b0550fb 8022782: publicLookup access failures in ScriptObject, ScriptFunction and ScriptFunction Reviewed-by: lagergren, attila, hannesw ! src/jdk/nashorn/internal/codegen/CompilerConstants.java ! src/jdk/nashorn/internal/runtime/JSType.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/ScriptRuntime.java Changeset: 3c13fba4d727 Author: attila Date: 2013-08-12 12:46 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/3c13fba4d727 8022789: Revisit doPrivileged blocks in Dynalink Reviewed-by: lagergren, sundar ! src/jdk/internal/dynalink/DynamicLinkerFactory.java + src/jdk/internal/dynalink/support/ClassLoaderGetterContextProvider.java ! src/jdk/internal/dynalink/support/ClassMap.java ! src/jdk/internal/dynalink/support/TypeConverterFactory.java Changeset: 0bbaa0ac36ab Author: sundar Date: 2013-08-12 16:52 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/0bbaa0ac36ab 8022614: Please exclude test test/script/trusted/JDK-8020809.js from Nashorn code coverage run Reviewed-by: jlaskey, lagergren ! exclude/exclude_list_cc.txt Changeset: 03ba1cd734c0 Author: hannesw Date: 2013-08-12 13:31 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/03ba1cd734c0 8022731: NativeArguments has wrong implementation of isMapped() Reviewed-by: lagergren, jlaskey ! src/jdk/nashorn/internal/objects/NativeArguments.java + test/script/basic/JDK-8022731.js + test/script/basic/JDK-8022731.js.EXPECTED Changeset: 821b605c7046 Author: sundar Date: 2013-08-12 17:08 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/821b605c7046 8022615: [nightly] Two nashorn print tests fail in nightly builds on Windows Reviewed-by: lagergren, jlaskey ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: f2e1673db03b Author: sundar Date: 2013-08-12 18:16 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f2e1673db03b 8022598: Object.getPrototypeOf should return null for host objects rather than throwing TypeError Reviewed-by: lagergren, jlaskey, attila, hannesw ! src/jdk/nashorn/internal/objects/NativeObject.java + test/script/basic/JDK-8022598.js Changeset: a0807e889be3 Author: sundar Date: 2013-08-12 20:37 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/a0807e889be3 Merge Changeset: 8ecf68b292d0 Author: lana Date: 2013-08-13 18:34 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/8ecf68b292d0 Merge Changeset: bbc4e9d37315 Author: jlaskey Date: 2013-08-12 18:00 -0300 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/bbc4e9d37315 8022676: Confusing error message checking instanceof non-class Reviewed-by: jlaskey, sundar Contributed-by: michael.horowitz at oracle.com ! src/jdk/nashorn/internal/runtime/resources/Messages.properties Changeset: ba507ac08719 Author: sundar Date: 2013-08-14 20:51 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/ba507ac08719 8023026: Array.prototype iterator functions like forEach, reduce should work for Java arrays, lists Reviewed-by: jlaskey, lagergren - src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java + src/jdk/nashorn/internal/runtime/arrays/JavaArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/JavaListIterator.java - src/jdk/nashorn/internal/runtime/arrays/MapIterator.java - src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ReverseJavaArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ReverseJavaListIterator.java - src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java + src/jdk/nashorn/internal/runtime/arrays/ReverseScriptArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ReverseScriptObjectIterator.java + src/jdk/nashorn/internal/runtime/arrays/ScriptArrayIterator.java + src/jdk/nashorn/internal/runtime/arrays/ScriptObjectIterator.java + test/script/basic/JDK-8023026.js + test/script/basic/JDK-8023026.js.EXPECTED Changeset: 09c99b58b81e Author: sundar Date: 2013-08-16 15:04 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/09c99b58b81e 8020355: bind on built-in constructors don't use bound argument values Reviewed-by: lagergren, hannesw ! src/jdk/nashorn/internal/runtime/ScriptFunctionData.java + test/script/basic/JDK-8020355.js Changeset: 1d29d2e27590 Author: hannesw Date: 2013-08-16 13:42 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1d29d2e27590 8019985: Date.parse("2000-01-01T00:00:00.Z") should return NaN Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/parser/DateParser.java + test/script/basic/JDK-8019985.js Changeset: 36fb36217e1d Author: lagergren Date: 2013-08-16 18:51 +0200 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/36fb36217e1d 8023017: SUB missing for widest op == number for BinaryNode Reviewed-by: sundar, jlaskey ! src/jdk/nashorn/internal/codegen/ObjectClassGenerator.java ! src/jdk/nashorn/internal/codegen/ObjectCreator.java ! src/jdk/nashorn/internal/ir/BinaryNode.java ! src/jdk/nashorn/internal/ir/BreakableNode.java ! src/jdk/nashorn/internal/ir/IdentNode.java ! src/jdk/nashorn/internal/ir/LexicalContextNode.java ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeArray.java ! src/jdk/nashorn/internal/parser/Parser.java ! src/jdk/nashorn/internal/runtime/Context.java ! src/jdk/nashorn/internal/runtime/RecompilableScriptFunctionData.java ! src/jdk/nashorn/internal/runtime/ScriptFunction.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayLikeIterator.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethod.java ! src/jdk/nashorn/internal/runtime/linker/BoundDynamicMethodLinker.java ! src/jdk/nashorn/internal/runtime/linker/JavaAdapterClassLoader.java Changeset: bd0174b1a42f Author: sundar Date: 2013-08-19 17:16 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/bd0174b1a42f 8023210: jjs tools should support a mode where it will load few command line scripts and then entering into interactive shell Reviewed-by: hannesw, attila, lagergren, jlaskey ! src/jdk/nashorn/internal/runtime/options/Options.java ! src/jdk/nashorn/tools/Shell.java Changeset: e628aefac504 Author: sundar Date: 2013-08-19 19:37 +0530 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/e628aefac504 Merge - src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java - src/jdk/nashorn/internal/runtime/arrays/MapIterator.java - src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java - src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java Changeset: 1f2394beecf7 Author: lana Date: 2013-08-20 17:46 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/1f2394beecf7 Merge - src/jdk/internal/dynalink/support/Backport.java - src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java - src/jdk/nashorn/internal/runtime/arrays/MapIterator.java - src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java - src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java Changeset: f484bfb624dd Author: lana Date: 2013-08-23 14:18 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/f484bfb624dd Merge - src/jdk/internal/dynalink/support/Backport.java - src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java - src/jdk/nashorn/internal/runtime/arrays/MapIterator.java - src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java - src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java Changeset: 824d33e678f2 Author: cl Date: 2013-08-29 09:42 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/nashorn/rev/824d33e678f2 Added tag jdk8-b105 for changeset f484bfb624dd ! .hgtags From karen.kinnear at oracle.com Thu Aug 29 11:36:32 2013 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 29 Aug 2013 14:36:32 -0400 Subject: CFV: New hsx Committer: Calvin Cheung Message-ID: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> I hereby nominate Calvin Cheung (openjdk username: ccheung) to be an OpenJDK hsx [0] Committer [1]. Calvin joined the hotspot runtime team a year ago after years of working on the java plugin and java webstart. Calvin is currently a committer to jdk6, jdk7, jdk7u and jdk8. As a member of the runtime team, Calvin has contributed multiple changes in serviceability and runtime, cleaning up memory leaks, jvm tracing improvements, fixing signal handling code and fatal errors, including the following 13 changesets which can be seen at [3]. Votes are due Thursday September 12th at 19:00:00 UTC (two week voting period). Only current hsx Committers [0] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2] Regards, Karen Kinnear [0]http://openjdk.java.net/census/#hsx [1]http://openjdk.java.net/bylaws#committer [2]http://openjdk.java.net/projects/#committer-vote [3] list here: >>> hg log -M -u ccheung --template "{desc}\n" | grep "^[0-9]\{7,7\}: " >>> >>> 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error >>> 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases >>> 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code >>> 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed >>> 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 >>> 8014431: cleanup warnings indicated by the -Wunused-value compiler option on linux >>> 8015265: revise the fix for 8007037 >>> 8005849: JEP 167: Event-Based JVM Tracing >>> 8012641: Perf_CreateLong creates perf counter of incorrect type >>> 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" >>> 8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp >>> 8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp >>> 8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c From vladimir.x.ivanov at oracle.com Thu Aug 29 11:41:14 2013 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 29 Aug 2013 22:41:14 +0400 Subject: CFV: New hsx Committer: Calvin Cheung In-Reply-To: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> References: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> Message-ID: <521F95CA.9040805@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 8/29/13 10:36 PM, Karen Kinnear wrote: > I hereby nominate Calvin Cheung (openjdk username: ccheung) to be an OpenJDK hsx > [0] Committer [1]. > > Calvin joined the hotspot runtime team a year ago after years of working on the > java plugin and java webstart. Calvin is currently a committer to jdk6, jdk7, jdk7u and jdk8. > As a member of the runtime team, Calvin has contributed multiple changes in > serviceability and runtime, cleaning up memory leaks, jvm tracing improvements, > fixing signal handling code and fatal errors, including the following 13 changesets which can be seen at [3]. > > Votes are due Thursday September 12th at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > >>>> hg log -M -u ccheung --template "{desc}\n" | grep "^[0-9]\{7,7\}: " >>>> >>>> 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error >>>> 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases >>>> 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code >>>> 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed >>>> 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 >>>> 8014431: cleanup warnings indicated by the -Wunused-value compiler option on linux >>>> 8015265: revise the fix for 8007037 >>>> 8005849: JEP 167: Event-Based JVM Tracing >>>> 8012641: Perf_CreateLong creates perf counter of incorrect type >>>> 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" >>>> 8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp >>>> 8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp >>>> 8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c From serguei.spitsyn at oracle.com Thu Aug 29 11:54:02 2013 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 29 Aug 2013 11:54:02 -0700 Subject: CFV: New hsx Committer: Calvin Cheung In-Reply-To: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> References: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> Message-ID: <521F98CA.5010309@oracle.com> Vote: yes On 8/29/13 11:36 AM, Karen Kinnear wrote: > I hereby nominate Calvin Cheung (openjdk username: ccheung) to be an OpenJDK hsx > [0] Committer [1]. > > Calvin joined the hotspot runtime team a year ago after years of working on the > java plugin and java webstart. Calvin is currently a committer to jdk6, jdk7, jdk7u and jdk8. > As a member of the runtime team, Calvin has contributed multiple changes in > serviceability and runtime, cleaning up memory leaks, jvm tracing improvements, > fixing signal handling code and fatal errors, including the following 13 changesets which can be seen at [3]. > > Votes are due Thursday September 12th at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > >>>> hg log -M -u ccheung --template "{desc}\n" | grep "^[0-9]\{7,7\}: " >>>> >>>> 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error >>>> 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases >>>> 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code >>>> 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed >>>> 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 >>>> 8014431: cleanup warnings indicated by the -Wunused-value compiler option on linux >>>> 8015265: revise the fix for 8007037 >>>> 8005849: JEP 167: Event-Based JVM Tracing >>>> 8012641: Perf_CreateLong creates perf counter of incorrect type >>>> 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" >>>> 8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp >>>> 8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp >>>> 8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c From harold.seigel at oracle.com Thu Aug 29 12:09:46 2013 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 29 Aug 2013 15:09:46 -0400 Subject: CFV: New hsx Committer: Calvin Cheung In-Reply-To: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> References: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> Message-ID: <521F9C7A.8010603@oracle.com> Vote: yes Thanks, Harold On 8/29/2013 2:36 PM, Karen Kinnear wrote: > I hereby nominate Calvin Cheung (openjdk username: ccheung) to be an OpenJDK hsx > [0] Committer [1]. > > Calvin joined the hotspot runtime team a year ago after years of working on the > java plugin and java webstart. Calvin is currently a committer to jdk6, jdk7, jdk7u and jdk8. > As a member of the runtime team, Calvin has contributed multiple changes in > serviceability and runtime, cleaning up memory leaks, jvm tracing improvements, > fixing signal handling code and fatal errors, including the following 13 changesets which can be seen at [3]. > > Votes are due Thursday September 12th at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > >>>> hg log -M -u ccheung --template "{desc}\n" | grep "^[0-9]\{7,7\}: " >>>> >>>> 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error >>>> 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases >>>> 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code >>>> 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed >>>> 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 >>>> 8014431: cleanup warnings indicated by the -Wunused-value compiler option on linux >>>> 8015265: revise the fix for 8007037 >>>> 8005849: JEP 167: Event-Based JVM Tracing >>>> 8012641: Perf_CreateLong creates perf counter of incorrect type >>>> 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" >>>> 8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp >>>> 8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp >>>> 8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c From zhengyu.gu at oracle.com Thu Aug 29 12:34:34 2013 From: zhengyu.gu at oracle.com (Zhengyu Gu) Date: Thu, 29 Aug 2013 15:34:34 -0400 Subject: CFV: New hsx Committer: Calvin Cheung In-Reply-To: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> References: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> Message-ID: <521FA24A.2080901@oracle.com> Vote: yes -Zhengyu On 8/29/2013 2:36 PM, Karen Kinnear wrote: > I hereby nominate Calvin Cheung (openjdk username: ccheung) to be an OpenJDK hsx > [0] Committer [1]. > > Calvin joined the hotspot runtime team a year ago after years of working on the > java plugin and java webstart. Calvin is currently a committer to jdk6, jdk7, jdk7u and jdk8. > As a member of the runtime team, Calvin has contributed multiple changes in > serviceability and runtime, cleaning up memory leaks, jvm tracing improvements, > fixing signal handling code and fatal errors, including the following 13 changesets which can be seen at [3]. > > Votes are due Thursday September 12th at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > >>>> hg log -M -u ccheung --template "{desc}\n" | grep "^[0-9]\{7,7\}: " >>>> >>>> 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error >>>> 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases >>>> 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code >>>> 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed >>>> 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 >>>> 8014431: cleanup warnings indicated by the -Wunused-value compiler option on linux >>>> 8015265: revise the fix for 8007037 >>>> 8005849: JEP 167: Event-Based JVM Tracing >>>> 8012641: Perf_CreateLong creates perf counter of incorrect type >>>> 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" >>>> 8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp >>>> 8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp >>>> 8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c From alejandro.murillo at oracle.com Thu Aug 29 12:41:58 2013 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Thu, 29 Aug 2013 13:41:58 -0600 Subject: CFV: New hsx Committer: Calvin Cheung In-Reply-To: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> References: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> Message-ID: <521FA406.8020603@oracle.com> vote: yes -- Alejandro From daniel.daugherty at oracle.com Thu Aug 29 12:46:01 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 29 Aug 2013 13:46:01 -0600 Subject: CFV: New hsx Committer: Calvin Cheung In-Reply-To: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> References: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> Message-ID: <521FA4F9.60506@oracle.com> Vote: yes Dan On 8/29/13 12:36 PM, Karen Kinnear wrote: > I hereby nominate Calvin Cheung (openjdk username: ccheung) to be an OpenJDK hsx > [0] Committer [1]. > > Calvin joined the hotspot runtime team a year ago after years of working on the > java plugin and java webstart. Calvin is currently a committer to jdk6, jdk7, jdk7u and jdk8. > As a member of the runtime team, Calvin has contributed multiple changes in > serviceability and runtime, cleaning up memory leaks, jvm tracing improvements, > fixing signal handling code and fatal errors, including the following 13 changesets which can be seen at [3]. > > Votes are due Thursday September 12th at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > >>>> hg log -M -u ccheung --template "{desc}\n" | grep "^[0-9]\{7,7\}: " >>>> >>>> 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error >>>> 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases >>>> 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code >>>> 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed >>>> 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 >>>> 8014431: cleanup warnings indicated by the -Wunused-value compiler option on linux >>>> 8015265: revise the fix for 8007037 >>>> 8005849: JEP 167: Event-Based JVM Tracing >>>> 8012641: Perf_CreateLong creates perf counter of incorrect type >>>> 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" >>>> 8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp >>>> 8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp >>>> 8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c > From coleen.phillimore at oracle.com Thu Aug 29 13:17:04 2013 From: coleen.phillimore at oracle.com (Coleen Phillmore) Date: Thu, 29 Aug 2013 16:17:04 -0400 Subject: CFV: New hsx Committer: Calvin Cheung In-Reply-To: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> References: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> Message-ID: <521FAC40.9000104@oracle.com> Vote: yes On 8/29/2013 2:36 PM, Karen Kinnear wrote: > I hereby nominate Calvin Cheung (openjdk username: ccheung) to be an OpenJDK hsx > [0] Committer [1]. > > Calvin joined the hotspot runtime team a year ago after years of working on the > java plugin and java webstart. Calvin is currently a committer to jdk6, jdk7, jdk7u and jdk8. > As a member of the runtime team, Calvin has contributed multiple changes in > serviceability and runtime, cleaning up memory leaks, jvm tracing improvements, > fixing signal handling code and fatal errors, including the following 13 changesets which can be seen at [3]. > > Votes are due Thursday September 12th at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > >>>> hg log -M -u ccheung --template "{desc}\n" | grep "^[0-9]\{7,7\}: " >>>> >>>> 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error >>>> 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases >>>> 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code >>>> 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed >>>> 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 >>>> 8014431: cleanup warnings indicated by the -Wunused-value compiler option on linux >>>> 8015265: revise the fix for 8007037 >>>> 8005849: JEP 167: Event-Based JVM Tracing >>>> 8012641: Perf_CreateLong creates perf counter of incorrect type >>>> 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" >>>> 8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp >>>> 8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp >>>> 8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c From david.holmes at oracle.com Thu Aug 29 18:49:20 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Aug 2013 11:49:20 +1000 Subject: RR(XS): JDK-8022617 Openjdk hotspot build is broken on BSD platforms using gcc In-Reply-To: <521F34BE.1060209@oracle.com> References: <521E0031.3050604@oracle.com> <521E98AE.3020206@oracle.com> <521F0FD8.5040008@oracle.com> <521F2746.1010507@oracle.com> <521F34BE.1060209@oracle.com> Message-ID: <521FFA20.9020606@oracle.com> On 29/08/2013 9:47 PM, Dmitry Samersoff wrote: > David, > > On 2013-08-29 14:49, David Holmes wrote: > >> This needs to be reviewed by the hotspot group. > > Added to CC Thanks. >> >> I don't understand your change given we already had: >> >> AS = $(CC) -c -x assembler-with-cpp > > It's guarded by: > >>> # If a SPEC is not set already, then use these defaults. >>> ifeq ($(SPEC),) > > as configure sets SPEC, this line is ignored. Ah! I think this was an oversight when the configure/SPEC support was added in. The setting of the AS value needed to come from configure but not necessarily the flags passed through. But it was a grey area in determining where to set things. >> Isn't this something that was fixed very recently? Discussed but not fixed. And of course only affected direct hotspot builds, not full forest builds. >> Your change, as far as I can see, will also add the assembler-with-cpp >> to clang not just gcc. > > It's intentional, according to my experiments clang supports this option > as well. Ok. The proof of this one is in the building so as long as everything builds okay then it is fine by me. Thanks, David > -Dmitry > >> >> ??? >> >> David >> >> On 29/08/2013 7:09 PM, Dmitry Samersoff wrote: >>> David, >>> >>> Thank you for the comments. >>> >>> Please, take a look to updated webrev: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.03/ >>> >>> -Dmitry >>> >>> On 2013-08-29 04:41, David Holmes wrote: >>>> Dmitry, >>>> >>>> I don't think this is something that should be handled at the configure >>>> level. Hotspot compiler flags are handled in the hotspot makefiles. This >>>> should be in gcc.make. >>>> >>>> BTW your changeset should include the generated-configure.sh file not >>>> configure. And you would also need to regenerate and push the closed >>>> generated-configure.sh file. >>>> >>>> David >>>> >>>> On 28/08/2013 11:50 PM, Dmitry Samersoff wrote: >>>>> Hi Everyone, >>>>> >>>>> Please review small fix >>>>> >>>>> webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8022617/webrev.02/ >>>>> >>>>> CR: >>>>> >>>>> http://bugs.sun.com/view_bug.do?bug_id=8022617 >>>>> >>>>> >>>>> Gory details: >>>>> >>>>> bsd_x86_64.s use macro to deal with OS X specific things. >>>>> >>>>> llvm-gcc preprocess .s and .S files and doesn't support .sx extension >>>>> recommended by GNU for case insensitive filesystem. >>>>> >>>>> Other operating systems doesn't preprocess .s files, so >>>>> bsd_x86_64.s >>>>> couldn't be compiled on other bsd systems. >>>>> >>>>> This patch enforce of preprocessing of all assembly sources by >>>>> command line options (-x assembler-with-cpp). >>>>> >>>>> -Dmitry >>>>> >>> >>> > > From John.Coomes at oracle.com Thu Aug 29 21:09:27 2013 From: John.Coomes at oracle.com (John Coomes) Date: Thu, 29 Aug 2013 21:09:27 -0700 Subject: new convention for hsx project repository names Message-ID: <21024.6903.641183.24409@oracle.com> The hsx Project has maintained a version number for HotSpot that is distinct from the JDK version--for example HotSpot version hs24 is being delivered into jdk7u40, and hs25 into jdk8. (For interested readers, some background info about separate versions is included at the end of this message.) The separate version has also been reflected in repository paths, e.g.: http://hg.openjdk.java.net/hsx/hsx24 http://hg.openjdk.java.net/hsx/hsx23 http://hg.openjdk.java.net/hsx/hsx23.2 http://hg.openjdk.java.net/hsx/hsx23.4 ... One often-mentioned problem with this naming scheme is that the correspondence between an hsx repository and the JDK release into which it will be delivered is not obvious. So we are planning on changing the repository naming convention going forward. More precisely, the new repository for HotSpot (and HotSpot-related) changes targeting jdk7u60 and later 7 updates would be: http://hg.openjdk.java.net/hsx/jdk7u (The old convention would have used the name http://.../hsx/hsx24.) This new repo will correspond to the jdk7u on-going development repo, i.e., http://hg.openjdk.java.net/jdk7u/jdk7u. Extending this a little into the future, once jdk7u60 reaches a point where a separate stabilization repo is needed, we will create http://hg.openjdk.java.net/hsx/jdk7u60. At that time the hsx/jdk7u repo would change to target the following jdk7u update release (if there is one). Similar conventions would apply to repositories for jdk8 updates once we have a need for them. Existing hsx repos should continue to be used; in particular, we will continue to use the on-going development repos for the forseeable future: http://hg.openjdk.java.net/hsx/hotspot-main http://hg.openjdk.java.net/hsx/hotspot-comp http://hg.openjdk.java.net/hsx/hotspot-emb http://hg.openjdk.java.net/hsx/hotspot-gc http://hg.openjdk.java.net/hsx/hotspot-rt These are currently targeting jdk8, and will switch to jdk9 in the near future. At that point a new jdk8 stabilization repo would be created: http://hg.openjdk.java.net/hsx/jdk8 to be used instead of the existing hsx/hsx25 repo (hsx/hsx25 is currently used only by the hotspot gatekeeper, Alejandro Murillo). Despite the length of this message, I think the naming change is straightforward and will (slightly) simplify HotSpot development. Since there are already HotSpot changes pending for jdk7u60, I want to create the new repo within the next few days. If you have questions or feedback, please follow-up on the list. Background on the separate HotSpot version number: Because the same HotSpot source has been delivered simultaneously into multiple JDK releases (e.g., builds of hs23 were delivered into jdk8 and into jdk7u4, builds of hs22 were delivered into early jdk8 builds and into jdk7u2, and so on), a separate HotSpot version facilitated tracking the sources as they propagated to different releases. But at the same time, it also imposed the overhead of having to map from a HotSpot version to a JDK version and back again. This is not always simple, particularly for those that do not work with HotSpot on a day-to-day basis. More recent hsx versions (hs24 and hs25), have really targeted only a single JDK release (although a few builds of hs24 did go into both jdk8 and into jdk7u). We expect this trend to continue, and thus the overhead of mapping from a HotSpot version to a JDK version is unnecessary. -John From david.holmes at oracle.com Thu Aug 29 22:37:57 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Aug 2013 15:37:57 +1000 Subject: new convention for hsx project repository names In-Reply-To: <21024.6903.641183.24409@oracle.com> References: <21024.6903.641183.24409@oracle.com> Message-ID: <52202FB5.6050505@oracle.com> Hi John, Can you clarify how the repository name change will affect the actual hotspot version info that is maintained in the repo, and reported via -version and -Xinternalversion. Thanks, David On 30/08/2013 2:09 PM, John Coomes wrote: > The hsx Project has maintained a version number for HotSpot that is > distinct from the JDK version--for example HotSpot version hs24 is > being delivered into jdk7u40, and hs25 into jdk8. (For interested > readers, some background info about separate versions is included at > the end of this message.) > > The separate version has also been reflected in repository paths, e.g.: > > http://hg.openjdk.java.net/hsx/hsx24 > http://hg.openjdk.java.net/hsx/hsx23 > http://hg.openjdk.java.net/hsx/hsx23.2 > http://hg.openjdk.java.net/hsx/hsx23.4 > ... > > One often-mentioned problem with this naming scheme is that the > correspondence between an hsx repository and the JDK release into which > it will be delivered is not obvious. So we are planning on changing the > repository naming convention going forward. > > More precisely, the new repository for HotSpot (and HotSpot-related) > changes targeting jdk7u60 and later 7 updates would be: > > http://hg.openjdk.java.net/hsx/jdk7u > > (The old convention would have used the name http://.../hsx/hsx24.) > This new repo will correspond to the jdk7u on-going development repo, > i.e., http://hg.openjdk.java.net/jdk7u/jdk7u. > > Extending this a little into the future, once jdk7u60 reaches a point > where a separate stabilization repo is needed, we will create > http://hg.openjdk.java.net/hsx/jdk7u60. At that time the hsx/jdk7u > repo would change to target the following jdk7u update release (if > there is one). > > Similar conventions would apply to repositories for jdk8 updates once > we have a need for them. > > Existing hsx repos should continue to be used; in particular, we will > continue to use the on-going development repos for the forseeable > future: > > http://hg.openjdk.java.net/hsx/hotspot-main > http://hg.openjdk.java.net/hsx/hotspot-comp > http://hg.openjdk.java.net/hsx/hotspot-emb > http://hg.openjdk.java.net/hsx/hotspot-gc > http://hg.openjdk.java.net/hsx/hotspot-rt > > These are currently targeting jdk8, and will switch to jdk9 in the near > future. At that point a new jdk8 stabilization repo would be created: > > http://hg.openjdk.java.net/hsx/jdk8 > > to be used instead of the existing hsx/hsx25 repo (hsx/hsx25 is > currently used only by the hotspot gatekeeper, Alejandro Murillo). > > Despite the length of this message, I think the naming change is > straightforward and will (slightly) simplify HotSpot development. > Since there are already HotSpot changes pending for jdk7u60, I want to > create the new repo within the next few days. If you have questions > or feedback, please follow-up on the list. > > Background on the separate HotSpot version number: > > Because the same HotSpot source has been delivered simultaneously into > multiple JDK releases (e.g., builds of hs23 were delivered into jdk8 and > into jdk7u4, builds of hs22 were delivered into early jdk8 builds and > into jdk7u2, and so on), a separate HotSpot version facilitated tracking > the sources as they propagated to different releases. But at the same > time, it also imposed the overhead of having to map from a HotSpot > version to a JDK version and back again. This is not always simple, > particularly for those that do not work with HotSpot on a day-to-day > basis. > > More recent hsx versions (hs24 and hs25), have really targeted only a > single JDK release (although a few builds of hs24 did go into both jdk8 > and into jdk7u). We expect this trend to continue, and thus the > overhead of mapping from a HotSpot version to a JDK version is > unnecessary. > > -John > From staffan.larsen at oracle.com Thu Aug 29 23:36:10 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 30 Aug 2013 08:36:10 +0200 Subject: CFV: New hsx Committer: Calvin Cheung In-Reply-To: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> References: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> Message-ID: <76C231B7-92BF-48A4-BAB1-51B19E199B12@oracle.com> Vote: yes. On 29 aug 2013, at 20:36, Karen Kinnear wrote: > I hereby nominate Calvin Cheung (openjdk username: ccheung) to be an OpenJDK hsx > [0] Committer [1]. > > Calvin joined the hotspot runtime team a year ago after years of working on the > java plugin and java webstart. Calvin is currently a committer to jdk6, jdk7, jdk7u and jdk8. > As a member of the runtime team, Calvin has contributed multiple changes in > serviceability and runtime, cleaning up memory leaks, jvm tracing improvements, > fixing signal handling code and fatal errors, including the following 13 changesets which can be seen at [3]. > > Votes are due Thursday September 12th at 19:00:00 UTC (two week voting period). > > Only current hsx Committers [0] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2] > > Regards, > Karen Kinnear > > > [0]http://openjdk.java.net/census/#hsx > [1]http://openjdk.java.net/bylaws#committer > [2]http://openjdk.java.net/projects/#committer-vote > [3] list here: > >>>> hg log -M -u ccheung --template "{desc}\n" | grep "^[0-9]\{7,7\}: " >>>> >>>> 8020675: invalid jar file in the bootclasspath could lead to jvm fatal error >>>> 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases >>>> 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code >>>> 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed >>>> 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 >>>> 8014431: cleanup warnings indicated by the -Wunused-value compiler option on linux >>>> 8015265: revise the fix for 8007037 >>>> 8005849: JEP 167: Event-Based JVM Tracing >>>> 8012641: Perf_CreateLong creates perf counter of incorrect type >>>> 8011661: Insufficient memory message says "malloc" when sometimes it should say "mmap" >>>> 8006001: [parfait] Possible file leak in hotspot/src/os/linux/vm/perfMemory_linux.cpp >>>> 8006103: [parfait] Possible null pointer dereference at hotspot/src/os/linux/vm/os_linux.cpp; os_windows.cpp; os_solaris.cpp; os_bsd.cpp >>>> 8006006: [parfait] Memory leak at hotspot/src/share/tools/launcher/wildcard.c From staffan.larsen at oracle.com Thu Aug 29 23:39:21 2013 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 30 Aug 2013 08:39:21 +0200 Subject: new convention for hsx project repository names In-Reply-To: <21024.6903.641183.24409@oracle.com> References: <21024.6903.641183.24409@oracle.com> Message-ID: <3A581E37-0E8F-4F35-A03D-AA01A5C7EF51@oracle.com> This is a good change! /Staffan On 30 aug 2013, at 06:09, John Coomes wrote: > The hsx Project has maintained a version number for HotSpot that is > distinct from the JDK version--for example HotSpot version hs24 is > being delivered into jdk7u40, and hs25 into jdk8. (For interested > readers, some background info about separate versions is included at > the end of this message.) > > The separate version has also been reflected in repository paths, e.g.: > > http://hg.openjdk.java.net/hsx/hsx24 > http://hg.openjdk.java.net/hsx/hsx23 > http://hg.openjdk.java.net/hsx/hsx23.2 > http://hg.openjdk.java.net/hsx/hsx23.4 > ... > > One often-mentioned problem with this naming scheme is that the > correspondence between an hsx repository and the JDK release into which > it will be delivered is not obvious. So we are planning on changing the > repository naming convention going forward. > > More precisely, the new repository for HotSpot (and HotSpot-related) > changes targeting jdk7u60 and later 7 updates would be: > > http://hg.openjdk.java.net/hsx/jdk7u > > (The old convention would have used the name http://.../hsx/hsx24.) > This new repo will correspond to the jdk7u on-going development repo, > i.e., http://hg.openjdk.java.net/jdk7u/jdk7u. > > Extending this a little into the future, once jdk7u60 reaches a point > where a separate stabilization repo is needed, we will create > http://hg.openjdk.java.net/hsx/jdk7u60. At that time the hsx/jdk7u > repo would change to target the following jdk7u update release (if > there is one). > > Similar conventions would apply to repositories for jdk8 updates once > we have a need for them. > > Existing hsx repos should continue to be used; in particular, we will > continue to use the on-going development repos for the forseeable > future: > > http://hg.openjdk.java.net/hsx/hotspot-main > http://hg.openjdk.java.net/hsx/hotspot-comp > http://hg.openjdk.java.net/hsx/hotspot-emb > http://hg.openjdk.java.net/hsx/hotspot-gc > http://hg.openjdk.java.net/hsx/hotspot-rt > > These are currently targeting jdk8, and will switch to jdk9 in the near > future. At that point a new jdk8 stabilization repo would be created: > > http://hg.openjdk.java.net/hsx/jdk8 > > to be used instead of the existing hsx/hsx25 repo (hsx/hsx25 is > currently used only by the hotspot gatekeeper, Alejandro Murillo). > > Despite the length of this message, I think the naming change is > straightforward and will (slightly) simplify HotSpot development. > Since there are already HotSpot changes pending for jdk7u60, I want to > create the new repo within the next few days. If you have questions > or feedback, please follow-up on the list. > > Background on the separate HotSpot version number: > > Because the same HotSpot source has been delivered simultaneously into > multiple JDK releases (e.g., builds of hs23 were delivered into jdk8 and > into jdk7u4, builds of hs22 were delivered into early jdk8 builds and > into jdk7u2, and so on), a separate HotSpot version facilitated tracking > the sources as they propagated to different releases. But at the same > time, it also imposed the overhead of having to map from a HotSpot > version to a JDK version and back again. This is not always simple, > particularly for those that do not work with HotSpot on a day-to-day > basis. > > More recent hsx versions (hs24 and hs25), have really targeted only a > single JDK release (although a few builds of hs24 did go into both jdk8 > and into jdk7u). We expect this trend to continue, and thus the > overhead of mapping from a HotSpot version to a JDK version is > unnecessary. > > -John From alejandro.murillo at oracle.com Fri Aug 30 03:52:51 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 30 Aug 2013 10:52:51 +0000 Subject: hg: hsx/hsx25/hotspot: 34 new changesets Message-ID: <20130830105724.BF1DE62414@hg.openjdk.java.net> Changeset: b649cfa58604 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b649cfa58604 Added tag jdk8-b105 for changeset acac3bde66b2 ! .hgtags Changeset: 73921c720b94 Author: amurillo Date: 2013-08-23 03:14 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/73921c720b94 8023635: new hotspot build - hs25-b48 Reviewed-by: jcoomes ! make/hotspot_version Changeset: c6ec0a97b30a Author: sla Date: 2013-08-21 13:18 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c6ec0a97b30a 8022808: Kitchensink hangs on macos Summary: Use pthread_mach_thread_np() instead of mach_thread_self() to avoid leaking resources Reviewed-by: dholmes, rbackman ! src/os/bsd/vm/os_bsd.cpp Changeset: 3a57fa7a4cd0 Author: hseigel Date: 2013-08-22 11:52 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/3a57fa7a4cd0 7121403: [TESTBUG] runtime/7051189/Xchecksig.sh fails on 64bit solaris 8023393: Need to suppress info message if -Xcheck:jni used with libjsig.dylab on Mac OSX Summary: Rewrite 7051189 test in Java, port Linux fix for 7051189 to Mac OSX. Reviewed-by: coleenp, dholmes, mseledtsov, ccheung ! src/os/bsd/vm/os_bsd.cpp - test/runtime/7051189/Xchecksig.sh + test/runtime/XCheckJniJsig/XCheckJSig.java Changeset: e37ab280bbce Author: allwin Date: 2013-07-23 14:32 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/e37ab280bbce 8011888: sa.js: TypeError: [object JSAdapter] has no such function "__has__" Reviewed-by: sla, sundar, kmo Contributed-by: yunda.mly at taobao.com ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js Changeset: 669d9a235486 Author: sla Date: 2013-08-22 14:56 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/669d9a235486 Merge Changeset: c062a6e1fa33 Author: iklam Date: 2013-08-22 10:20 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c062a6e1fa33 8023406: make/windows/build_vm_def.sh takes too long even when BUILD_WIN_SA != 1 Summary: Avoid dumping C++ vtable when BUILD_WIN_SA != 1 Reviewed-by: dcubed, sla, tbell ! make/windows/build_vm_def.sh ! make/windows/makefiles/debug.make ! make/windows/makefiles/fastdebug.make ! make/windows/makefiles/product.make ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/vm.make Changeset: 811aea34d5e7 Author: iklam Date: 2013-08-22 13:53 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/811aea34d5e7 Merge Changeset: ff2520b97b00 Author: jiangli Date: 2013-08-22 19:27 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ff2520b97b00 8023547: com/sun/jdi/RedefineMulti.sh fails with IllegalArgumentException after JDK-8021948 . Summary: Need to check if the constant pool mapping returns 0. Reviewed-by: coleenp, sspitsyn ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 887db75613f8 Author: jiangli Date: 2013-08-22 17:21 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/887db75613f8 Merge Changeset: a70566600baf Author: poonam Date: 2013-08-21 22:12 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/a70566600baf 8020530: Non heap memory size calculated incorrectly Reviewed-by: coleenp, sla Contributed-by: vladimir.kempik at oracle.com ! src/share/vm/services/management.cpp Changeset: 730210728146 Author: poonam Date: 2013-08-22 18:09 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/730210728146 Merge - test/runtime/7051189/Xchecksig.sh Changeset: 817e46dd5864 Author: poonam Date: 2013-08-22 21:23 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/817e46dd5864 Merge Changeset: 739c309fd729 Author: mgronlun Date: 2013-08-23 10:36 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/739c309fd729 8023457: Event based tracing framework needs a mutex for thread groups Reviewed-by: acorn, sla ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp Changeset: cacc421f39d7 Author: dcubed Date: 2013-08-23 10:39 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/cacc421f39d7 Merge - test/runtime/7051189/Xchecksig.sh Changeset: badf4244ceae Author: hseigel Date: 2013-08-25 21:21 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/badf4244ceae 8022183: GCC 4.6 change sdefault setting for omit-frame-pointer which breaks hotspot stack walking Summary: Explicitly specify -fno-omit-frame-pointer. Reviewed-by: coleenp, dholmes, dcubed ! make/linux/makefiles/amd64.make ! make/linux/makefiles/gcc.make Changeset: faf2631b9334 Author: dsimms Date: 2013-08-26 09:33 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/faf2631b9334 8022683: JNI GetStringUTFChars should return NULL on allocation failure not abort the VM Summary: Return NULL on OOM from GetStringChars, GetStringUTFChars and GetArrayElements family of functions. Reviewed-by: dholmes, coleenp ! src/share/vm/memory/allocation.hpp ! src/share/vm/prims/jni.cpp Changeset: 4c84d351cca9 Author: stefank Date: 2013-08-16 13:22 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/4c84d351cca9 8007074: SIGSEGV at ParMarkBitMap::verify_clear() Summary: Replace the broken large pages implementation on Linux. New flag: -XX:+UseTransparentHugePages - Linux specific flag to turn on transparent huge page hinting with madvise(..., MAP_HUGETLB). Changed behavior: -XX:+UseLargePages - tries to use -XX:+UseTransparentHugePages before trying other large pages implementations (on Linux). Changed behavior: -XX:+UseHugeTLBFS - Use upfront allocation of Large Pages instead of using the broken implementation to dynamically committing large pages. Changed behavior: -XX:LargePageSizeInBytes - Turned off the ability to use this flag on Linux and provides warning to user if set to a value different than the OS chosen large page size. Changed behavior: Setting no large page size - Now defaults to use -XX:UseTransparentHugePages if the OS supports it. Previously, -XX:+UseHugeTLBFS was chosen if the OS was configured to use large pages. Reviewed-by: tschatzl, dcubed, brutisso ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/globals_linux.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 21ffbaa691b5 Author: stefank Date: 2013-08-26 07:01 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/21ffbaa691b5 Merge ! src/share/vm/prims/jni.cpp Changeset: 1bb10d3170fa Author: jmasa Date: 2013-08-16 06:12 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1bb10d3170fa 8022817: CMS should not shrink if compaction was not done Reviewed-by: ysr, mgerdin ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: f7d3b4387a16 Author: brutisso Date: 2013-08-21 22:35 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f7d3b4387a16 8022872: G1: Use correct GC cause for young GC triggered by humongous allocations Reviewed-by: tonyp, tschatzl ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp Changeset: c31eb8c86a50 Author: brutisso Date: 2013-08-22 04:14 +0200 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/c31eb8c86a50 Merge Changeset: ec145d04eda8 Author: jmasa Date: 2013-08-23 15:59 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/ec145d04eda8 Merge Changeset: 1624a68007bd Author: jmasa Date: 2013-08-27 18:55 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1624a68007bd Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: f92b82d454fa Author: bpittore Date: 2013-08-23 20:33 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/f92b82d454fa 8014135: The JVMTI specification does not conform to recent changes in JNI specification Summary: Added support for statically linked agents Reviewed-by: sspitsyn, bobv, coleenp ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp Changeset: 5fd8e2fbafd4 Author: cjplummer Date: 2013-08-23 12:36 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5fd8e2fbafd4 8020829: JT_HS: 2 runtime NMT tests fail on platforms if NMT detail is not supported Summary: Make tests query a new WhiteBox API to see if NMT detail is supported, and behave properly if it is not supported. Reviewed-by: dholmes, coleenp ! src/share/vm/prims/whitebox.cpp ! test/runtime/NMT/ThreadedVirtualAllocTestType.java ! test/runtime/NMT/VirtualAllocTestType.java ! test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Changeset: 7aa0c1fb6fdb Author: dholmes Date: 2013-08-27 22:05 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/7aa0c1fb6fdb 8006164: [TESTBUG] compact profile hotspot test issues Summary: Define profile-based test groups. Reviewed-by: dcubed, mchung ! test/TEST.ROOT + test/TEST.groups Changeset: 1fedf3c7f923 Author: bpittore Date: 2013-08-28 14:44 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/1fedf3c7f923 8023580: Add jtreg test for 8004051 and 8005722 Summary: Tests checks an assertion dealing with the number of args passed in registers Reviewed-by: mseledtsov, kvn + test/compiler/8004051/Test8004051.java Changeset: b1fb293d92c4 Author: jiangli Date: 2013-08-28 12:01 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/b1fb293d92c4 Merge Changeset: 2b113b65a051 Author: dholmes Date: 2013-08-28 19:25 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/2b113b65a051 8023900: [TESTBUG] Initial compact profile test groups need adjusting Reviewed-by: dcubed, mchung, hseigel ! test/TEST.groups Changeset: 54dfd798deaf Author: dholmes Date: 2013-08-28 21:42 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/54dfd798deaf Merge Changeset: 62f527c674d2 Author: dholmes Date: 2013-08-29 00:22 -0400 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/62f527c674d2 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp Changeset: 18b4798adbc4 Author: amurillo Date: 2013-08-30 00:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/18b4798adbc4 Merge - test/runtime/7051189/Xchecksig.sh Changeset: aed585cafc0d Author: amurillo Date: 2013-08-30 00:19 -0700 URL: http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/aed585cafc0d Added tag hs25-b48 for changeset 18b4798adbc4 ! .hgtags From alejandro.murillo at oracle.com Fri Aug 30 05:55:36 2013 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Fri, 30 Aug 2013 12:55:36 +0000 Subject: hg: hsx/hotspot-main/hotspot: 4 new changesets Message-ID: <20130830125549.537FF6241B@hg.openjdk.java.net> Changeset: b649cfa58604 Author: cl Date: 2013-08-29 09:41 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/b649cfa58604 Added tag jdk8-b105 for changeset acac3bde66b2 ! .hgtags Changeset: 18b4798adbc4 Author: amurillo Date: 2013-08-30 00:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/18b4798adbc4 Merge - test/runtime/7051189/Xchecksig.sh Changeset: aed585cafc0d Author: amurillo Date: 2013-08-30 00:19 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/aed585cafc0d Added tag hs25-b48 for changeset 18b4798adbc4 ! .hgtags Changeset: c169f7038414 Author: amurillo Date: 2013-08-30 00:29 -0700 URL: http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/c169f7038414 8024022: new hotspot build - hs25-b49 Reviewed-by: jcoomes ! make/hotspot_version From daniel.daugherty at oracle.com Fri Aug 30 05:59:25 2013 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 30 Aug 2013 06:59:25 -0600 Subject: new convention for hsx project repository names In-Reply-To: <21024.6903.641183.24409@oracle.com> References: <21024.6903.641183.24409@oracle.com> Message-ID: <5220972D.9000001@oracle.com> I like it! Details about how this will affect 'version' info would be good (to echo David H)... I suspect we'll go back to reporting the same version string for both JDK and VM: $ /java/re/jdk/1.6.0_03/promoted/latest/binaries/solaris-i586/bin/java -version java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode) and here's the first release where the version numbers diverged: $ /java/re/jdk/1.6.0_04/promoted/latest/binaries/solaris-i586/bin/java -version java version "1.6.0_04" Java(TM) SE Runtime Environment (build 1.6.0_04-b12) Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode) HSX-10... now at HSX-25... it's been a long road... Dan On 8/29/13 10:09 PM, John Coomes wrote: > The hsx Project has maintained a version number for HotSpot that is > distinct from the JDK version--for example HotSpot version hs24 is > being delivered into jdk7u40, and hs25 into jdk8. (For interested > readers, some background info about separate versions is included at > the end of this message.) > > The separate version has also been reflected in repository paths, e.g.: > > http://hg.openjdk.java.net/hsx/hsx24 > http://hg.openjdk.java.net/hsx/hsx23 > http://hg.openjdk.java.net/hsx/hsx23.2 > http://hg.openjdk.java.net/hsx/hsx23.4 > ... > > One often-mentioned problem with this naming scheme is that the > correspondence between an hsx repository and the JDK release into which > it will be delivered is not obvious. So we are planning on changing the > repository naming convention going forward. > > More precisely, the new repository for HotSpot (and HotSpot-related) > changes targeting jdk7u60 and later 7 updates would be: > > http://hg.openjdk.java.net/hsx/jdk7u > > (The old convention would have used the name http://.../hsx/hsx24.) > This new repo will correspond to the jdk7u on-going development repo, > i.e., http://hg.openjdk.java.net/jdk7u/jdk7u. > > Extending this a little into the future, once jdk7u60 reaches a point > where a separate stabilization repo is needed, we will create > http://hg.openjdk.java.net/hsx/jdk7u60. At that time the hsx/jdk7u > repo would change to target the following jdk7u update release (if > there is one). > > Similar conventions would apply to repositories for jdk8 updates once > we have a need for them. > > Existing hsx repos should continue to be used; in particular, we will > continue to use the on-going development repos for the forseeable > future: > > http://hg.openjdk.java.net/hsx/hotspot-main > http://hg.openjdk.java.net/hsx/hotspot-comp > http://hg.openjdk.java.net/hsx/hotspot-emb > http://hg.openjdk.java.net/hsx/hotspot-gc > http://hg.openjdk.java.net/hsx/hotspot-rt > > These are currently targeting jdk8, and will switch to jdk9 in the near > future. At that point a new jdk8 stabilization repo would be created: > > http://hg.openjdk.java.net/hsx/jdk8 > > to be used instead of the existing hsx/hsx25 repo (hsx/hsx25 is > currently used only by the hotspot gatekeeper, Alejandro Murillo). > > Despite the length of this message, I think the naming change is > straightforward and will (slightly) simplify HotSpot development. > Since there are already HotSpot changes pending for jdk7u60, I want to > create the new repo within the next few days. If you have questions > or feedback, please follow-up on the list. > > Background on the separate HotSpot version number: > > Because the same HotSpot source has been delivered simultaneously into > multiple JDK releases (e.g., builds of hs23 were delivered into jdk8 and > into jdk7u4, builds of hs22 were delivered into early jdk8 builds and > into jdk7u2, and so on), a separate HotSpot version facilitated tracking > the sources as they propagated to different releases. But at the same > time, it also imposed the overhead of having to map from a HotSpot > version to a JDK version and back again. This is not always simple, > particularly for those that do not work with HotSpot on a day-to-day > basis. > > More recent hsx versions (hs24 and hs25), have really targeted only a > single JDK release (although a few builds of hs24 did go into both jdk8 > and into jdk7u). We expect this trend to continue, and thus the > overhead of mapping from a HotSpot version to a JDK version is > unnecessary. > > -John > From John.Coomes at oracle.com Fri Aug 30 15:32:21 2013 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 30 Aug 2013 15:32:21 -0700 Subject: new convention for hsx project repository names In-Reply-To: <52202FB5.6050505@oracle.com> References: <21024.6903.641183.24409@oracle.com> <52202FB5.6050505@oracle.com> Message-ID: <21025.7541.995077.658147@oracle.com> David Holmes (david.holmes at oracle.com) wrote: > Hi John, > > Can you clarify how the repository name change will affect the actual > hotspot version info that is maintained in the repo, and reported via > -version and -Xinternalversion. Hi David, The new convention only affects the repository names; the version reported by the JVM will remain the same for now. Changing the version string is an obvious future step, but since it's visible to users (not just developers), we have to be a bit more careful. Look for more email on that in the coming weeks. -John > On 30/08/2013 2:09 PM, John Coomes wrote: > > The hsx Project has maintained a version number for HotSpot that is > > distinct from the JDK version--for example HotSpot version hs24 is > > being delivered into jdk7u40, and hs25 into jdk8. (For interested > > readers, some background info about separate versions is included at > > the end of this message.) > > > > The separate version has also been reflected in repository paths, e.g.: > > > > http://hg.openjdk.java.net/hsx/hsx24 > > http://hg.openjdk.java.net/hsx/hsx23 > > http://hg.openjdk.java.net/hsx/hsx23.2 > > http://hg.openjdk.java.net/hsx/hsx23.4 > > ... > > > > One often-mentioned problem with this naming scheme is that the > > correspondence between an hsx repository and the JDK release into which > > it will be delivered is not obvious. So we are planning on changing the > > repository naming convention going forward. > > > > More precisely, the new repository for HotSpot (and HotSpot-related) > > changes targeting jdk7u60 and later 7 updates would be: > > > > http://hg.openjdk.java.net/hsx/jdk7u > > > > (The old convention would have used the name http://.../hsx/hsx24.) > > This new repo will correspond to the jdk7u on-going development repo, > > i.e., http://hg.openjdk.java.net/jdk7u/jdk7u. > > > > Extending this a little into the future, once jdk7u60 reaches a point > > where a separate stabilization repo is needed, we will create > > http://hg.openjdk.java.net/hsx/jdk7u60. At that time the hsx/jdk7u > > repo would change to target the following jdk7u update release (if > > there is one). > > > > Similar conventions would apply to repositories for jdk8 updates once > > we have a need for them. > > > > Existing hsx repos should continue to be used; in particular, we will > > continue to use the on-going development repos for the forseeable > > future: > > > > http://hg.openjdk.java.net/hsx/hotspot-main > > http://hg.openjdk.java.net/hsx/hotspot-comp > > http://hg.openjdk.java.net/hsx/hotspot-emb > > http://hg.openjdk.java.net/hsx/hotspot-gc > > http://hg.openjdk.java.net/hsx/hotspot-rt > > > > These are currently targeting jdk8, and will switch to jdk9 in the near > > future. At that point a new jdk8 stabilization repo would be created: > > > > http://hg.openjdk.java.net/hsx/jdk8 > > > > to be used instead of the existing hsx/hsx25 repo (hsx/hsx25 is > > currently used only by the hotspot gatekeeper, Alejandro Murillo). > > > > Despite the length of this message, I think the naming change is > > straightforward and will (slightly) simplify HotSpot development. > > Since there are already HotSpot changes pending for jdk7u60, I want to > > create the new repo within the next few days. If you have questions > > or feedback, please follow-up on the list. > > > > Background on the separate HotSpot version number: > > > > Because the same HotSpot source has been delivered simultaneously into > > multiple JDK releases (e.g., builds of hs23 were delivered into jdk8 and > > into jdk7u4, builds of hs22 were delivered into early jdk8 builds and > > into jdk7u2, and so on), a separate HotSpot version facilitated tracking > > the sources as they propagated to different releases. But at the same > > time, it also imposed the overhead of having to map from a HotSpot > > version to a JDK version and back again. This is not always simple, > > particularly for those that do not work with HotSpot on a day-to-day > > basis. > > > > More recent hsx versions (hs24 and hs25), have really targeted only a > > single JDK release (although a few builds of hs24 did go into both jdk8 > > and into jdk7u). We expect this trend to continue, and thus the > > overhead of mapping from a HotSpot version to a JDK version is > > unnecessary. > > > > -John > > From John.Coomes at oracle.com Fri Aug 30 15:43:34 2013 From: John.Coomes at oracle.com (John Coomes) Date: Fri, 30 Aug 2013 15:43:34 -0700 Subject: CFV: New hsx Committer: Calvin Cheung In-Reply-To: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> References: <969F81B4-F882-492E-9347-F7FD3428243B@oracle.com> Message-ID: <21025.8214.720439.589612@oracle.com> Vote: yes -John