From serguei.spitsyn at oracle.com Mon Oct 1 06:02:05 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 30 Sep 2018 23:02:05 -0700 Subject: CFV: New JDK Reviewer: Jini George In-Reply-To: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> References: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> Message-ID: Vote: yes From roman at kennke.org Mon Oct 1 06:39:08 2018 From: roman at kennke.org (Roman Kennke) Date: Mon, 1 Oct 2018 08:39:08 +0200 Subject: Is jdk/submit repo down? Message-ID: <24aacb6f-9964-7a77-b506-33fa4f236788@kennke.org> See $SUBJ. I've got 3 patches waiting in jdk/submit since last Thursday and Friday, without any results yet. Am I doing something wrong? Or is the submit repo not working ATM? Thanks, Roman From adinn at redhat.com Mon Oct 1 07:59:39 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 1 Oct 2018 08:59:39 +0100 Subject: CFV: New JDK Reviewer: Jini George In-Reply-To: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> References: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> Message-ID: Vote: yes On 27/09/18 17:05, jesper.wilhelmsson at oracle.com wrote: > I hearby nominate Jini George (jgeorge) to JDK Project Reviewer. > > Jini has made 37 contributions in the JDK [3], many in the Serviceability Agent which is an area that for a long time was lacking active contributors. Jini's work in the SA is highly appreciated. > > Votes are due by 18:00 CET October 11, 2018. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of contributions: > > (1) 8210836: Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/c0f9161f591e > > (2) 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode > http://hg.openjdk.java.net/jdk/jdk/rev/948c62200f8c > > (3) 8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC > http://hg.openjdk.java.net/jdk/jdk/rev/e46b9e514479 > > (4) 8195613: [SA] HotSpotTypeDataBase.readVMLongConstants truncates values to int > http://hg.openjdk.java.net/jdk/jdk/rev/300e4a88c400 > > (5) 8174995: SA: clhsdb 'where -a' throws Assertion Failure with illegal code 236 when CDS is used > http://hg.openjdk.java.net/jdk/jdk/rev/55153a374d18 > > (6) 8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS > http://hg.openjdk.java.net/jdk/jdk/rev/ec2dd30adbc1 > > (7) 8175312: SA: clhsdb: Provide an improved heap summary for 'universe' for G1GC > http://hg.openjdk.java.net/jdk/jdk/rev/ccb003941743 > > (8) 8175384: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes > http://hg.openjdk.java.net/jdk/jdk/rev/d2a860bc50a3 > > (9) 8193352: SA: Test for the clhsdb 'thread' and 'threads' commands > http://hg.openjdk.java.net/jdk/jdk/rev/fdef4da95080 > > (10) 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands > http://hg.openjdk.java.net/jdk/jdk/rev/be065f758154 > > (11) 8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol > http://hg.openjdk.java.net/jdk/jdk/rev/61a14b5cb1c6 > > (12) 8191914: New SA test timeout on windows > http://hg.openjdk.java.net/jdk/jdk/rev/88ec5fca7726 > > (13) 8191324: SA cleanup -- part 2 > http://hg.openjdk.java.net/jdk/jdk/rev/2659c4fe8ea7 > > (14) 8191961: SA: Remove left over quarantined SA tests due to 8184042 from ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/111834dd10dd > > (15) 8191919: Include TestJhsdbJstackLock.java in ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/d851eb254409 > > (16) 8190307: SA tests for the clhsdb commands: universe, intconstant, type > http://hg.openjdk.java.net/jdk/jdk/rev/75d365bfc2e6 > > (17) 8189798: SA cleanup - part 1 > http://hg.openjdk.java.net/jdk/jdk/rev/ac0af7750da9 > > (18) 8184042: several serviceability/sa tests timed out on MacOS X > http://hg.openjdk.java.net/jdk/jdk/rev/dfb375d231fb > > (19) 8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 > http://hg.openjdk.java.net/jdk/jdk/rev/deab1e2f0ebf > > (20) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/2eab88a780e3 > > (21) 8162504: TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS > http://hg.openjdk.java.net/jdk/jdk/rev/4597fa06b227 > > (22) 8175054: Move new TestPrintMdo.java to hotspot/test directory > http://hg.openjdk.java.net/jdk/jdk/rev/d9ba85f5cb9d > > (23) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/c809fcb66c81 > > (24) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk/jdk/rev/a152f2d3320e > > (25) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk/jdk/rev/0b0ae99d8639 > http://hg.openjdk.java.net/jdk/jdk/rev/297ba2772122 > > (26) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk/jdk/rev/48d874bf85fb > > (27) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk/jdk/rev/a20695c30be5 > > (28) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/154099b110df > > (29) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk/jdk/rev/815cfbe4878b > > (30) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk/jdk/rev/afd6ae4fec81 > > (31) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk/jdk/rev/10e6e31dc1aa > > (32) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/815650daefb4 > > (33) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/aed0f6434aea > > (34) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk/jdk/rev/c0e02245ff93 > http://hg.openjdk.java.net/jdk/jdk/rev/12787d18650e > > (35) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk/jdk/rev/adf083cbc37f > > (36) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk/jdk/rev/8a2083c5e2b1 > http://hg.openjdk.java.net/jdk/jdk/rev/d46cac7959c4 > > (37) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk/jdk/rev/82ece130a37b > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From erik.osterlund at oracle.com Mon Oct 1 08:02:14 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 1 Oct 2018 10:02:14 +0200 Subject: CFV: New JDK Reviewer: Jini George In-Reply-To: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> References: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> Message-ID: <5BB1D486.6030805@oracle.com> Vote: yes /Erik On 2018-09-27 18:05, jesper.wilhelmsson at oracle.com wrote: > I hearby nominate Jini George (jgeorge) to JDK Project Reviewer. > > Jini has made 37 contributions in the JDK [3], many in the Serviceability Agent which is an area that for a long time was lacking active contributors. Jini's work in the SA is highly appreciated. > > Votes are due by 18:00 CET October 11, 2018. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of contributions: > > (1) 8210836: Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/c0f9161f591e > > (2) 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode > http://hg.openjdk.java.net/jdk/jdk/rev/948c62200f8c > > (3) 8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC > http://hg.openjdk.java.net/jdk/jdk/rev/e46b9e514479 > > (4) 8195613: [SA] HotSpotTypeDataBase.readVMLongConstants truncates values to int > http://hg.openjdk.java.net/jdk/jdk/rev/300e4a88c400 > > (5) 8174995: SA: clhsdb 'where -a' throws Assertion Failure with illegal code 236 when CDS is used > http://hg.openjdk.java.net/jdk/jdk/rev/55153a374d18 > > (6) 8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS > http://hg.openjdk.java.net/jdk/jdk/rev/ec2dd30adbc1 > > (7) 8175312: SA: clhsdb: Provide an improved heap summary for 'universe' for G1GC > http://hg.openjdk.java.net/jdk/jdk/rev/ccb003941743 > > (8) 8175384: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes > http://hg.openjdk.java.net/jdk/jdk/rev/d2a860bc50a3 > > (9) 8193352: SA: Test for the clhsdb 'thread' and 'threads' commands > http://hg.openjdk.java.net/jdk/jdk/rev/fdef4da95080 > > (10) 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands > http://hg.openjdk.java.net/jdk/jdk/rev/be065f758154 > > (11) 8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol > http://hg.openjdk.java.net/jdk/jdk/rev/61a14b5cb1c6 > > (12) 8191914: New SA test timeout on windows > http://hg.openjdk.java.net/jdk/jdk/rev/88ec5fca7726 > > (13) 8191324: SA cleanup -- part 2 > http://hg.openjdk.java.net/jdk/jdk/rev/2659c4fe8ea7 > > (14) 8191961: SA: Remove left over quarantined SA tests due to 8184042 from ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/111834dd10dd > > (15) 8191919: Include TestJhsdbJstackLock.java in ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/d851eb254409 > > (16) 8190307: SA tests for the clhsdb commands: universe, intconstant, type > http://hg.openjdk.java.net/jdk/jdk/rev/75d365bfc2e6 > > (17) 8189798: SA cleanup - part 1 > http://hg.openjdk.java.net/jdk/jdk/rev/ac0af7750da9 > > (18) 8184042: several serviceability/sa tests timed out on MacOS X > http://hg.openjdk.java.net/jdk/jdk/rev/dfb375d231fb > > (19) 8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 > http://hg.openjdk.java.net/jdk/jdk/rev/deab1e2f0ebf > > (20) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/2eab88a780e3 > > (21) 8162504: TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS > http://hg.openjdk.java.net/jdk/jdk/rev/4597fa06b227 > > (22) 8175054: Move new TestPrintMdo.java to hotspot/test directory > http://hg.openjdk.java.net/jdk/jdk/rev/d9ba85f5cb9d > > (23) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/c809fcb66c81 > > (24) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk/jdk/rev/a152f2d3320e > > (25) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk/jdk/rev/0b0ae99d8639 > http://hg.openjdk.java.net/jdk/jdk/rev/297ba2772122 > > (26) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk/jdk/rev/48d874bf85fb > > (27) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk/jdk/rev/a20695c30be5 > > (28) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/154099b110df > > (29) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk/jdk/rev/815cfbe4878b > > (30) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk/jdk/rev/afd6ae4fec81 > > (31) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk/jdk/rev/10e6e31dc1aa > > (32) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/815650daefb4 > > (33) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/aed0f6434aea > > (34) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk/jdk/rev/c0e02245ff93 > http://hg.openjdk.java.net/jdk/jdk/rev/12787d18650e > > (35) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk/jdk/rev/adf083cbc37f > > (36) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk/jdk/rev/8a2083c5e2b1 > http://hg.openjdk.java.net/jdk/jdk/rev/d46cac7959c4 > > (37) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk/jdk/rev/82ece130a37b > From aph at redhat.com Mon Oct 1 10:21:49 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Oct 2018 11:21:49 +0100 Subject: Is jdk/submit repo down? In-Reply-To: <24aacb6f-9964-7a77-b506-33fa4f236788@kennke.org> References: <24aacb6f-9964-7a77-b506-33fa4f236788@kennke.org> Message-ID: On 10/01/2018 07:39 AM, Roman Kennke wrote: > See $SUBJ. I've got 3 patches waiting in jdk/submit since last Thursday > and Friday, without any results yet. Am I doing something wrong? +1 -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From matthias.baesken at sap.com Mon Oct 1 11:16:18 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 1 Oct 2018 11:16:18 +0000 Subject: jboolean handling in native JDK code - was : RE: 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean In-Reply-To: <594d2fde-3b63-a67b-dea7-21ae6acbb41c@oracle.com> References: <594d2fde-3b63-a67b-dea7-21ae6acbb41c@oracle.com> Message-ID: Hi Phil, thanks for clarifying ! Then just one function remains, the coding of VerifyClassForMajorVersion in check_code.c , where we leave the range of JNI_TRUE / JNI_FALSE : we might assign "result = context->err_code;" and err_code gets potentially values 0 - 3 -------------------------------------------------------------------------------------------------------------------------------- jdk/src/java.base/share/native/libverify/check_code.c 763#define CC_OK 1 764#define CC_VerifyError 0 765#define CC_OutOfMemory 2 766#define CC_ClassFormatError 3 767 768JNIEXPORT jboolean 769VerifyClassForMajorVersion(JNIEnv *env, jclass cb, char *buffer, jint len, 770 jint major_version) 771{ ................. 774 jboolean result = CC_OK; 775 int i; 776 int num_methods; 777 int* code_lengths; 778 unsigned char** code; 779 878 result = CC_OK; 879 } else { 880 result = context->err_code; 881 } 908 return result; 909} 910 Best regards, Matthias > -----Original Message----- > From: Phil Race > Sent: Freitag, 28. September 2018 18:33 > To: Andrew Haley ; Baesken, Matthias > ; jdk-dev at openjdk.java.net > Cc: Simonis, Volker > Subject: Re: jboolean handling in native JDK code - was : RE: 8211163: UNIX > version of Java_java_io_Console_echo does not return a clean boolean > > _RequestWindowFocus is declared to return jboolean. > > So I don't think there's a nasty bug, just a whole lot of casting which might > be better avoided by some additional overload of SyncCall() which accepts > the function's real signature. > > -phil. > > > On 09/28/2018 07:04 AM, Andrew Haley wrote: > > On 09/28/2018 01:32 PM, Baesken, Matthias wrote: > >> Shouldn't we better compare the pointer to NULL instead of just > casting ? > > Heavens, yes! You have found a nasty bug. > > > > Note that the cast to intptr_t used here suppresses the compiler > > warning which should have been a big clue that something was > > wrong. Good catch. > > > > 8198895: Compilation errors in java.desktop with VS 2017 > > > > +++ > b/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp > Mon Mar 19 14:16:23 2018 -0700 > > @@ -3915,8 +3915,8 @@ > > rfs->component = selfGlobalRef; > > rfs->isMouseEventCause = isMouseEventCause; > > > > - return (jboolean)AwtToolkit::GetInstance().SyncCall( > > - (void*(*)(void*))AwtWindow::_RequestWindowFocus, rfs); > > + return (jboolean)((intptr_t)AwtToolkit::GetInstance().SyncCall( > > + (void*(*)(void*))AwtWindow::_RequestWindowFocus, rfs)); > > // global refs and rfs are deleted in _RequestWindowFocus > > > > CATCH_BAD_ALLOC_RET(JNI_FALSE); From christian.tornqvist at oracle.com Mon Oct 1 11:46:44 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 1 Oct 2018 04:46:44 -0700 Subject: Is jdk/submit repo down? In-Reply-To: References: <24aacb6f-9964-7a77-b506-33fa4f236788@kennke.org> Message-ID: Hi Andrew and Roman, There was a configuration issue with the submit repo, it?s been corrected and I?ve restarted the jobs I could see. Sorry for the inconvenience. Thanks, Christian > On Oct 1, 2018, at 3:21 AM, Andrew Haley wrote: > > On 10/01/2018 07:39 AM, Roman Kennke wrote: >> See $SUBJ. I've got 3 patches waiting in jdk/submit since last Thursday >> and Friday, without any results yet. Am I doing something wrong? > > +1 > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From roman at kennke.org Mon Oct 1 11:51:30 2018 From: roman at kennke.org (Roman Kennke) Date: Mon, 1 Oct 2018 13:51:30 +0200 Subject: Is jdk/submit repo down? In-Reply-To: References: <24aacb6f-9964-7a77-b506-33fa4f236788@kennke.org> Message-ID: <295b7760-83b9-5c42-f99c-55f8200d3278@kennke.org> Thank you, Christian! Cheers, Roman Am 01.10.18 um 13:46 schrieb Christian Tornqvist: > Hi Andrew and Roman, > > There was a configuration issue with the submit repo, it?s been corrected and I?ve restarted the jobs I could see. Sorry for the inconvenience. > > Thanks, > Christian > >> On Oct 1, 2018, at 3:21 AM, Andrew Haley wrote: >> >> On 10/01/2018 07:39 AM, Roman Kennke wrote: >>> See $SUBJ. I've got 3 patches waiting in jdk/submit since last Thursday >>> and Friday, without any results yet. Am I doing something wrong? >> >> +1 >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From calvin.cheung at oracle.com Mon Oct 1 15:22:01 2018 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Mon, 01 Oct 2018 08:22:01 -0700 Subject: CFV: New JDK Reviewer: Jini George In-Reply-To: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> References: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> Message-ID: <5BB23B99.9050409@oracle.com> Vote: yes On 9/27/18, 9:05 AM, jesper.wilhelmsson at oracle.com wrote: > I hearby nominate Jini George (jgeorge) to JDK Project Reviewer. > > Jini has made 37 contributions in the JDK [3], many in the Serviceability Agent which is an area that for a long time was lacking active contributors. Jini's work in the SA is highly appreciated. > > Votes are due by 18:00 CET October 11, 2018. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of contributions: > > (1) 8210836: Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/c0f9161f591e > > (2) 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode > http://hg.openjdk.java.net/jdk/jdk/rev/948c62200f8c > > (3) 8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC > http://hg.openjdk.java.net/jdk/jdk/rev/e46b9e514479 > > (4) 8195613: [SA] HotSpotTypeDataBase.readVMLongConstants truncates values to int > http://hg.openjdk.java.net/jdk/jdk/rev/300e4a88c400 > > (5) 8174995: SA: clhsdb 'where -a' throws Assertion Failure with illegal code 236 when CDS is used > http://hg.openjdk.java.net/jdk/jdk/rev/55153a374d18 > > (6) 8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS > http://hg.openjdk.java.net/jdk/jdk/rev/ec2dd30adbc1 > > (7) 8175312: SA: clhsdb: Provide an improved heap summary for 'universe' for G1GC > http://hg.openjdk.java.net/jdk/jdk/rev/ccb003941743 > > (8) 8175384: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes > http://hg.openjdk.java.net/jdk/jdk/rev/d2a860bc50a3 > > (9) 8193352: SA: Test for the clhsdb 'thread' and 'threads' commands > http://hg.openjdk.java.net/jdk/jdk/rev/fdef4da95080 > > (10) 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands > http://hg.openjdk.java.net/jdk/jdk/rev/be065f758154 > > (11) 8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol > http://hg.openjdk.java.net/jdk/jdk/rev/61a14b5cb1c6 > > (12) 8191914: New SA test timeout on windows > http://hg.openjdk.java.net/jdk/jdk/rev/88ec5fca7726 > > (13) 8191324: SA cleanup -- part 2 > http://hg.openjdk.java.net/jdk/jdk/rev/2659c4fe8ea7 > > (14) 8191961: SA: Remove left over quarantined SA tests due to 8184042 from ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/111834dd10dd > > (15) 8191919: Include TestJhsdbJstackLock.java in ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/d851eb254409 > > (16) 8190307: SA tests for the clhsdb commands: universe, intconstant, type > http://hg.openjdk.java.net/jdk/jdk/rev/75d365bfc2e6 > > (17) 8189798: SA cleanup - part 1 > http://hg.openjdk.java.net/jdk/jdk/rev/ac0af7750da9 > > (18) 8184042: several serviceability/sa tests timed out on MacOS X > http://hg.openjdk.java.net/jdk/jdk/rev/dfb375d231fb > > (19) 8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 > http://hg.openjdk.java.net/jdk/jdk/rev/deab1e2f0ebf > > (20) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/2eab88a780e3 > > (21) 8162504: TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS > http://hg.openjdk.java.net/jdk/jdk/rev/4597fa06b227 > > (22) 8175054: Move new TestPrintMdo.java to hotspot/test directory > http://hg.openjdk.java.net/jdk/jdk/rev/d9ba85f5cb9d > > (23) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/c809fcb66c81 > > (24) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk/jdk/rev/a152f2d3320e > > (25) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk/jdk/rev/0b0ae99d8639 > http://hg.openjdk.java.net/jdk/jdk/rev/297ba2772122 > > (26) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk/jdk/rev/48d874bf85fb > > (27) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk/jdk/rev/a20695c30be5 > > (28) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/154099b110df > > (29) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk/jdk/rev/815cfbe4878b > > (30) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk/jdk/rev/afd6ae4fec81 > > (31) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk/jdk/rev/10e6e31dc1aa > > (32) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/815650daefb4 > > (33) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/aed0f6434aea > > (34) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk/jdk/rev/c0e02245ff93 > http://hg.openjdk.java.net/jdk/jdk/rev/12787d18650e > > (35) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk/jdk/rev/adf083cbc37f > > (36) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk/jdk/rev/8a2083c5e2b1 > http://hg.openjdk.java.net/jdk/jdk/rev/d46cac7959c4 > > (37) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk/jdk/rev/82ece130a37b > From javalists at cbfiddle.com Mon Oct 1 20:06:28 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 1 Oct 2018 13:06:28 -0700 Subject: JDK 11 minimum macOS release Message-ID: <1B3FF51F-C662-4247-B93F-E8F40D368FE0@cbfiddle.com> I notice that the Oracle installation page [1] for JDK 11 says that macOS 10.11 is required. (The OpenJDK release page [2] says nothing.) The code itself is built for macOS 10.9. Why the difference? Alan [1] https://docs.oracle.com/en/java/javase/11/install/overview-jdk-installation.html [2] http://jdk.java.net/11/ From serguei.spitsyn at oracle.com Wed Oct 3 06:13:53 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 2 Oct 2018 23:13:53 -0700 Subject: CFV: New JDK Reviewer: Jini George In-Reply-To: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> References: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> Message-ID: Vote: yes From ashipile at redhat.com Wed Oct 3 08:02:30 2018 From: ashipile at redhat.com (Aleksey Shipilev) Date: Wed, 3 Oct 2018 10:02:30 +0200 Subject: Is jdk/submit repo down? In-Reply-To: References: <24aacb6f-9964-7a77-b506-33fa4f236788@kennke.org> Message-ID: <6f861582-f47d-ad4a-9c65-e1425d7a9c2f@redhat.com> Hi Christian, On 10/01/2018 01:46 PM, Christian Tornqvist wrote: > There was a configuration issue with the submit repo, it?s been corrected and I?ve restarted the > jobs I could see. Sorry for the inconvenience. Are there other issues today? My job is in the queue for more than 12 hours now. -Aleksey From sean.coffey at oracle.com Wed Oct 3 14:54:59 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 3 Oct 2018 15:54:59 +0100 Subject: Tagging proposal for JDK GA releases Message-ID: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> I'd like to propose an enhancement to the JDK build-tagging convention to help users more easily identify JDK GA releases via Mercurial tag names. The concept is quite simple and lets people identify snapshots of GA releases in Mercurial history without having to know the build number of the GA release. For example, to obtain JDK 10.0.2 GA sources today, one issues the `hg update -r jdk-10.0.2+13` command. With the proposed enhancement, `hg update -r jdk-10.0.2-ga` could have been used. It's proposed that the new ga tag would be in addition to the regular GA build number tag. It would be added to the relevant repository once the GA milestone has been reached. This new convention would be used for future JDK releases and is tracked via JDK-8180946[1]. If the changes are adopted, I can look at retroactively adding labels for all feature JDK GA releases since JDK 7 to the JDK feature-release main-line repository. To accommodate the new tag format, some simple jcheck edits would be required. Test checks would also be added. Comments? regards, Sean. [1] https://bugs.openjdk.java.net/browse/JDK-8180946 From hohensee at amazon.com Wed Oct 3 15:25:18 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 3 Oct 2018 15:25:18 +0000 Subject: Tagging proposal for JDK GA releases In-Reply-To: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> Message-ID: <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> We at Amazon would find this useful. Thanks, Paul ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" wrote: I'd like to propose an enhancement to the JDK build-tagging convention to help users more easily identify JDK GA releases via Mercurial tag names. The concept is quite simple and lets people identify snapshots of GA releases in Mercurial history without having to know the build number of the GA release. For example, to obtain JDK 10.0.2 GA sources today, one issues the `hg update -r jdk-10.0.2+13` command. With the proposed enhancement, `hg update -r jdk-10.0.2-ga` could have been used. It's proposed that the new ga tag would be in addition to the regular GA build number tag. It would be added to the relevant repository once the GA milestone has been reached. This new convention would be used for future JDK releases and is tracked via JDK-8180946[1]. If the changes are adopted, I can look at retroactively adding labels for all feature JDK GA releases since JDK 7 to the JDK feature-release main-line repository. To accommodate the new tag format, some simple jcheck edits would be required. Test checks would also be added. Comments? regards, Sean. [1] https://bugs.openjdk.java.net/browse/JDK-8180946 From christian.tornqvist at oracle.com Wed Oct 3 15:39:09 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 3 Oct 2018 08:39:09 -0700 Subject: Is jdk/submit repo down? In-Reply-To: <6f861582-f47d-ad4a-9c65-e1425d7a9c2f@redhat.com> References: <24aacb6f-9964-7a77-b506-33fa4f236788@kennke.org> <6f861582-f47d-ad4a-9c65-e1425d7a9c2f@redhat.com> Message-ID: <44A12FE5-CFD8-48D2-8167-E39D55DF944A@oracle.com> Hi Aleksey, Your job seems to have hit some network issues that are no longer present, I?ve restarted your job and it should complete soon. Thanks, Christian > On Oct 3, 2018, at 1:02 AM, Aleksey Shipilev wrote: > > Hi Christian, > > On 10/01/2018 01:46 PM, Christian Tornqvist wrote: >> There was a configuration issue with the submit repo, it?s been corrected and I?ve restarted the >> jobs I could see. Sorry for the inconvenience. > > Are there other issues today? My job is in the queue for more than 12 hours now. > > -Aleksey From ashipile at redhat.com Wed Oct 3 15:39:46 2018 From: ashipile at redhat.com (Aleksey Shipilev) Date: Wed, 3 Oct 2018 17:39:46 +0200 Subject: Is jdk/submit repo down? In-Reply-To: <44A12FE5-CFD8-48D2-8167-E39D55DF944A@oracle.com> References: <24aacb6f-9964-7a77-b506-33fa4f236788@kennke.org> <6f861582-f47d-ad4a-9c65-e1425d7a9c2f@redhat.com> <44A12FE5-CFD8-48D2-8167-E39D55DF944A@oracle.com> Message-ID: <2e946aa0-3e48-7feb-a445-0121af7dca6f@redhat.com> On 10/03/2018 05:39 PM, Christian Tornqvist wrote: > Your job seems to have hit some network issues that are no longer present, I?ve restarted your > job and it should complete soon. Thank you! -Aleksey From martijnverburg at gmail.com Wed Oct 3 15:43:14 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 3 Oct 2018 16:43:14 +0100 Subject: Tagging proposal for JDK GA releases In-Reply-To: <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> Message-ID: Likewise at Adopt Cheers, Martijn On Wed, 3 Oct 2018 at 16:26, Hohensee, Paul wrote: > We at Amazon would find this useful. > > Thanks, > > Paul > > ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" < > jdk-updates-dev-bounces at openjdk.java.net on behalf of > sean.coffey at oracle.com> wrote: > > I'd like to propose an enhancement to the JDK build-tagging > convention to help users more easily identify JDK GA releases > via Mercurial tag names. > > The concept is quite simple and lets people identify snapshots > of GA releases in Mercurial history without having to know the > build number of the GA release. > > For example, to obtain JDK 10.0.2 GA sources today, one issues the > `hg update -r jdk-10.0.2+13` command. With the proposed > enhancement, `hg update -r jdk-10.0.2-ga` could have been used. > It's proposed that the new ga tag would be in addition to the regular > GA build number tag. It would be added to the relevant repository > once the GA milestone has been reached. > > This new convention would be used for future JDK releases and is > tracked via JDK-8180946[1]. If the changes are adopted, I can > look at retroactively adding labels for all feature JDK GA releases > since JDK 7 to the JDK feature-release main-line repository. > > To accommodate the new tag format, some simple jcheck edits > would be required. Test checks would also be added. > > Comments? > > regards, > Sean. > > [1] https://bugs.openjdk.java.net/browse/JDK-8180946 > > > From volker.simonis at gmail.com Thu Oct 4 08:15:44 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Oct 2018 11:15:44 +0300 Subject: Tagging proposal for JDK GA releases In-Reply-To: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> Message-ID: Sounds good! Thanks for driving this forward, Volker Se?n Coffey schrieb am Mi. 3. Okt. 2018 um 17:55: > I'd like to propose an enhancement to the JDK build-tagging > convention to help users more easily identify JDK GA releases > via Mercurial tag names. > > The concept is quite simple and lets people identify snapshots > of GA releases in Mercurial history without having to know the > build number of the GA release. > > For example, to obtain JDK 10.0.2 GA sources today, one issues the > `hg update -r jdk-10.0.2+13` command. With the proposed > enhancement, `hg update -r jdk-10.0.2-ga` could have been used. > It's proposed that the new ga tag would be in addition to the regular > GA build number tag. It would be added to the relevant repository > once the GA milestone has been reached. > > This new convention would be used for future JDK releases and is > tracked via JDK-8180946[1]. If the changes are adopted, I can > look at retroactively adding labels for all feature JDK GA releases > since JDK 7 to the JDK feature-release main-line repository. > > To accommodate the new tag format, some simple jcheck edits > would be required. Test checks would also be added. > > Comments? > > regards, > Sean. > > [1] https://bugs.openjdk.java.net/browse/JDK-8180946 > From goetz.lindenmaier at sap.com Thu Oct 4 08:19:38 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Oct 2018 08:19:38 +0000 Subject: Tagging proposal for JDK GA releases In-Reply-To: <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> Message-ID: Hi, I also think this would make things more clear. I want to propose another point I stumbled about lately. You all know that if I do hg clone -r jdk-10.0.2-ga I get all the changes, but not the change that tags the version. I often check for the hash of the change tagging the release and clone that. Then I have a repo whose last change is the ga tag. Unfortunately recently, the tag comes later and is not directly applied to the change it wants to tag, but a few changes later. E.g., tag 12+14 is applied on top of "8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError" while it tags "Merge 8897e41b327c": http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 * Added tag jdk-12+14 for changeset 8897e41b327c | * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError | * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative | * 8211150: G1 Full GC not purging code root memory and hence causing memory leak | * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false | * 8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI | * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF | * 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions)= | * Merge 8897e41b327c jdk-12+14 The following would be more convenient: *Merge | \ | * Added tag jdk-12+14 for changeset 8897e41b327c | | * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError | | * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative | | * | 8211150: G1 Full GC not purging code root memory and hence causing memory leak | | * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false | | * | 8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI | | * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF | | * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions)= | / * Merge 8897e41b327c jdk-12+14 Which easily can be achieved by doing hg update -r 8897e41b327c (the merge change) before doing hg tag -f. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Hohensee, Paul > Sent: Mittwoch, 3. Oktober 2018 17:25 > To: Se?n Coffey ; jdk-dev dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- > dev at openjdk.java.net > Subject: Re: Tagging proposal for JDK GA releases > > We at Amazon would find this useful. > > Thanks, > > Paul > > ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" updates-dev-bounces at openjdk.java.net on behalf of > sean.coffey at oracle.com> wrote: > > I'd like to propose an enhancement to the JDK build-tagging > convention to help users more easily identify JDK GA releases > via Mercurial tag names. > > The concept is quite simple and lets people identify snapshots > of GA releases in Mercurial history without having to know the > build number of the GA release. > > For example, to obtain JDK 10.0.2 GA sources today, one issues the > `hg update -r jdk-10.0.2+13` command. With the proposed > enhancement, `hg update -r jdk-10.0.2-ga` could have been used. > It's proposed that the new ga tag would be in addition to the regular > GA build number tag. It would be added to the relevant repository > once the GA milestone has been reached. > > This new convention would be used for future JDK releases and is > tracked via JDK-8180946[1]. If the changes are adopted, I can > look at retroactively adding labels for all feature JDK GA releases > since JDK 7 to the JDK feature-release main-line repository. > > To accommodate the new tag format, some simple jcheck edits > would be required. Test checks would also be added. > > Comments? > > regards, > Sean. > > [1] https://bugs.openjdk.java.net/browse/JDK-8180946 > From jesper.wilhelmsson at oracle.com Thu Oct 4 08:47:37 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 4 Oct 2018 10:47:37 +0200 Subject: Tagging proposal for JDK GA releases In-Reply-To: References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> Message-ID: <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> The proposal looks good to me. > On 4 Oct 2018, at 10:19, Lindenmaier, Goetz wrote: > > Hi, > > I also think this would make things more clear. > > I want to propose another point I stumbled about lately. > Sorry, my mistake. We are not supposed to tag merge changesets. I have re-tagged jdk-12+14 to a non-merge change. I would like to take the opportunity to highlight that the hg history would be a lot easier to work with if everyone remembers to rebase their changes before pushing. Then we would have a lot fewer merges in there. /Jesper > You all know that if I do hg clone -r jdk-10.0.2-ga > I get all the changes, but not the change that tags the version. > I often check for the hash of the change tagging the release > and clone that. Then I have a repo whose last change is the ga tag. > > Unfortunately recently, the tag comes later and is not directly > applied to the change it wants to tag, but a few changes later. E.g., > tag 12+14 is applied on top of "8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError" > while it tags "Merge 8897e41b327c": > http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 > > * Added tag jdk-12+14 for changeset 8897e41b327c > | > * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError > | > * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative > | > * 8211150: G1 Full GC not purging code root memory and hence causing memory leak > | > * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false > | > * 8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI > | > * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF > | > * 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions)= > | > * Merge 8897e41b327c jdk-12+14 > > The following would be more convenient: > > *Merge > | \ > | * Added tag jdk-12+14 for changeset 8897e41b327c > | | > * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError > | | > * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative > | | > * | 8211150: G1 Full GC not purging code root memory and hence causing memory leak > | | > * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false > | | > * | 8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI > | | > * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF > | | > * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions)= > | / > * Merge 8897e41b327c jdk-12+14 > > Which easily can be achieved by doing hg update -r 8897e41b327c (the merge change) > before doing hg tag -f. > > Best regards, > Goetz. > > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Hohensee, Paul >> Sent: Mittwoch, 3. Oktober 2018 17:25 >> To: Se?n Coffey ; jdk-dev > dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- >> dev at openjdk.java.net >> Subject: Re: Tagging proposal for JDK GA releases >> >> We at Amazon would find this useful. >> >> Thanks, >> >> Paul >> >> ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" > updates-dev-bounces at openjdk.java.net on behalf of >> sean.coffey at oracle.com> wrote: >> >> I'd like to propose an enhancement to the JDK build-tagging >> convention to help users more easily identify JDK GA releases >> via Mercurial tag names. >> >> The concept is quite simple and lets people identify snapshots >> of GA releases in Mercurial history without having to know the >> build number of the GA release. >> >> For example, to obtain JDK 10.0.2 GA sources today, one issues the >> `hg update -r jdk-10.0.2+13` command. With the proposed >> enhancement, `hg update -r jdk-10.0.2-ga` could have been used. >> It's proposed that the new ga tag would be in addition to the regular >> GA build number tag. It would be added to the relevant repository >> once the GA milestone has been reached. >> >> This new convention would be used for future JDK releases and is >> tracked via JDK-8180946[1]. If the changes are adopted, I can >> look at retroactively adding labels for all feature JDK GA releases >> since JDK 7 to the JDK feature-release main-line repository. >> >> To accommodate the new tag format, some simple jcheck edits >> would be required. Test checks would also be added. >> >> Comments? >> >> regards, >> Sean. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8180946 >> > From goetz.lindenmaier at sap.com Thu Oct 4 09:09:55 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Oct 2018 09:09:55 +0000 Subject: Tagging proposal for JDK GA releases In-Reply-To: <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> Message-ID: <0a18f1ae2a20475ea782db906c24e2ae@sap.com> Hi Jesper, I didn't mean that the tag is on a Merge changeset, I didn't know that rule. What I mean is, in other words than in my mail below: I would like that the parent of the tag change is the change to be tagged. I know this means that there will be a merge, but it seems worth while. Best regards, Goetz. > -----Original Message----- > From: jesper.wilhelmsson at oracle.com > Sent: Donnerstag, 4. Oktober 2018 10:48 > To: Lindenmaier, Goetz > Cc: Hohensee, Paul ; Se?n Coffey > ; jdk-dev ; jdk- > updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: Re: Tagging proposal for JDK GA releases > > The proposal looks good to me. > > > On 4 Oct 2018, at 10:19, Lindenmaier, Goetz > wrote: > > > > Hi, > > > > I also think this would make things more clear. > > > > I want to propose another point I stumbled about lately. > > > > Sorry, my mistake. We are not supposed to tag merge changesets. > I have re-tagged jdk-12+14 to a non-merge change. > > I would like to take the opportunity to highlight that the hg history would be > a lot easier to work with if everyone remembers to rebase their changes > before pushing. Then we would have a lot fewer merges in there. > /Jesper > > > You all know that if I do hg clone -r jdk-10.0.2-ga > > I get all the changes, but not the change that tags the version. > > I often check for the hash of the change tagging the release > > and clone that. Then I have a repo whose last change is the ga tag. > > > > Unfortunately recently, the tag comes later and is not directly > > applied to the change it wants to tag, but a few changes later. E.g., > > tag 12+14 is applied on top of "8202359: [GRAAL] > compiler/uncommontrap/TestDeoptOOM.java failed with > OutOfMemoryError" > > while it tags "Merge 8897e41b327c": > > http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 > > > > * Added tag jdk-12+14 for changeset 8897e41b327c > > | > > * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed > with OutOfMemoryError > > | > > * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths > when directory is relative > > | > > * 8211150: G1 Full GC not purging code root memory and hence causing > memory leak > > | > > * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with > expected value: false > > | > > * 8211392: > compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times > out in JDK12 CI > > | > > * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF > > | > > * 8211375: Minimal VM build failures after JDK-8211251 (Default mask > register for avx512 instructions)= > > | > > * Merge 8897e41b327c jdk-12+14 > > > > The following would be more convenient: > > > > *Merge > > | \ > > | * Added tag jdk-12+14 for changeset 8897e41b327c > > | | > > * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java > failed with OutOfMemoryError > > | | > > * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths > when directory is relative > > | | > > * | 8211150: G1 Full GC not purging code root memory and hence causing > memory leak > > | | > > * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with > expected value: false > > | | > > * | 8211392: > compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times > out in JDK12 CI > > | | > > * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF > > | | > > * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask > register for avx512 instructions)= > > | / > > * Merge 8897e41b327c jdk-12+14 > > > > Which easily can be achieved by doing hg update -r 8897e41b327c (the > merge change) > > before doing hg tag -f. > > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: jdk-updates-dev > On > >> Behalf Of Hohensee, Paul > >> Sent: Mittwoch, 3. Oktober 2018 17:25 > >> To: Se?n Coffey ; jdk-dev >> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- > >> dev at openjdk.java.net > >> Subject: Re: Tagging proposal for JDK GA releases > >> > >> We at Amazon would find this useful. > >> > >> Thanks, > >> > >> Paul > >> > >> ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" >> updates-dev-bounces at openjdk.java.net on behalf of > >> sean.coffey at oracle.com> wrote: > >> > >> I'd like to propose an enhancement to the JDK build-tagging > >> convention to help users more easily identify JDK GA releases > >> via Mercurial tag names. > >> > >> The concept is quite simple and lets people identify snapshots > >> of GA releases in Mercurial history without having to know the > >> build number of the GA release. > >> > >> For example, to obtain JDK 10.0.2 GA sources today, one issues the > >> `hg update -r jdk-10.0.2+13` command. With the proposed > >> enhancement, `hg update -r jdk-10.0.2-ga` could have been used. > >> It's proposed that the new ga tag would be in addition to the regular > >> GA build number tag. It would be added to the relevant repository > >> once the GA milestone has been reached. > >> > >> This new convention would be used for future JDK releases and is > >> tracked via JDK-8180946[1]. If the changes are adopted, I can > >> look at retroactively adding labels for all feature JDK GA releases > >> since JDK 7 to the JDK feature-release main-line repository. > >> > >> To accommodate the new tag format, some simple jcheck edits > >> would be required. Test checks would also be added. > >> > >> Comments? > >> > >> regards, > >> Sean. > >> > >> [1] https://bugs.openjdk.java.net/browse/JDK-8180946 > >> > > From jesper.wilhelmsson at oracle.com Thu Oct 4 09:37:30 2018 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 4 Oct 2018 11:37:30 +0200 Subject: Tagging proposal for JDK GA releases In-Reply-To: <0a18f1ae2a20475ea782db906c24e2ae@sap.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> <0a18f1ae2a20475ea782db906c24e2ae@sap.com> Message-ID: > 4 okt. 2018 kl. 11:09 skrev Lindenmaier, Goetz : > > Hi Jesper, > > I didn't mean that the tag is on a Merge changeset, > I didn't know that rule. It?s more a guideline than a rule I guess. But I?ve heard it can cause issues in some cases. > What I mean is, in other words than in my mail below: > I would like that the parent of the tag change is the > change to be tagged. > I know this means that there will be a merge, but > it seems worth while. Has it been done this way in the past? I?ve only been tagging promoted builds for a short while, I may be missing some step that was part of the process before. /Jesper > Best regards, > Goetz. > >> -----Original Message----- >> From: jesper.wilhelmsson at oracle.com >> Sent: Donnerstag, 4. Oktober 2018 10:48 >> To: Lindenmaier, Goetz >> Cc: Hohensee, Paul ; Se?n Coffey >> ; jdk-dev ; jdk- >> updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net >> Subject: Re: Tagging proposal for JDK GA releases >> >> The proposal looks good to me. >> >>> On 4 Oct 2018, at 10:19, Lindenmaier, Goetz >> wrote: >>> >>> Hi, >>> >>> I also think this would make things more clear. >>> >>> I want to propose another point I stumbled about lately. >>> >> >> Sorry, my mistake. We are not supposed to tag merge changesets. >> I have re-tagged jdk-12+14 to a non-merge change. >> >> I would like to take the opportunity to highlight that the hg history would be >> a lot easier to work with if everyone remembers to rebase their changes >> before pushing. Then we would have a lot fewer merges in there. >> /Jesper >> >>> You all know that if I do hg clone -r jdk-10.0.2-ga >>> I get all the changes, but not the change that tags the version. >>> I often check for the hash of the change tagging the release >>> and clone that. Then I have a repo whose last change is the ga tag. >>> >>> Unfortunately recently, the tag comes later and is not directly >>> applied to the change it wants to tag, but a few changes later. E.g., >>> tag 12+14 is applied on top of "8202359: [GRAAL] >> compiler/uncommontrap/TestDeoptOOM.java failed with >> OutOfMemoryError" >>> while it tags "Merge 8897e41b327c": >>> http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 >>> >>> * Added tag jdk-12+14 for changeset 8897e41b327c >>> | >>> * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed >> with OutOfMemoryError >>> | >>> * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths >> when directory is relative >>> | >>> * 8211150: G1 Full GC not purging code root memory and hence causing >> memory leak >>> | >>> * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with >> expected value: false >>> | >>> * 8211392: >> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times >> out in JDK12 CI >>> | >>> * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >>> | >>> * 8211375: Minimal VM build failures after JDK-8211251 (Default mask >> register for avx512 instructions)= >>> | >>> * Merge 8897e41b327c jdk-12+14 >>> >>> The following would be more convenient: >>> >>> *Merge >>> | \ >>> | * Added tag jdk-12+14 for changeset 8897e41b327c >>> | | >>> * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java >> failed with OutOfMemoryError >>> | | >>> * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths >> when directory is relative >>> | | >>> * | 8211150: G1 Full GC not purging code root memory and hence causing >> memory leak >>> | | >>> * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with >> expected value: false >>> | | >>> * | 8211392: >> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times >> out in JDK12 CI >>> | | >>> * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >>> | | >>> * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask >> register for avx512 instructions)= >>> | / >>> * Merge 8897e41b327c jdk-12+14 >>> >>> Which easily can be achieved by doing hg update -r 8897e41b327c (the >> merge change) >>> before doing hg tag -f. >>> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: jdk-updates-dev >> On >>>> Behalf Of Hohensee, Paul >>>> Sent: Mittwoch, 3. Oktober 2018 17:25 >>>> To: Se?n Coffey ; jdk-dev >>> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- >>>> dev at openjdk.java.net >>>> Subject: Re: Tagging proposal for JDK GA releases >>>> >>>> We at Amazon would find this useful. >>>> >>>> Thanks, >>>> >>>> Paul >>>> >>>> ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" >>> updates-dev-bounces at openjdk.java.net on behalf of >>>> sean.coffey at oracle.com> wrote: >>>> >>>> I'd like to propose an enhancement to the JDK build-tagging >>>> convention to help users more easily identify JDK GA releases >>>> via Mercurial tag names. >>>> >>>> The concept is quite simple and lets people identify snapshots >>>> of GA releases in Mercurial history without having to know the >>>> build number of the GA release. >>>> >>>> For example, to obtain JDK 10.0.2 GA sources today, one issues the >>>> `hg update -r jdk-10.0.2+13` command. With the proposed >>>> enhancement, `hg update -r jdk-10.0.2-ga` could have been used. >>>> It's proposed that the new ga tag would be in addition to the regular >>>> GA build number tag. It would be added to the relevant repository >>>> once the GA milestone has been reached. >>>> >>>> This new convention would be used for future JDK releases and is >>>> tracked via JDK-8180946[1]. If the changes are adopted, I can >>>> look at retroactively adding labels for all feature JDK GA releases >>>> since JDK 7 to the JDK feature-release main-line repository. >>>> >>>> To accommodate the new tag format, some simple jcheck edits >>>> would be required. Test checks would also be added. >>>> >>>> Comments? >>>> >>>> regards, >>>> Sean. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8180946 >>>> >>> > From goetz.lindenmaier at sap.com Thu Oct 4 09:44:19 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Oct 2018 09:44:19 +0000 Subject: Tagging proposal for JDK GA releases In-Reply-To: References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> <0a18f1ae2a20475ea782db906c24e2ae@sap.com> Message-ID: <9199693ea8174d7d89674323b9d5c4f1@sap.com> Hi I think before, when no-one committed to jdk/jdk because there were the hs/comp/gc etc repositories it happened by process. I.e., no changes were merged into the repo before the build was tagged. I think all the jdk10 tags have the tagged change for parent. This is no more the case since jdk11. Best regards, Goetz. > -----Original Message----- > From: Jesper Wilhelmsson > Sent: Donnerstag, 4. Oktober 2018 11:38 > To: Lindenmaier, Goetz > Cc: Hohensee, Paul ; Se?n Coffey > ; jdk-dev ; jdk- > updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: Re: Tagging proposal for JDK GA releases > > > > > 4 okt. 2018 kl. 11:09 skrev Lindenmaier, Goetz > : > > > > Hi Jesper, > > > > I didn't mean that the tag is on a Merge changeset, > > I didn't know that rule. > > It?s more a guideline than a rule I guess. But I?ve heard it can cause issues in > some cases. > > > What I mean is, in other words than in my mail below: > > I would like that the parent of the tag change is the > > change to be tagged. > > I know this means that there will be a merge, but > > it seems worth while. > > Has it been done this way in the past? I?ve only been tagging promoted > builds for a short while, I may be missing some step that was part of the > process before. > /Jesper > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: jesper.wilhelmsson at oracle.com > > >> Sent: Donnerstag, 4. Oktober 2018 10:48 > >> To: Lindenmaier, Goetz > >> Cc: Hohensee, Paul ; Se?n Coffey > >> ; jdk-dev ; jdk- > >> updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > >> Subject: Re: Tagging proposal for JDK GA releases > >> > >> The proposal looks good to me. > >> > >>> On 4 Oct 2018, at 10:19, Lindenmaier, Goetz > > >> wrote: > >>> > >>> Hi, > >>> > >>> I also think this would make things more clear. > >>> > >>> I want to propose another point I stumbled about lately. > >>> > >> > >> Sorry, my mistake. We are not supposed to tag merge changesets. > >> I have re-tagged jdk-12+14 to a non-merge change. > >> > >> I would like to take the opportunity to highlight that the hg history would > be > >> a lot easier to work with if everyone remembers to rebase their changes > >> before pushing. Then we would have a lot fewer merges in there. > >> /Jesper > >> > >>> You all know that if I do hg clone -r jdk-10.0.2-ga > >>> I get all the changes, but not the change that tags the version. > >>> I often check for the hash of the change tagging the release > >>> and clone that. Then I have a repo whose last change is the ga tag. > >>> > >>> Unfortunately recently, the tag comes later and is not directly > >>> applied to the change it wants to tag, but a few changes later. E.g., > >>> tag 12+14 is applied on top of "8202359: [GRAAL] > >> compiler/uncommontrap/TestDeoptOOM.java failed with > >> OutOfMemoryError" > >>> while it tags "Merge 8897e41b327c": > >>> http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 > >>> > >>> * Added tag jdk-12+14 for changeset 8897e41b327c > >>> | > >>> * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java > failed > >> with OutOfMemoryError > >>> | > >>> * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths > >> when directory is relative > >>> | > >>> * 8211150: G1 Full GC not purging code root memory and hence causing > >> memory leak > >>> | > >>> * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with > >> expected value: false > >>> | > >>> * 8211392: > >> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java > times > >> out in JDK12 CI > >>> | > >>> * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF > >>> | > >>> * 8211375: Minimal VM build failures after JDK-8211251 (Default mask > >> register for avx512 instructions)= > >>> | > >>> * Merge 8897e41b327c jdk-12+14 > >>> > >>> The following would be more convenient: > >>> > >>> *Merge > >>> | \ > >>> | * Added tag jdk-12+14 for changeset 8897e41b327c > >>> | | > >>> * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java > >> failed with OutOfMemoryError > >>> | | > >>> * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute > paths > >> when directory is relative > >>> | | > >>> * | 8211150: G1 Full GC not purging code root memory and hence > causing > >> memory leak > >>> | | > >>> * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with > >> expected value: false > >>> | | > >>> * | 8211392: > >> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java > times > >> out in JDK12 CI > >>> | | > >>> * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF > >>> | | > >>> * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask > >> register for avx512 instructions)= > >>> | / > >>> * Merge 8897e41b327c jdk-12+14 > >>> > >>> Which easily can be achieved by doing hg update -r 8897e41b327c (the > >> merge change) > >>> before doing hg tag -f. > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: jdk-updates-dev bounces at openjdk.java.net> > >> On > >>>> Behalf Of Hohensee, Paul > >>>> Sent: Mittwoch, 3. Oktober 2018 17:25 > >>>> To: Se?n Coffey ; jdk-dev >>>> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- > >>>> dev at openjdk.java.net > >>>> Subject: Re: Tagging proposal for JDK GA releases > >>>> > >>>> We at Amazon would find this useful. > >>>> > >>>> Thanks, > >>>> > >>>> Paul > >>>> > >>>> ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" >>>> updates-dev-bounces at openjdk.java.net on behalf of > >>>> sean.coffey at oracle.com> wrote: > >>>> > >>>> I'd like to propose an enhancement to the JDK build-tagging > >>>> convention to help users more easily identify JDK GA releases > >>>> via Mercurial tag names. > >>>> > >>>> The concept is quite simple and lets people identify snapshots > >>>> of GA releases in Mercurial history without having to know the > >>>> build number of the GA release. > >>>> > >>>> For example, to obtain JDK 10.0.2 GA sources today, one issues the > >>>> `hg update -r jdk-10.0.2+13` command. With the proposed > >>>> enhancement, `hg update -r jdk-10.0.2-ga` could have been used. > >>>> It's proposed that the new ga tag would be in addition to the regular > >>>> GA build number tag. It would be added to the relevant repository > >>>> once the GA milestone has been reached. > >>>> > >>>> This new convention would be used for future JDK releases and is > >>>> tracked via JDK-8180946[1]. If the changes are adopted, I can > >>>> look at retroactively adding labels for all feature JDK GA releases > >>>> since JDK 7 to the JDK feature-release main-line repository. > >>>> > >>>> To accommodate the new tag format, some simple jcheck edits > >>>> would be required. Test checks would also be added. > >>>> > >>>> Comments? > >>>> > >>>> regards, > >>>> Sean. > >>>> > >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8180946 > >>>> > >>> > > From jesper.wilhelmsson at oracle.com Thu Oct 4 09:58:37 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 4 Oct 2018 11:58:37 +0200 Subject: Tagging proposal for JDK GA releases In-Reply-To: <9199693ea8174d7d89674323b9d5c4f1@sap.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> <0a18f1ae2a20475ea782db906c24e2ae@sap.com> <9199693ea8174d7d89674323b9d5c4f1@sap.com> Message-ID: <6B8C902C-F2BD-454C-9FB4-8F98EEF52A43@oracle.com> Hi Goetz, I see, so it was more by accident than on purpose it was that way before. Let's not hijack this thread with this discussion, it should be discussed as a separate suggestion. Personally I'm not in favor for adding more merge changesets but that doesn't mean I won't do it if there is a good reason for it. Thanks, /Jesper > On 4 Oct 2018, at 11:44, Lindenmaier, Goetz wrote: > > Hi > > I think before, when no-one committed to jdk/jdk because there were the hs/comp/gc etc > repositories it happened by process. I.e., no changes were merged into the repo > before the build was tagged. > > I think all the jdk10 tags have the tagged change for parent. > This is no more the case since jdk11. > > Best regards, > Goetz. > > >> -----Original Message----- >> From: Jesper Wilhelmsson >> Sent: Donnerstag, 4. Oktober 2018 11:38 >> To: Lindenmaier, Goetz >> Cc: Hohensee, Paul ; Se?n Coffey >> ; jdk-dev ; jdk- >> updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net >> Subject: Re: Tagging proposal for JDK GA releases >> >> >> >>> 4 okt. 2018 kl. 11:09 skrev Lindenmaier, Goetz >> : >>> >>> Hi Jesper, >>> >>> I didn't mean that the tag is on a Merge changeset, >>> I didn't know that rule. >> >> It?s more a guideline than a rule I guess. But I?ve heard it can cause issues in >> some cases. >> >>> What I mean is, in other words than in my mail below: >>> I would like that the parent of the tag change is the >>> change to be tagged. >>> I know this means that there will be a merge, but >>> it seems worth while. >> >> Has it been done this way in the past? I?ve only been tagging promoted >> builds for a short while, I may be missing some step that was part of the >> process before. >> /Jesper >> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: jesper.wilhelmsson at oracle.com >> >>>> Sent: Donnerstag, 4. Oktober 2018 10:48 >>>> To: Lindenmaier, Goetz >>>> Cc: Hohensee, Paul ; Se?n Coffey >>>> ; jdk-dev ; jdk- >>>> updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net >>>> Subject: Re: Tagging proposal for JDK GA releases >>>> >>>> The proposal looks good to me. >>>> >>>>> On 4 Oct 2018, at 10:19, Lindenmaier, Goetz >> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I also think this would make things more clear. >>>>> >>>>> I want to propose another point I stumbled about lately. >>>>> >>>> >>>> Sorry, my mistake. We are not supposed to tag merge changesets. >>>> I have re-tagged jdk-12+14 to a non-merge change. >>>> >>>> I would like to take the opportunity to highlight that the hg history would >> be >>>> a lot easier to work with if everyone remembers to rebase their changes >>>> before pushing. Then we would have a lot fewer merges in there. >>>> /Jesper >>>> >>>>> You all know that if I do hg clone -r jdk-10.0.2-ga >>>>> I get all the changes, but not the change that tags the version. >>>>> I often check for the hash of the change tagging the release >>>>> and clone that. Then I have a repo whose last change is the ga tag. >>>>> >>>>> Unfortunately recently, the tag comes later and is not directly >>>>> applied to the change it wants to tag, but a few changes later. E.g., >>>>> tag 12+14 is applied on top of "8202359: [GRAAL] >>>> compiler/uncommontrap/TestDeoptOOM.java failed with >>>> OutOfMemoryError" >>>>> while it tags "Merge 8897e41b327c": >>>>> http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 >>>>> >>>>> * Added tag jdk-12+14 for changeset 8897e41b327c >>>>> | >>>>> * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java >> failed >>>> with OutOfMemoryError >>>>> | >>>>> * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths >>>> when directory is relative >>>>> | >>>>> * 8211150: G1 Full GC not purging code root memory and hence causing >>>> memory leak >>>>> | >>>>> * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with >>>> expected value: false >>>>> | >>>>> * 8211392: >>>> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java >> times >>>> out in JDK12 CI >>>>> | >>>>> * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >>>>> | >>>>> * 8211375: Minimal VM build failures after JDK-8211251 (Default mask >>>> register for avx512 instructions)= >>>>> | >>>>> * Merge 8897e41b327c jdk-12+14 >>>>> >>>>> The following would be more convenient: >>>>> >>>>> *Merge >>>>> | \ >>>>> | * Added tag jdk-12+14 for changeset 8897e41b327c >>>>> | | >>>>> * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java >>>> failed with OutOfMemoryError >>>>> | | >>>>> * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute >> paths >>>> when directory is relative >>>>> | | >>>>> * | 8211150: G1 Full GC not purging code root memory and hence >> causing >>>> memory leak >>>>> | | >>>>> * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with >>>> expected value: false >>>>> | | >>>>> * | 8211392: >>>> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java >> times >>>> out in JDK12 CI >>>>> | | >>>>> * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >>>>> | | >>>>> * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask >>>> register for avx512 instructions)= >>>>> | / >>>>> * Merge 8897e41b327c jdk-12+14 >>>>> >>>>> Which easily can be achieved by doing hg update -r 8897e41b327c (the >>>> merge change) >>>>> before doing hg tag -f. >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: jdk-updates-dev > bounces at openjdk.java.net> >>>> On >>>>>> Behalf Of Hohensee, Paul >>>>>> Sent: Mittwoch, 3. Oktober 2018 17:25 >>>>>> To: Se?n Coffey ; jdk-dev >>>>> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: Tagging proposal for JDK GA releases >>>>>> >>>>>> We at Amazon would find this useful. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Paul >>>>>> >>>>>> ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" >>>>> updates-dev-bounces at openjdk.java.net on behalf of >>>>>> sean.coffey at oracle.com> wrote: >>>>>> >>>>>> I'd like to propose an enhancement to the JDK build-tagging >>>>>> convention to help users more easily identify JDK GA releases >>>>>> via Mercurial tag names. >>>>>> >>>>>> The concept is quite simple and lets people identify snapshots >>>>>> of GA releases in Mercurial history without having to know the >>>>>> build number of the GA release. >>>>>> >>>>>> For example, to obtain JDK 10.0.2 GA sources today, one issues the >>>>>> `hg update -r jdk-10.0.2+13` command. With the proposed >>>>>> enhancement, `hg update -r jdk-10.0.2-ga` could have been used. >>>>>> It's proposed that the new ga tag would be in addition to the regular >>>>>> GA build number tag. It would be added to the relevant repository >>>>>> once the GA milestone has been reached. >>>>>> >>>>>> This new convention would be used for future JDK releases and is >>>>>> tracked via JDK-8180946[1]. If the changes are adopted, I can >>>>>> look at retroactively adding labels for all feature JDK GA releases >>>>>> since JDK 7 to the JDK feature-release main-line repository. >>>>>> >>>>>> To accommodate the new tag format, some simple jcheck edits >>>>>> would be required. Test checks would also be added. >>>>>> >>>>>> Comments? >>>>>> >>>>>> regards, >>>>>> Sean. >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8180946 >>>>>> >>>>> >>> > From kevin.rushforth at oracle.com Thu Oct 4 11:43:05 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 4 Oct 2018 04:43:05 -0700 Subject: Tagging proposal for JDK GA releases In-Reply-To: <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> Message-ID: <9f54fa26-c82d-98d9-3fd5-7b817f2387e1@oracle.com> > Sorry, my mistake. We are not supposed to tag merge changesets. > I have re-tagged jdk-12+14 to a non-merge change. I don't understand this comment. If the merge changeset is what you built from then why wouldn't you tag that? If you don't, then you won't be tagging the sources as they were built. -- Kevin On 10/4/2018 1:47 AM, jesper.wilhelmsson at oracle.com wrote: > The proposal looks good to me. > >> On 4 Oct 2018, at 10:19, Lindenmaier, Goetz wrote: >> >> Hi, >> >> I also think this would make things more clear. >> >> I want to propose another point I stumbled about lately. >> > Sorry, my mistake. We are not supposed to tag merge changesets. > I have re-tagged jdk-12+14 to a non-merge change. > > I would like to take the opportunity to highlight that the hg history would be a lot easier to work with if everyone remembers to rebase their changes before pushing. Then we would have a lot fewer merges in there. > /Jesper > >> You all know that if I do hg clone -r jdk-10.0.2-ga >> I get all the changes, but not the change that tags the version. >> I often check for the hash of the change tagging the release >> and clone that. Then I have a repo whose last change is the ga tag. >> >> Unfortunately recently, the tag comes later and is not directly >> applied to the change it wants to tag, but a few changes later. E.g., >> tag 12+14 is applied on top of "8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError" >> while it tags "Merge 8897e41b327c": >> http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 >> >> * Added tag jdk-12+14 for changeset 8897e41b327c >> | >> * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError >> | >> * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative >> | >> * 8211150: G1 Full GC not purging code root memory and hence causing memory leak >> | >> * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false >> | >> * 8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI >> | >> * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >> | >> * 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions)= >> | >> * Merge 8897e41b327c jdk-12+14 >> >> The following would be more convenient: >> >> *Merge >> | \ >> | * Added tag jdk-12+14 for changeset 8897e41b327c >> | | >> * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed with OutOfMemoryError >> | | >> * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative >> | | >> * | 8211150: G1 Full GC not purging code root memory and hence causing memory leak >> | | >> * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false >> | | >> * | 8211392: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times out in JDK12 CI >> | | >> * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >> | | >> * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask register for avx512 instructions)= >> | / >> * Merge 8897e41b327c jdk-12+14 >> >> Which easily can be achieved by doing hg update -r 8897e41b327c (the merge change) >> before doing hg tag -f. >> >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: jdk-updates-dev On >>> Behalf Of Hohensee, Paul >>> Sent: Mittwoch, 3. Oktober 2018 17:25 >>> To: Se?n Coffey ; jdk-dev >> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- >>> dev at openjdk.java.net >>> Subject: Re: Tagging proposal for JDK GA releases >>> >>> We at Amazon would find this useful. >>> >>> Thanks, >>> >>> Paul >>> >>> ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" >> updates-dev-bounces at openjdk.java.net on behalf of >>> sean.coffey at oracle.com> wrote: >>> >>> I'd like to propose an enhancement to the JDK build-tagging >>> convention to help users more easily identify JDK GA releases >>> via Mercurial tag names. >>> >>> The concept is quite simple and lets people identify snapshots >>> of GA releases in Mercurial history without having to know the >>> build number of the GA release. >>> >>> For example, to obtain JDK 10.0.2 GA sources today, one issues the >>> `hg update -r jdk-10.0.2+13` command. With the proposed >>> enhancement, `hg update -r jdk-10.0.2-ga` could have been used. >>> It's proposed that the new ga tag would be in addition to the regular >>> GA build number tag. It would be added to the relevant repository >>> once the GA milestone has been reached. >>> >>> This new convention would be used for future JDK releases and is >>> tracked via JDK-8180946[1]. If the changes are adopted, I can >>> look at retroactively adding labels for all feature JDK GA releases >>> since JDK 7 to the JDK feature-release main-line repository. >>> >>> To accommodate the new tag format, some simple jcheck edits >>> would be required. Test checks would also be added. >>> >>> Comments? >>> >>> regards, >>> Sean. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8180946 >>> From kevin.rushforth at oracle.com Thu Oct 4 11:45:05 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 4 Oct 2018 04:45:05 -0700 Subject: Tagging proposal for JDK GA releases In-Reply-To: <0a18f1ae2a20475ea782db906c24e2ae@sap.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> <0a18f1ae2a20475ea782db906c24e2ae@sap.com> Message-ID: > I didn't mean that the tag is on a Merge changeset, > I didn't know that rule. There is no such rule (and if there is, it would be wrong). > What I mean is, in other words than in my mail below: > I would like that the parent of the tag change is the > change to be tagged. This seems like a good idea, even if it does generate an extra merge changeset. -- Kevin On 10/4/2018 2:09 AM, Lindenmaier, Goetz wrote: > Hi Jesper, > > I didn't mean that the tag is on a Merge changeset, > I didn't know that rule. > > What I mean is, in other words than in my mail below: > I would like that the parent of the tag change is the > change to be tagged. > I know this means that there will be a merge, but > it seems worth while. > > Best regards, > Goetz. > >> -----Original Message----- >> From: jesper.wilhelmsson at oracle.com >> Sent: Donnerstag, 4. Oktober 2018 10:48 >> To: Lindenmaier, Goetz >> Cc: Hohensee, Paul ; Se?n Coffey >> ; jdk-dev ; jdk- >> updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net >> Subject: Re: Tagging proposal for JDK GA releases >> >> The proposal looks good to me. >> >>> On 4 Oct 2018, at 10:19, Lindenmaier, Goetz >> wrote: >>> Hi, >>> >>> I also think this would make things more clear. >>> >>> I want to propose another point I stumbled about lately. >>> >> Sorry, my mistake. We are not supposed to tag merge changesets. >> I have re-tagged jdk-12+14 to a non-merge change. >> >> I would like to take the opportunity to highlight that the hg history would be >> a lot easier to work with if everyone remembers to rebase their changes >> before pushing. Then we would have a lot fewer merges in there. >> /Jesper >> >>> You all know that if I do hg clone -r jdk-10.0.2-ga >>> I get all the changes, but not the change that tags the version. >>> I often check for the hash of the change tagging the release >>> and clone that. Then I have a repo whose last change is the ga tag. >>> >>> Unfortunately recently, the tag comes later and is not directly >>> applied to the change it wants to tag, but a few changes later. E.g., >>> tag 12+14 is applied on top of "8202359: [GRAAL] >> compiler/uncommontrap/TestDeoptOOM.java failed with >> OutOfMemoryError" >>> while it tags "Merge 8897e41b327c": >>> http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 >>> >>> * Added tag jdk-12+14 for changeset 8897e41b327c >>> | >>> * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed >> with OutOfMemoryError >>> | >>> * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths >> when directory is relative >>> | >>> * 8211150: G1 Full GC not purging code root memory and hence causing >> memory leak >>> | >>> * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with >> expected value: false >>> | >>> * 8211392: >> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times >> out in JDK12 CI >>> | >>> * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >>> | >>> * 8211375: Minimal VM build failures after JDK-8211251 (Default mask >> register for avx512 instructions)= >>> | >>> * Merge 8897e41b327c jdk-12+14 >>> >>> The following would be more convenient: >>> >>> *Merge >>> | \ >>> | * Added tag jdk-12+14 for changeset 8897e41b327c >>> | | >>> * | 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java >> failed with OutOfMemoryError >>> | | >>> * | 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths >> when directory is relative >>> | | >>> * | 8211150: G1 Full GC not purging code root memory and hence causing >> memory leak >>> | | >>> * | 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with >> expected value: false >>> | | >>> * | 8211392: >> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java times >> out in JDK12 CI >>> | | >>> * | 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >>> | | >>> * | 8211375: Minimal VM build failures after JDK-8211251 (Default mask >> register for avx512 instructions)= >>> | / >>> * Merge 8897e41b327c jdk-12+14 >>> >>> Which easily can be achieved by doing hg update -r 8897e41b327c (the >> merge change) >>> before doing hg tag -f. >>> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: jdk-updates-dev >> On >>>> Behalf Of Hohensee, Paul >>>> Sent: Mittwoch, 3. Oktober 2018 17:25 >>>> To: Se?n Coffey ; jdk-dev >>> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- >>>> dev at openjdk.java.net >>>> Subject: Re: Tagging proposal for JDK GA releases >>>> >>>> We at Amazon would find this useful. >>>> >>>> Thanks, >>>> >>>> Paul >>>> >>>> ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" >>> updates-dev-bounces at openjdk.java.net on behalf of >>>> sean.coffey at oracle.com> wrote: >>>> >>>> I'd like to propose an enhancement to the JDK build-tagging >>>> convention to help users more easily identify JDK GA releases >>>> via Mercurial tag names. >>>> >>>> The concept is quite simple and lets people identify snapshots >>>> of GA releases in Mercurial history without having to know the >>>> build number of the GA release. >>>> >>>> For example, to obtain JDK 10.0.2 GA sources today, one issues the >>>> `hg update -r jdk-10.0.2+13` command. With the proposed >>>> enhancement, `hg update -r jdk-10.0.2-ga` could have been used. >>>> It's proposed that the new ga tag would be in addition to the regular >>>> GA build number tag. It would be added to the relevant repository >>>> once the GA milestone has been reached. >>>> >>>> This new convention would be used for future JDK releases and is >>>> tracked via JDK-8180946[1]. If the changes are adopted, I can >>>> look at retroactively adding labels for all feature JDK GA releases >>>> since JDK 7 to the JDK feature-release main-line repository. >>>> >>>> To accommodate the new tag format, some simple jcheck edits >>>> would be required. Test checks would also be added. >>>> >>>> Comments? >>>> >>>> regards, >>>> Sean. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8180946 >>>> From kevin.rushforth at oracle.com Thu Oct 4 11:52:01 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 4 Oct 2018 04:52:01 -0700 Subject: Tagging proposal for JDK GA releases In-Reply-To: References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> <47E8CE40-59F0-4CC0-8A0A-0A87ABDFCBB7@amazon.com> <78737632-4990-434B-96F8-FB86D00B2037@oracle.com> <0a18f1ae2a20475ea782db906c24e2ae@sap.com> Message-ID: <45ea5445-9da1-7f13-93e6-f01b0a9c042c@oracle.com> I sent this before I read the good suggestion to not hijack this thread with a discussion of tagging builds, so I'll stop after this reply. I should note that the suggestion to make the tagging changeset the parent of the changeset being tagged (with the attendant merge changeset) would be a departure from current practice, so could be considered in the future, but would need to be discussed further and done carefully. -- Kevin On 10/4/2018 4:45 AM, Kevin Rushforth wrote: > >> I didn't mean that the tag is on a Merge changeset, >> I didn't know that rule. > > There is no such rule (and if there is, it would be wrong). > >> What I mean is, in other words than in my mail below: >> I would like that the parent of the tag change is the >> change to be tagged. > > This seems like a good idea, even if it does generate an extra merge > changeset. > > -- Kevin > > > On 10/4/2018 2:09 AM, Lindenmaier, Goetz wrote: >> Hi Jesper, >> >> I didn't mean that the tag is on a Merge changeset, >> I didn't know that rule. >> >> What I mean is, in other words than in my mail below: >> I would like that the parent of the tag change is the >> change to be tagged. >> I know this means that there will be a merge, but >> it seems worth while. >> >> Best regards, >> ?? Goetz. >> >>> -----Original Message----- >>> From: jesper.wilhelmsson at oracle.com >>> Sent: Donnerstag, 4. Oktober 2018 10:48 >>> To: Lindenmaier, Goetz >>> Cc: Hohensee, Paul ; Se?n Coffey >>> ; jdk-dev ; jdk- >>> updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net >>> Subject: Re: Tagging proposal for JDK GA releases >>> >>> The proposal looks good to me. >>> >>>> On 4 Oct 2018, at 10:19, Lindenmaier, Goetz >>>> >>> wrote: >>>> Hi, >>>> >>>> I also think this would make things more clear. >>>> >>>> I want to propose another point I stumbled about lately. >>>> >>> Sorry, my mistake. We are not supposed to tag merge changesets. >>> I have re-tagged jdk-12+14 to a non-merge change. >>> >>> I would like to take the opportunity to highlight that the hg >>> history would be >>> a lot easier to work with if everyone remembers to rebase their changes >>> before pushing. Then we would have a lot fewer merges in there. >>> /Jesper >>> >>>> You all know that if I do hg clone -r jdk-10.0.2-ga >>>> I get all the changes, but not the change that tags the version. >>>> I often check for the hash of the change tagging the release >>>> and clone that. Then I have a repo whose last change is the ga tag. >>>> >>>> Unfortunately recently, the tag comes later and is not directly >>>> applied to the change it wants to tag, but a few changes later. E.g., >>>> tag 12+14 is applied on top of "8202359: [GRAAL] >>> compiler/uncommontrap/TestDeoptOOM.java failed with >>> OutOfMemoryError" >>>> while it tags "Merge 8897e41b327c": >>>> http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1 >>>> >>>> * Added tag jdk-12+14 for changeset 8897e41b327c >>>> | >>>> * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java failed >>> with OutOfMemoryError >>>> | >>>> * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute >>>> paths >>> when directory is relative >>>> | >>>> * 8211150: G1 Full GC not purging code root memory and hence causing >>> memory leak >>>> | >>>> * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with >>> expected value: false >>>> | >>>> * 8211392: >>> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java >>> times >>> out in JDK12 CI >>>> | >>>> * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >>>> | >>>> * 8211375: Minimal VM build failures after JDK-8211251 (Default mask >>> register for avx512 instructions)= >>>> | >>>> * Merge? 8897e41b327c? jdk-12+14 >>>> >>>> The following would be more convenient: >>>> >>>> *Merge >>>> | \ >>>> |? * Added tag jdk-12+14 for changeset 8897e41b327c >>>> |? | >>>> *? |? 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java >>> failed with OutOfMemoryError >>>> |? | >>>> *? |? 8211385: (zipfs) ZipDirectoryStream yields a stream of >>>> absolute paths >>> when directory is relative >>>> |? | >>>> *? | 8211150: G1 Full GC not purging code root memory and hence >>>> causing >>> memory leak >>>> |? | >>>> *? |? 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar >>>> with >>> expected value: false >>>> |? | >>>> *? |? 8211392: >>> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java >>> times >>> out in JDK12 CI >>>> |? | >>>> *? |? 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF >>>> |? | >>>> *? | 8211375: Minimal VM build failures after JDK-8211251 (Default >>>> mask >>> register for avx512 instructions)= >>>> | / >>>> * Merge? 8897e41b327c? jdk-12+14 >>>> >>>> Which easily can be achieved by doing hg update -r 8897e41b327c (the >>> merge change) >>>> before doing hg tag -f. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> >>>>> -----Original Message----- >>>>> From: jdk-updates-dev >>> On >>>>> Behalf Of Hohensee, Paul >>>>> Sent: Mittwoch, 3. Oktober 2018 17:25 >>>>> To: Se?n Coffey ; jdk-dev >>>> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u- >>>>> dev at openjdk.java.net >>>>> Subject: Re: Tagging proposal for JDK GA releases >>>>> >>>>> We at Amazon would find this useful. >>>>> >>>>> Thanks, >>>>> >>>>> Paul >>>>> >>>>> ?On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Se?n Coffey" >>>>> >>>> updates-dev-bounces at openjdk.java.net on behalf of >>>>> sean.coffey at oracle.com> wrote: >>>>> >>>>> ??? I'd like to propose an enhancement to the JDK build-tagging >>>>> ??? convention to help users more easily identify JDK GA releases >>>>> ??? via Mercurial tag names. >>>>> >>>>> ??? The concept is quite simple and lets people identify snapshots >>>>> ??? of GA releases in Mercurial history without having to know the >>>>> ??? build number of the GA release. >>>>> >>>>> ??? For example, to obtain JDK 10.0.2 GA sources today, one issues >>>>> the >>>>> ??? `hg update -r jdk-10.0.2+13` command. With the proposed >>>>> ??? enhancement, `hg update -r jdk-10.0.2-ga` could have been used. >>>>> ??? It's proposed that the new ga tag would be in addition to the >>>>> regular >>>>> ??? GA build number tag. It would be added to the relevant repository >>>>> ??? once the GA milestone has been reached. >>>>> >>>>> ??? This new convention would be used for future JDK releases and is >>>>> ??? tracked via JDK-8180946[1]. If the changes are adopted, I can >>>>> ??? look at retroactively adding labels for all feature JDK GA >>>>> releases >>>>> ??? since JDK 7 to the JDK feature-release main-line repository. >>>>> >>>>> ??? To accommodate the new tag format, some simple jcheck edits >>>>> ??? would be required. Test checks would also be added. >>>>> >>>>> ??? Comments? >>>>> >>>>> ??? regards, >>>>> ??? Sean. >>>>> >>>>> ??? [1] https://bugs.openjdk.java.net/browse/JDK-8180946 >>>>> > From mark.reinhold at oracle.com Thu Oct 4 22:55:36 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 04 Oct 2018 15:55:36 -0700 Subject: JEP proposed to target JDK 12: 340: One AArch64 Port, Not Two In-Reply-To: <20180927223741.D01B720B000@eggemoggin.niobe.net> References: <20180927223741.D01B720B000@eggemoggin.niobe.net> Message-ID: <20181004155536.742466576@eggemoggin.niobe.net> 2018/9/27 15:37:41 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 12: > > 340: One AArch64 Port, Not Two > http://openjdk.java.net/jeps/340 > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:00 UTC on Thursday, 4 October, or if they?re raised > and then satisfactorily answered, then per the JEP 2.0 process proposal > [2] I?ll target this JEP to JDK 12. Hearing no objections, I?ve targeted this JEP to JDK 12. - Mark From mark.reinhold at oracle.com Thu Oct 4 22:55:41 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 04 Oct 2018 15:55:41 -0700 Subject: JEP proposed to target JDK 12: 341: Default CDS Archives In-Reply-To: <20180927223743.13E8820B002@eggemoggin.niobe.net> References: <20180927223743.13E8820B002@eggemoggin.niobe.net> Message-ID: <20181004155541.562537206@eggemoggin.niobe.net> 2018/9/27 15:37:43 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 12: > > 341: Default CDS Archives > http://openjdk.java.net/jeps/341 > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 23:00 UTC on Thursday, 4 October, or if they?re raised > and then satisfactorily answered, then per the JEP 2.0 process proposal > [2] I?ll target this JEP to JDK 12. Hearing no objections, I?ve targeted this JEP to JDK 12. - Mark From mark.reinhold at oracle.com Thu Oct 4 23:31:15 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 04 Oct 2018 16:31:15 -0700 Subject: Proposed schedule for JDK 12 In-Reply-To: <20180927161653.618998912@eggemoggin.niobe.net> References: <20180913224102.673F82097A3@eggemoggin.niobe.net> <5B9AEC3F.3080701@oracle.com> <20180927161653.618998912@eggemoggin.niobe.net> Message-ID: <20181004163115.729168824@eggemoggin.niobe.net> 2018/9/27 16:16:53 -0700, mark.reinhold at oracle.com: > ... > > I did notice a mistake in the schedule, though: RDP 2 was three weeks > long in JDK 10 and JDK 11, but it?s only two weeks long in JDK 12, and > the RC phase was five weeks (and five days) long in JDK 10 and JDK 11 > but it?s six weeks (and five days) long in JDK 12. > > This is easy to fix -- we just move the start of the RC phase out by one > week: > > 2018/12/13 Rampdown Phase One > 2019/01/17 Rampdown Phase Two > 2019/02/07 Release-Candidate Phase (changed; was 1/31) > 2019/03/19 General Availability > > I?ll hold this thread open until 23:30 UTC next Thursday in case there > are further comments or objections. Hearing no further comments or objections, this is now the schedule for JDK 12. - Mark From jiangli.zhou at oracle.com Fri Oct 5 16:57:05 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 5 Oct 2018 09:57:05 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: <0f79551e-5f0a-b7f4-cc72-eb84ed8baa14@oracle.com> References: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> <0f79551e-5f0a-b7f4-cc72-eb84ed8baa14@oracle.com> Message-ID: <37b2f736-88dc-f523-1551-0a87c3fb1a4b@oracle.com> Dear all, JEP 341, Default CDS Archive has been targeted to JDK 12 (please see Mark's email from yesterday, Re: JEP proposed to target JDK 12: 341: Default CDS Archives). Code review, testing and performance runs are completed for the default CDS archive changes. I've started the final pre-integration test yesterday with all tier1 - tier8. So far most of the tiers have been completed. Just a heads up, I'm planning to integrate the change in the next few hour. Thanks everyone for contributing to this effort!!! Jiangli On 9/6/18 12:45 PM, Jiangli Zhou wrote: > Hi, > > The JEP (http://openjdk.java.net/jeps/341) for the default CDS > archives is now a candidate. Please see Mark's email, 'New candidate > JEP: 341: Default CDS Archives'. Please help test Erik's makefile > patch for your platform if it is not built/tested in openjdk mainline > to prevent any possible breakage on your side. Any comments/feedbacks > on the default CDS archive are highly appreciated! > > ? http://cr.openjdk.java.net/~jiangli/8202951/webrev.02/ > > The above webrev is sync'ed with the lasted jdk/jdk repository today. > > Thanks! > > Jiangli > > On 8/30/18 11:26 AM, Jiangli Zhou wrote: >> Hi Magnus, >> >> Sounds good. Will update the message. >> >> Thanks! >> >> Jiangli >> >> >> On 8/30/18 3:56 AM, Magnus Ihse Bursie wrote: >>> On 2018-08-29 17:45, Erik Joelsson wrote: >>>> >>>> Hello Magnus, >>>> >>>> As the author of the build changes I will answer this. >>>> >>>> On 2018-08-29 04:53, Magnus Ihse Bursie wrote: >>>>> On 2018-08-28 18:25, Erik Joelsson wrote: >>>>>> Build changes look good to me (but should probably get review >>>>>> from someone else). >>>>> >>>>> I'm (as usually) not as happy as Erik. ;-) >>>>> >>>>> In Images.gmk, you have added this rule: >>>>> ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) >>>>> >>>>> It took me a while to grasp. You are relying on >>>>> $(JIMAGE_TARGET_FILE) to evaluate to bin/java. But that is only >>>>> incidentally so. This file is just picked arbitrarily to represent >>>>> when the entire image is done, for make. Please use >>>>> $(JRE_IMAGE_DIR)/bin/java instead. >>>>> >>>> I can agree with this part. That was a bit of a hack done in a hurry. >>>>> The logic in jdk-options.m4 is broken. If indeed it is not >>>>> possible to use cds archive with zero, then things will break >>>>> since it will still be built if using --enable-cds-archive! >>>>> >>>>> What you should do is to set default to true unless using cross >>>>> compilation or zero. If the user explicitly sets >>>>> --enable-cds-archive, and it's not possible, a fatal error should >>>>> be generated. >>>>> >>>> Here I'm not as sure. I deliberately let it be possible to override >>>> the default behavior for zero as someone might want to fix that at >>>> some point, you never know. For cross compilation it's just not >>>> possible ever so that's different. Maybe my reasoning is invalid. >>> >>> I see. I still think it would have made more sense, in that case, to >>> set the default to false if using zero, but allow override. But I'm >>> not going to insist on that. >>> >>> However, if the problem with zero is not that it's technically >>> impossible, just that it's not tested, I think the message should be >>> changed from "[no, not possible with JVM variant zero]" to just >>> "[no]" with a comment in the configure script that it's off by >>> default since it's not tested. >>> >>> Apart from that, Jiangli's latest webrev looks good. >>> >>> Jiangli: If you fix it like I suggested, you do not need to respin >>> the webrev. >>> >>> /Magnus >>> >>>> >>>> /Erik >>>>> Apart from this, I'm more on Erik's line. :-) >>>>> >>>>> /Magnus >>>>> >>>>> >>>>> >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>>>>> Please review the implementation for JEP JDK-8204247 >>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of >>>>>>> the JEP is to include a default CDS archive in JDK 12 binary >>>>>>> distribution (downloadable from http://jdk.java.net/12/). The >>>>>>> default CDS archive is generated using the default classlist >>>>>>> (resides in the lib/ directory) at JDK build time. Any >>>>>>> comments/suggestions are highly appreciated. >>>>>>> >>>>>>> All makefile changes in the webrev are contributed by Erik >>>>>>> Joelsson (many thanks!!). >>>>>>> >>>>>>> This is a combination of efforts from different teams and >>>>>>> individuals. Thanks to everyone who has been involved in the JEP >>>>>>> & implementation discussions, testing and bug fixing! >>>>>>> >>>>>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>>>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>>>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>>>>> >>>>>>> Two sanity test cases for the default CDS archive are included >>>>>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not >>>>>>> intended for in-depth CDS functional testing, which is already >>>>>>> covered by the existing cds/appcds tests and all tiered tests >>>>>>> executing with the default CDS archive enabled. >>>>>>> >>>>>>> As part of the webrev, >>>>>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also >>>>>>> fixed to use larger java heap (JDK-8209739 >>>>>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>>>>> >>>>>>> Tests executed: >>>>>>> ?- several rounds of tier1 - tier8 via mach5 >>>>>>> ?- JCK lang, api and vm tests via mach5 >>>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> Calvin, Ioi, Jiangli >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From bsrbnd at gmail.com Sat Oct 6 22:05:58 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 7 Oct 2018 00:05:58 +0200 Subject: Primitive boolean array packing Message-ID: Hi, Per JVMS, primitive boolean arrays are currently using 8 bits (one byte) per boolean value, see [1] (baload/bastore). We've see in some threads [2] that 'BitSet' or 'EnumSet' are occasionally preferred solutions as they are using boolean vectors (aka long values) using 8x less memory. But as the spec [1] allows primitive boolean array packing, I made a quick experiment which is available here: http://cr.openjdk.java.net/~bsrbnd/boolpack/webrev.00/ This is a partial draft implementing primitive boolean array packing (8x smaller) at machine-level (vs BitSet at class-level): * only x86 interpreter implemented => c1/c2/inlining disabled for methods using baload/bastore (not much performance regression when building the jdk and running the tests) * unsafe access partially implemented * array copy currently not implemented * -XX:+/-BooleanPacking to enable/disable the feature currently not implemented A couple of residual tier1 tests are still failing due to the unfinished implementation. I didn't search much if such experiments have already been accomplished, but I'd like to take the temperature of this feature as completing the implementation represents a significant amount of work. Is this something that is worth exploring? Thanks in advance for any feedback. Regards, Bernard [1] https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-6.html#jvms-6.5.baload [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012504.html From shade at redhat.com Sun Oct 7 08:01:47 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 7 Oct 2018 10:01:47 +0200 Subject: Primitive boolean array packing In-Reply-To: References: Message-ID: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> On 10/07/2018 12:05 AM, B. Blaser wrote: > I didn't search much if such experiments have already been > accomplished, but I'd like to take the temperature of this feature as > completing the implementation represents a significant amount of work. > Is this something that is worth exploring? The most problematic part, in my mind, is that JMM requires the absence of word tearing for array element accesses. See here: https://shipilev.net/blog/2014/jmm-pragmatics/#_part_ii_word_tearing With densely packed boolean[], you'd need to convert plain stores to locked/CAS-loops to support this, I think, which raises all sorts of performance questions. Choosing between boolean[] and BitSet is basically choosing between stricter/relaxed concurrency guarantees vs dense/sparse footprint. -Aleksey From aph at redhat.com Sun Oct 7 11:47:45 2018 From: aph at redhat.com (Andrew Haley) Date: Sun, 7 Oct 2018 12:47:45 +0100 Subject: Primitive boolean array packing In-Reply-To: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> Message-ID: <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> On 10/07/2018 09:01 AM, Aleksey Shipilev wrote: > On 10/07/2018 12:05 AM, B. Blaser wrote: >> I didn't search much if such experiments have already been >> accomplished, but I'd like to take the temperature of this feature as >> completing the implementation represents a significant amount of work. >> Is this something that is worth exploring? > > The most problematic part, in my mind, is that JMM requires the absence of word tearing for array > element accesses. See here: https://shipilev.net/blog/2014/jmm-pragmatics/#_part_ii_word_tearing > > With densely packed boolean[], you'd need to convert plain stores to locked/CAS-loops to support > this, I think, which raises all sorts of performance questions. Choosing between boolean[] and > BitSet is basically choosing between stricter/relaxed concurrency guarantees vs dense/sparse footprint. But you get a lot of performance conflicts between cores having to share cache lines anyway. Maybe we should do some performance experiments: we wouldn't need to do all of the C2 work, just write a little C++ and asm code and measure what happens under some plausible conditions. We'd have to try both contended and uncontended situations. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Sun Oct 7 11:51:38 2018 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 7 Oct 2018 13:51:38 +0200 Subject: Primitive boolean array packing In-Reply-To: <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> Message-ID: >>> I didn't search much if such experiments have already been >>> accomplished, but I'd like to take the temperature of this feature as >>> completing the implementation represents a significant amount of work. >>> Is this something that is worth exploring? >> >> The most problematic part, in my mind, is that JMM requires the absence of word tearing for array >> element accesses. See here: https://shipilev.net/blog/2014/jmm-pragmatics/#_part_ii_word_tearing >> >> With densely packed boolean[], you'd need to convert plain stores to locked/CAS-loops to support >> this, I think, which raises all sorts of performance questions. Choosing between boolean[] and >> BitSet is basically choosing between stricter/relaxed concurrency guarantees vs dense/sparse footprint. > > But you get a lot of performance conflicts between cores having to share > cache lines anyway. Maybe we should do some performance experiments: we > wouldn't need to do all of the C2 work, just write a little C++ and asm > code and measure what happens under some plausible conditions. We'd have > to try both contended and uncontended situations. Are boolean arrays even common enough to make a difference? Roman From bsrbnd at gmail.com Sun Oct 7 12:38:21 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 7 Oct 2018 14:38:21 +0200 Subject: Primitive boolean array packing In-Reply-To: References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> Message-ID: On Sun, 7 Oct 2018 at 13:51, Roman Kennke wrote: > > >>> I didn't search much if such experiments have already been > >>> accomplished, but I'd like to take the temperature of this feature as > >>> completing the implementation represents a significant amount of work. > >>> Is this something that is worth exploring? > >> > >> The most problematic part, in my mind, is that JMM requires the absence of word tearing for array > >> element accesses. See here: https://shipilev.net/blog/2014/jmm-pragmatics/#_part_ii_word_tearing > >> > >> With densely packed boolean[], you'd need to convert plain stores to locked/CAS-loops to support > >> this, I think, which raises all sorts of performance questions. Choosing between boolean[] and > >> BitSet is basically choosing between stricter/relaxed concurrency guarantees vs dense/sparse footprint. > > > > But you get a lot of performance conflicts between cores having to share > > cache lines anyway. Maybe we should do some performance experiments: we > > wouldn't need to do all of the C2 work, just write a little C++ and asm > > code and measure what happens under some plausible conditions. We'd have > > to try both contended and uncontended situations. > > Are boolean arrays even common enough to make a difference? > > Roman Thanks Aleksey, you're absolutely right but a programmer can still disable this feature and use regular boolean arrays if necessary. Nevertheless, if the memory consumption is a priority and boolean packing a necessity, the problem you mentioned has two solutions: 1) either the JVM could lock distinct boolean elements per 8-bit block to preserve synchronized data, in which case some profiling would be necessary as Andrew suggested 2) or the JVM could no more guarantee concurrent access on distinct boolean array elements if packing is enabled delegating the synchronization to the programmer. While the first solution is safer, the second one minimizes the additional performance cost with a better synchronization focusing which maybe addresses Roman's question... Bernard From shade at redhat.com Sun Oct 7 15:13:11 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 7 Oct 2018 17:13:11 +0200 Subject: Primitive boolean array packing In-Reply-To: References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> Message-ID: On 10/07/2018 02:38 PM, B. Blaser wrote: > Thanks Aleksey, you're absolutely right but a programmer can still > disable this feature and use regular boolean arrays if necessary. I fully expect the JVM feature/flag what optionally breaks the Java specification will be flat out rejected. You can have the optional feature that makes the behavior tighter than required by spec, but it is a hard stop to make the behaviors weaker than required by spec. So, the work on packed boolean arrays has to demonstrate good performance with along with work tearing guarantees. On 10/07/2018 01:47 PM, Andrew Haley wrote: > But you get a lot of performance conflicts between cores having to share > cache lines anyway. Maybe we should do some performance experiments: we > wouldn't need to do all of the C2 work, just write a little C++ and asm > code and measure what happens under some plausible conditions. We'd have > to try both contended and uncontended situations. My educated guess from the subword atomic operations over VarHandles: the local latency of uncontended CAS would still be too significant to ignore. Over years, we hoped CAS overhead would become negligible, but it still isn't (see Biased Locking as another example that depends on this). -Aleksey From aph at redhat.com Sun Oct 7 17:51:20 2018 From: aph at redhat.com (Andrew Haley) Date: Sun, 7 Oct 2018 18:51:20 +0100 Subject: Primitive boolean array packing In-Reply-To: References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> Message-ID: On 10/07/2018 04:13 PM, Aleksey Shipilev wrote: > On 10/07/2018 02:38 PM, B. Blaser wrote: >> Thanks Aleksey, you're absolutely right but a programmer can still >> disable this feature and use regular boolean arrays if necessary. > > I fully expect the JVM feature/flag what optionally breaks the Java > specification will be flat out rejected. It doesn't break the Java specification: Notes The baload instruction is used to load values from both byte and boolean arrays. In Oracle's Java Virtual Machine implementation, boolean arrays - that is, arrays of type T_BOOLEAN (?2.2, ?newarray) - are implemented as arrays of 8-bit values. Other implementations may implement packed boolean arrays; the baload instruction of such implementations must be used to access those arrays. > My educated guess from the subword atomic operations over > VarHandles: the local latency of uncontended CAS would still be too > significant to ignore. Over years, we hoped CAS overhead would > become negligible, but it still isn't Probably so. Numbers would be nice. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Sun Oct 7 18:29:33 2018 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 7 Oct 2018 20:29:33 +0200 Subject: Primitive boolean array packing In-Reply-To: References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> Message-ID: IIRC, some CPUs even have instructions for directly getting/setting bits, without explicit mask/shift. AArch64 can do that I think. Not sure if it's more efficient though. Roman > On 10/07/2018 04:13 PM, Aleksey Shipilev wrote: >> On 10/07/2018 02:38 PM, B. Blaser wrote: >>> Thanks Aleksey, you're absolutely right but a programmer can still >>> disable this feature and use regular boolean arrays if necessary. >> >> I fully expect the JVM feature/flag what optionally breaks the Java >> specification will be flat out rejected. > > It doesn't break the Java specification: > > Notes > > The baload instruction is used to load values from both byte and > boolean arrays. In Oracle's Java Virtual Machine implementation, > boolean arrays - that is, arrays of type T_BOOLEAN (?2.2, > ?newarray) - are implemented as arrays of 8-bit values. Other > implementations may implement packed boolean arrays; the baload > instruction of such implementations must be used to access those > arrays. > >> My educated guess from the subword atomic operations over >> VarHandles: the local latency of uncontended CAS would still be too >> significant to ignore. Over years, we hoped CAS overhead would >> become negligible, but it still isn't > > Probably so. Numbers would be nice. > From shade at redhat.com Sun Oct 7 19:54:00 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 7 Oct 2018 21:54:00 +0200 Subject: Primitive boolean array packing In-Reply-To: References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> Message-ID: <62d7984a-78dc-82a4-15aa-6deeebf95342@redhat.com> On 10/07/2018 07:51 PM, Andrew Haley wrote: > On 10/07/2018 04:13 PM, Aleksey Shipilev wrote: >> On 10/07/2018 02:38 PM, B. Blaser wrote: >>> Thanks Aleksey, you're absolutely right but a programmer can still >>> disable this feature and use regular boolean arrays if necessary. >> >> I fully expect the JVM feature/flag what optionally breaks the Java >> specification will be flat out rejected. > > It doesn't break the Java specification: > > Notes > > The baload instruction is used to load values from both byte and > boolean arrays. In Oracle's Java Virtual Machine implementation, > boolean arrays - that is, arrays of type T_BOOLEAN (?2.2, > ?newarray) - are implemented as arrays of 8-bit values. Other > implementations may implement packed boolean arrays; the baload > instruction of such implementations must be used to access those > arrays. You need to specify what do you mean by "it". Current prototype sure does break the provisions of JLS 17.6 "Word Tearing": https://docs.oracle.com/javase/specs/jls/se11/html/jls-17.html#jls-17.6 My comment was about generic thing: we cannot break the Java spec even if we have the JVM flag that makes it right again. I thought that what B. was suggesting as the escape hatch. Of course, if you do packed boolean[] with locked/CAS-ed writes or otherwise guarantee the absence of word tearing, it does not break the spec. -Aleksey From bsrbnd at gmail.com Mon Oct 8 08:30:19 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 8 Oct 2018 10:30:19 +0200 Subject: Primitive boolean array packing In-Reply-To: <62d7984a-78dc-82a4-15aa-6deeebf95342@redhat.com> References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> <62d7984a-78dc-82a4-15aa-6deeebf95342@redhat.com> Message-ID: On Sun, 7 Oct 2018 at 21:54, Aleksey Shipilev wrote: > > On 10/07/2018 07:51 PM, Andrew Haley wrote: > > On 10/07/2018 04:13 PM, Aleksey Shipilev wrote: > >> On 10/07/2018 02:38 PM, B. Blaser wrote: > >>> Thanks Aleksey, you're absolutely right but a programmer can still > >>> disable this feature and use regular boolean arrays if necessary. > >> > >> I fully expect the JVM feature/flag what optionally breaks the Java > >> specification will be flat out rejected. > > > > It doesn't break the Java specification: > > > > Notes > > > > The baload instruction is used to load values from both byte and > > boolean arrays. In Oracle's Java Virtual Machine implementation, > > boolean arrays - that is, arrays of type T_BOOLEAN (?2.2, > > ?newarray) - are implemented as arrays of 8-bit values. Other > > implementations may implement packed boolean arrays; the baload > > instruction of such implementations must be used to access those > > arrays. > > You need to specify what do you mean by "it". Current prototype sure does break the provisions of > JLS 17.6 "Word Tearing": > https://docs.oracle.com/javase/specs/jls/se11/html/jls-17.html#jls-17.6 > > My comment was about generic thing: we cannot break the Java spec even if we have the JVM flag that > makes it right again. I thought that what B. was suggesting as the escape hatch. Of course, if you > do packed boolean[] with locked/CAS-ed writes or otherwise guarantee the absence of word tearing, it > does not break the spec. > > -Aleksey You're undoubtedly right, I was focusing on the JVMS and I missed that point in the JLS... I'll try to put the prototype in sync with *all* the specs. Thanks, Bernard From bsrbnd at gmail.com Mon Oct 8 08:40:19 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 8 Oct 2018 10:40:19 +0200 Subject: Primitive boolean array packing In-Reply-To: References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> Message-ID: On Sun, 7 Oct 2018 at 20:29, Roman Kennke wrote: > > IIRC, some CPUs even have instructions for directly getting/setting > bits, without explicit mask/shift. AArch64 can do that I think. Not sure > if it's more efficient though. > > Roman Sounds great, probably no word-tearing problem and no additional sync would be necessary on this arch. Unfortunately, I don't have the opportunity to work on this hardware, maybe someone could experiment on it? Bernard From aph at redhat.com Mon Oct 8 08:53:17 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 8 Oct 2018 09:53:17 +0100 Subject: Primitive boolean array packing In-Reply-To: <62d7984a-78dc-82a4-15aa-6deeebf95342@redhat.com> References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> <62d7984a-78dc-82a4-15aa-6deeebf95342@redhat.com> Message-ID: On 10/07/2018 08:54 PM, Aleksey Shipilev wrote: > You need to specify what do you mean by "it". Current prototype sure > does break the provisions of JLS 17.6 "Word Tearing": > https://docs.oracle.com/javase/specs/jls/se11/html/jls-17.html#jls-17.6 Oh, sure, of course. > My comment was about generic thing: we cannot break the Java spec > even if we have the JVM flag that makes it right again. I thought > that what B. was suggesting as the escape hatch. And I thought it was a switch between bit arrays and byte arrays. > Of course, if you do packed boolean[] with locked/CAS-ed writes or > otherwise guarantee the absence of word tearing, it does not break > the spec. Exactly. it's an interesting idea for large bit vectors, and it could well generate good code. However, it probably makes more sense to implement it as a bit vector class with suitable helper intrinsics. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From bsrbnd at gmail.com Mon Oct 8 11:16:28 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 8 Oct 2018 13:16:28 +0200 Subject: Primitive boolean array packing In-Reply-To: References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> <62d7984a-78dc-82a4-15aa-6deeebf95342@redhat.com> Message-ID: On Mon, 8 Oct 2018 at 10:53, Andrew Haley wrote: > > On 10/07/2018 08:54 PM, Aleksey Shipilev wrote: > > > Of course, if you do packed boolean[] with locked/CAS-ed writes or > > otherwise guarantee the absence of word tearing, it does not break > > the spec. > > Exactly. it's an interesting idea for large bit vectors, and it could > well generate good code. However, it probably makes more sense to > implement it as a bit vector class with suitable helper intrinsics. The current prototype was intended to scrupulously implement what the JVMS explicitly allows for baload/bastore instructions. But helper intrinsics might be good alternatives too, we could try both. Note that the existing BitSet needs external sync (most probably on the whole set) when used in multi-threaded environments. With packed baload/bastore instructions or dedicated intrinsics, the sync would be on smaller 8-bit blocks or no sync at all on some arch as Roman mentioned (AArch64). Bernard From goetz.lindenmaier at sap.com Mon Oct 8 13:56:15 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 8 Oct 2018 13:56:15 +0000 Subject: RFR(S): 8211856: [ppc, s390] ProblemList some failing tests. Message-ID: <898769097d8d40a6bdcd98fed93096d6@sap.com> Hi, The ppc and s390 ports are now part of OpenJDK for 3-4 releases. A great effort was taken to get all jtreg tests working. This change adds the few remaining issues to the ProblemsLists of jdk and hotspot after opening bugs for them. http://cr.openjdk.java.net/~goetz/wr18/8211856-problemList/01/ As these tests all fail in jdk11, I would like to downport this to jdk11u later on. Best regards, Goetz. From Roger.Riggs at oracle.com Mon Oct 8 14:46:41 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 8 Oct 2018 10:46:41 -0400 Subject: CFV: New JDK Reviewer: Jini George In-Reply-To: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> References: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> Message-ID: <40fc886d-596b-abd9-9dd9-3d0e3d2ad987@oracle.com> Vote: yes On 09/27/2018 12:05 PM, jesper.wilhelmsson at oracle.com wrote: > I hearby nominate Jini George (jgeorge) to JDK Project Reviewer. From aph at redhat.com Mon Oct 8 15:19:26 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 8 Oct 2018 16:19:26 +0100 Subject: Primitive boolean array packing In-Reply-To: References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> <62d7984a-78dc-82a4-15aa-6deeebf95342@redhat.com> Message-ID: <882cb210-5870-2292-e78f-62857abdc54f@redhat.com> On 10/08/2018 12:16 PM, B. Blaser wrote: > The current prototype was intended to scrupulously implement what the > JVMS explicitly allows for baload/bastore instructions. > But helper intrinsics might be good alternatives too, we could try both. So I tried it with a rough C++/assembly language test, and it doesn't make much sense to use this for default boolean arrays. The update sequence on AArch64 is 0: ldxrb w2, [x0]; and w2, w2, w1 stxrb w3, w2, [x0] cbnz w3, 0b (combined with a bunch of uninteresting shifts and logical operations.) We have to load a byte in exclusive state, AND or OR it as appropriate, then store it, still in exclusive state. That gets us the atomicity we need. 10**9 random set operations on an 8 Mbit array take 0.550s; with a boolean array the time is 0.150s. This is the local overhead of the load/store exclusive. > Note that the existing BitSet needs external sync (most probably on > the whole set) when used in multi-threaded environments. > With packed baload/bastore instructions or dedicated intrinsics, the > sync would be on smaller 8-bit blocks or no sync at all on some arch > as Roman mentioned (AArch64). It might help. The question is how much we need large bit arrays. They're certainly useful for things like Bloom filters. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From maurizio.cimadamore at oracle.com Mon Oct 8 16:30:05 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 8 Oct 2018 17:30:05 +0100 Subject: Primitive boolean array packing In-Reply-To: References: Message-ID: Hi Bernard, what you describe here is also overlapping with Project Panama, which allows you to define a Java wrapper for a packed struct using layout descriptions. If you go down that path, you can, I believe, address the memory footprint issues w/o touching the VM (e.g. by changing the implementation of some of these classes to use Panama structs). Could be a worthwhile experiment to try and do that! Cheers Maurizio On 06/10/18 23:05, B. Blaser wrote: > Hi, > > Per JVMS, primitive boolean arrays are currently using 8 bits (one > byte) per boolean value, see [1] (baload/bastore). > > We've see in some threads [2] that 'BitSet' or 'EnumSet' are > occasionally preferred solutions as they are using boolean vectors > (aka long values) using 8x less memory. > > But as the spec [1] allows primitive boolean array packing, I made a > quick experiment which is available here: > > http://cr.openjdk.java.net/~bsrbnd/boolpack/webrev.00/ > > This is a partial draft implementing primitive boolean array packing > (8x smaller) at machine-level (vs BitSet at class-level): > * only x86 interpreter implemented => c1/c2/inlining disabled for > methods using baload/bastore (not much performance regression when > building the jdk and running the tests) > * unsafe access partially implemented > * array copy currently not implemented > * -XX:+/-BooleanPacking to enable/disable the feature currently not implemented > > A couple of residual tier1 tests are still failing due to the > unfinished implementation. > > I didn't search much if such experiments have already been > accomplished, but I'd like to take the temperature of this feature as > completing the implementation represents a significant amount of work. > Is this something that is worth exploring? > > Thanks in advance for any feedback. > > Regards, > Bernard > > > [1] https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-6.html#jvms-6.5.baload > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012504.html From vladimir.kozlov at oracle.com Mon Oct 8 17:10:49 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 8 Oct 2018 10:10:49 -0700 Subject: RFR(S): 8211856: [ppc, s390] ProblemList some failing tests. In-Reply-To: <898769097d8d40a6bdcd98fed93096d6@sap.com> References: <898769097d8d40a6bdcd98fed93096d6@sap.com> Message-ID: <0e8691ca-f811-e74f-8d23-95d365f62075@oracle.com> Looks good to me. Thanks, Vladimir On 10/8/18 6:56 AM, Lindenmaier, Goetz wrote: > Hi, > > The ppc and s390 ports are now part of OpenJDK for 3-4 releases. > A great effort was taken to get all jtreg tests working. > > This change adds the few remaining issues to the ProblemsLists > of jdk and hotspot after opening bugs for them. > http://cr.openjdk.java.net/~goetz/wr18/8211856-problemList/01/ > > As these tests all fail in jdk11, I would like to downport this to jdk11u > later on. > > Best regards, > Goetz. > From bsrbnd at gmail.com Mon Oct 8 17:18:08 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 8 Oct 2018 19:18:08 +0200 Subject: Primitive boolean array packing In-Reply-To: <882cb210-5870-2292-e78f-62857abdc54f@redhat.com> References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> <62d7984a-78dc-82a4-15aa-6deeebf95342@redhat.com> <882cb210-5870-2292-e78f-62857abdc54f@redhat.com> Message-ID: On Mon, 8 Oct 2018 at 17:19, Andrew Haley wrote: > > On 10/08/2018 12:16 PM, B. Blaser wrote: > > The current prototype was intended to scrupulously implement what the > > JVMS explicitly allows for baload/bastore instructions. > > But helper intrinsics might be good alternatives too, we could try both. > > So I tried it with a rough C++/assembly language test, and it doesn't > make much sense to use this for default boolean arrays. The update > sequence on AArch64 is > > 0: ldxrb w2, [x0]; > and w2, w2, w1 > stxrb w3, w2, [x0] > cbnz w3, 0b > > (combined with a bunch of uninteresting shifts and logical > operations.) We have to load a byte in exclusive state, AND or OR it > as appropriate, then store it, still in exclusive state. That gets us > the atomicity we need. > > 10**9 random set operations on an 8 Mbit array take 0.550s; with a > boolean array the time is 0.150s. This is the local overhead of the > load/store exclusive. Reducing memory consumption has a price which doesn't seem too expensive, fortunately. > > Note that the existing BitSet needs external sync (most probably on > > the whole set) when used in multi-threaded environments. > > With packed baload/bastore instructions or dedicated intrinsics, the > > sync would be on smaller 8-bit blocks or no sync at all on some arch > > as Roman mentioned (AArch64). > > It might help. The question is how much we need large bit > arrays. They're certainly useful for things like Bloom filters. As I initially mentioned, this would be useful for large bit arrays or for a large *number* of smaller bit arrays. We are planning to refactor javac flags [1] currently using one long value per symbol [2] which potentially means a huge number of bit arrays (or vectors) of more than 64 elements. Bernard [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012504.html [2] http://hg.openjdk.java.net/jdk/jdk/file/d8aebcc2d3ac/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java#l98 > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From bsrbnd at gmail.com Mon Oct 8 17:25:41 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 8 Oct 2018 19:25:41 +0200 Subject: Primitive boolean array packing In-Reply-To: References: Message-ID: On Mon, 8 Oct 2018 at 18:30, Maurizio Cimadamore wrote: > > Hi Bernard, > what you describe here is also overlapping with Project Panama, which > allows you to define a Java wrapper for a packed struct using layout > descriptions. If you go down that path, you can, I believe, address the > memory footprint issues w/o touching the VM (e.g. by changing the > implementation of some of these classes to use Panama structs). Could be > a worthwhile experiment to try and do that! > > Cheers > Maurizio Thanks Maurizio, I'll take a look ;-) Cheers, Bernard From per.liden at oracle.com Tue Oct 9 06:51:50 2018 From: per.liden at oracle.com (Per Liden) Date: Tue, 9 Oct 2018 08:51:50 +0200 Subject: CFV: New JDK Reviewer: Jini George In-Reply-To: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> References: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> Message-ID: <004d279c-91fb-e165-8952-46761c948b6a@oracle.com> Vote: yes /Per On 2018-09-27 18:05, jesper.wilhelmsson at oracle.com wrote: > I hearby nominate Jini George (jgeorge) to JDK Project Reviewer. > > Jini has made 37 contributions in the JDK [3], many in the Serviceability Agent which is an area that for a long time was lacking active contributors. Jini's work in the SA is highly appreciated. > > Votes are due by 18:00 CET October 11, 2018. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of contributions: > > (1) 8210836: Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/c0f9161f591e > > (2) 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode > http://hg.openjdk.java.net/jdk/jdk/rev/948c62200f8c > > (3) 8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC > http://hg.openjdk.java.net/jdk/jdk/rev/e46b9e514479 > > (4) 8195613: [SA] HotSpotTypeDataBase.readVMLongConstants truncates values to int > http://hg.openjdk.java.net/jdk/jdk/rev/300e4a88c400 > > (5) 8174995: SA: clhsdb 'where -a' throws Assertion Failure with illegal code 236 when CDS is used > http://hg.openjdk.java.net/jdk/jdk/rev/55153a374d18 > > (6) 8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS > http://hg.openjdk.java.net/jdk/jdk/rev/ec2dd30adbc1 > > (7) 8175312: SA: clhsdb: Provide an improved heap summary for 'universe' for G1GC > http://hg.openjdk.java.net/jdk/jdk/rev/ccb003941743 > > (8) 8175384: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes > http://hg.openjdk.java.net/jdk/jdk/rev/d2a860bc50a3 > > (9) 8193352: SA: Test for the clhsdb 'thread' and 'threads' commands > http://hg.openjdk.java.net/jdk/jdk/rev/fdef4da95080 > > (10) 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands > http://hg.openjdk.java.net/jdk/jdk/rev/be065f758154 > > (11) 8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol > http://hg.openjdk.java.net/jdk/jdk/rev/61a14b5cb1c6 > > (12) 8191914: New SA test timeout on windows > http://hg.openjdk.java.net/jdk/jdk/rev/88ec5fca7726 > > (13) 8191324: SA cleanup -- part 2 > http://hg.openjdk.java.net/jdk/jdk/rev/2659c4fe8ea7 > > (14) 8191961: SA: Remove left over quarantined SA tests due to 8184042 from ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/111834dd10dd > > (15) 8191919: Include TestJhsdbJstackLock.java in ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/d851eb254409 > > (16) 8190307: SA tests for the clhsdb commands: universe, intconstant, type > http://hg.openjdk.java.net/jdk/jdk/rev/75d365bfc2e6 > > (17) 8189798: SA cleanup - part 1 > http://hg.openjdk.java.net/jdk/jdk/rev/ac0af7750da9 > > (18) 8184042: several serviceability/sa tests timed out on MacOS X > http://hg.openjdk.java.net/jdk/jdk/rev/dfb375d231fb > > (19) 8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 > http://hg.openjdk.java.net/jdk/jdk/rev/deab1e2f0ebf > > (20) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/2eab88a780e3 > > (21) 8162504: TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS > http://hg.openjdk.java.net/jdk/jdk/rev/4597fa06b227 > > (22) 8175054: Move new TestPrintMdo.java to hotspot/test directory > http://hg.openjdk.java.net/jdk/jdk/rev/d9ba85f5cb9d > > (23) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/c809fcb66c81 > > (24) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk/jdk/rev/a152f2d3320e > > (25) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk/jdk/rev/0b0ae99d8639 > http://hg.openjdk.java.net/jdk/jdk/rev/297ba2772122 > > (26) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk/jdk/rev/48d874bf85fb > > (27) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk/jdk/rev/a20695c30be5 > > (28) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/154099b110df > > (29) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk/jdk/rev/815cfbe4878b > > (30) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk/jdk/rev/afd6ae4fec81 > > (31) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk/jdk/rev/10e6e31dc1aa > > (32) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/815650daefb4 > > (33) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/aed0f6434aea > > (34) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk/jdk/rev/c0e02245ff93 > http://hg.openjdk.java.net/jdk/jdk/rev/12787d18650e > > (35) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk/jdk/rev/adf083cbc37f > > (36) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk/jdk/rev/8a2083c5e2b1 > http://hg.openjdk.java.net/jdk/jdk/rev/d46cac7959c4 > > (37) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk/jdk/rev/82ece130a37b > From david.holmes at oracle.com Tue Oct 9 10:14:41 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Oct 2018 20:14:41 +1000 Subject: CFV: New JDK Reviewer: Jini George In-Reply-To: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> References: <3C834F7A-6B22-41F5-B78A-B673FE917F71@oracle.com> Message-ID: <8b974c6b-5501-df83-17f2-372125f2fca9@oracle.com> Vote: yes David On 28/09/2018 2:05 AM, jesper.wilhelmsson at oracle.com wrote: > I hearby nominate Jini George (jgeorge) to JDK Project Reviewer. > > Jini has made 37 contributions in the JDK [3], many in the Serviceability Agent which is an area that for a long time was lacking active contributors. Jini's work in the SA is highly appreciated. > > Votes are due by 18:00 CET October 11, 2018. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of contributions: > > (1) 8210836: Build fails with warn_unused_result in openjdk/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/c0f9161f591e > > (2) 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode > http://hg.openjdk.java.net/jdk/jdk/rev/948c62200f8c > > (3) 8189429: SA: MacOSX: Replace the deprecated PT_ATTACH with PT_ATTACHEXC > http://hg.openjdk.java.net/jdk/jdk/rev/e46b9e514479 > > (4) 8195613: [SA] HotSpotTypeDataBase.readVMLongConstants truncates values to int > http://hg.openjdk.java.net/jdk/jdk/rev/300e4a88c400 > > (5) 8174995: SA: clhsdb 'where -a' throws Assertion Failure with illegal code 236 when CDS is used > http://hg.openjdk.java.net/jdk/jdk/rev/55153a374d18 > > (6) 8174994: SA: clhsdb printmdo throws WrongTypeException when attached to a process with CDS > http://hg.openjdk.java.net/jdk/jdk/rev/ec2dd30adbc1 > > (7) 8175312: SA: clhsdb: Provide an improved heap summary for 'universe' for G1GC > http://hg.openjdk.java.net/jdk/jdk/rev/ccb003941743 > > (8) 8175384: SA: clhsdb 'printall' throws ClassCastException while printing out the bytecodes > http://hg.openjdk.java.net/jdk/jdk/rev/d2a860bc50a3 > > (9) 8193352: SA: Test for the clhsdb 'thread' and 'threads' commands > http://hg.openjdk.java.net/jdk/jdk/rev/fdef4da95080 > > (10) 8192985: SA: Test cases for the clhsdb 'inspect', 'scanoops' and 'printas' commands > http://hg.openjdk.java.net/jdk/jdk/rev/be065f758154 > > (11) 8191538: SA: tests for clhsdb commands: vmstructsdump, field, symboltable and symbol > http://hg.openjdk.java.net/jdk/jdk/rev/61a14b5cb1c6 > > (12) 8191914: New SA test timeout on windows > http://hg.openjdk.java.net/jdk/jdk/rev/88ec5fca7726 > > (13) 8191324: SA cleanup -- part 2 > http://hg.openjdk.java.net/jdk/jdk/rev/2659c4fe8ea7 > > (14) 8191961: SA: Remove left over quarantined SA tests due to 8184042 from ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/111834dd10dd > > (15) 8191919: Include TestJhsdbJstackLock.java in ProblemList.txt > http://hg.openjdk.java.net/jdk/jdk/rev/d851eb254409 > > (16) 8190307: SA tests for the clhsdb commands: universe, intconstant, type > http://hg.openjdk.java.net/jdk/jdk/rev/75d365bfc2e6 > > (17) 8189798: SA cleanup - part 1 > http://hg.openjdk.java.net/jdk/jdk/rev/ac0af7750da9 > > (18) 8184042: several serviceability/sa tests timed out on MacOS X > http://hg.openjdk.java.net/jdk/jdk/rev/dfb375d231fb > > (19) 8175512: new TestPrintMdo.java fails with -XX:TieredStopAtLevel=1 > http://hg.openjdk.java.net/jdk/jdk/rev/deab1e2f0ebf > > (20) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/2eab88a780e3 > > (21) 8162504: TestInstanceKlassSize.java and TestInstanceKlassSizeForInterface.java fail on Mac OS > http://hg.openjdk.java.net/jdk/jdk/rev/4597fa06b227 > > (22) 8175054: Move new TestPrintMdo.java to hotspot/test directory > http://hg.openjdk.java.net/jdk/jdk/rev/d9ba85f5cb9d > > (23) 8173896: SA: BasicLauncherTest.java (printmdo) fails for Client VM and Server VM with emulated-client > http://hg.openjdk.java.net/jdk/jdk/rev/c809fcb66c81 > > (24) 8171084: heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow > http://hg.openjdk.java.net/jdk/jdk/rev/a152f2d3320e > > (25) 8159127: hprof heap dumps broken for lambda classdata > http://hg.openjdk.java.net/jdk/jdk/rev/0b0ae99d8639 > http://hg.openjdk.java.net/jdk/jdk/rev/297ba2772122 > > (26) 8169232: SA: TestCpoolForInvokeDynamic.java fails with sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have found entry 1 > http://hg.openjdk.java.net/jdk/jdk/rev/48d874bf85fb > > (27) 8169638: serviceability/sa/TestInstanceKlassSize.java and serviceability/sa/TestInstanceKlassSizeForInterface.java fail compilation > http://hg.openjdk.java.net/jdk/jdk/rev/a20695c30be5 > > (28) 8169344: Potential open file descriptor in exists() of hotspot/agent/src/os/bsd/ps_core.c > http://hg.openjdk.java.net/jdk/jdk/rev/154099b110df > > (29) 7107018: sun.jvm.hotspot.utilities.soql.JSJavaHeap.forEachClass incorrect test > http://hg.openjdk.java.net/jdk/jdk/rev/815cfbe4878b > > (30) 8164783: SA: jhsdb clhsdb 'printall' often throws "Corrupted constant pool" assertion failure > http://hg.openjdk.java.net/jdk/jdk/rev/afd6ae4fec81 > > (31) 8164383: jhsdb dumps core on Solaris 12 when loading dumped core > http://hg.openjdk.java.net/jdk/jdk/rev/10e6e31dc1aa > > (32) 8166552: SA: Missed testcase for add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/815650daefb4 > > (33) 8027920: SA: Add default methods to InstanceKlass > http://hg.openjdk.java.net/jdk/jdk/rev/aed0f6434aea > > (34) 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" > http://hg.openjdk.java.net/jdk/jdk/rev/c0e02245ff93 > http://hg.openjdk.java.net/jdk/jdk/rev/12787d18650e > > (35) 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > http://hg.openjdk.java.net/jdk/jdk/rev/adf083cbc37f > > (36) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames > http://hg.openjdk.java.net/jdk/jdk/rev/8a2083c5e2b1 > http://hg.openjdk.java.net/jdk/jdk/rev/d46cac7959c4 > > (37) 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test > http://hg.openjdk.java.net/jdk/jdk/rev/82ece130a37b > From claes.redestad at oracle.com Tue Oct 9 13:15:27 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Oct 2018 15:15:27 +0200 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks Message-ID: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> Hi, please review the initial build support for JEP 230: Microbenchmark Suite[1]. Webrev: http://cr.openjdk.java.net/~redestad/8061281/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8061281 There are some added steps to be able to build the microbenchmark suite: export JMH_HOME=/path/to/jmh (mkdir -p $JMH_HOME; cd $JMH_HOME; bash make/devkit/createJMHBundle.sh; tar -zxvf jmh-1.21.tar.gz) bash configure --with-jmh=$JMH_HOME make build-microbenchmark This produces the JMH benchmarks under build/$CONF_NAME/images/test/micro/microbenchmarks.jar There is also support woven into the make run-test target (thanks to Magnus), allowing for integrated build and test: make run-test TEST="micro:java.lang.reflect" MICRO="OPTIONS=-f 1 -wi 2;RESULT_FORMAT=json" Remaining tasks before the JEP can be targetted is to write proper documentation and deciding which microbenchmarks to migrate from jmh-jdk-microbenchmarks[2]. Thanks! /Claes [1] http://openjdk.java.net/jeps/230 [2] http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ From martin.doerr at sap.com Tue Oct 9 13:25:40 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 9 Oct 2018 13:25:40 +0000 Subject: RFR(S): 8211856: [ppc, s390] ProblemList some failing tests. In-Reply-To: <0e8691ca-f811-e74f-8d23-95d365f62075@oracle.com> References: <898769097d8d40a6bdcd98fed93096d6@sap.com> <0e8691ca-f811-e74f-8d23-95d365f62075@oracle.com> Message-ID: Hi G?tz, looks good to me, too. I'm glad that it's not much more than SA and some jdk tests on AIX. Thanks for updating. Best regards, Martin -----Original Message----- From: jdk-dev On Behalf Of Vladimir Kozlov Sent: Montag, 8. Oktober 2018 19:11 To: jdk-dev at openjdk.java.net Subject: Re: RFR(S): 8211856: [ppc, s390] ProblemList some failing tests. Looks good to me. Thanks, Vladimir On 10/8/18 6:56 AM, Lindenmaier, Goetz wrote: > Hi, > > The ppc and s390 ports are now part of OpenJDK for 3-4 releases. > A great effort was taken to get all jtreg tests working. > > This change adds the few remaining issues to the ProblemsLists > of jdk and hotspot after opening bugs for them. > http://cr.openjdk.java.net/~goetz/wr18/8211856-problemList/01/ > > As these tests all fail in jdk11, I would like to downport this to jdk11u > later on. > > Best regards, > Goetz. > From magnus.ihse.bursie at oracle.com Tue Oct 9 13:44:40 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 9 Oct 2018 15:44:40 +0200 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks In-Reply-To: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> References: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> Message-ID: On 2018-10-09 15:15, Claes Redestad wrote: > Hi, > > please review the initial build support for JEP 230: Microbenchmark > Suite[1]. > > Webrev: http://cr.openjdk.java.net/~redestad/8061281/jdk.00/ The build changes look good. (But I can't really review them as I wrote most of them :-)) As you say, we also need to update documentation, especially doc/testing.md, with the new micro test suite for run-test. /Magnus > Bug: https://bugs.openjdk.java.net/browse/JDK-8061281 > > There are some added steps to be able to build the microbenchmark suite: > > export JMH_HOME=/path/to/jmh > (mkdir -p $JMH_HOME; cd $JMH_HOME; bash > make/devkit/createJMHBundle.sh; tar -zxvf jmh-1.21.tar.gz) > bash configure --with-jmh=$JMH_HOME > make build-microbenchmark > > This produces the JMH benchmarks under > build/$CONF_NAME/images/test/micro/microbenchmarks.jar > > There is also support woven into the make run-test target (thanks to > Magnus), allowing for integrated build and test: > > make run-test TEST="micro:java.lang.reflect" MICRO="OPTIONS=-f 1 -wi > 2;RESULT_FORMAT=json" > > Remaining tasks before the JEP can be targetted is to write proper > documentation and deciding which microbenchmarks to migrate from > jmh-jdk-microbenchmarks[2]. > > Thanks! > > /Claes > > [1] http://openjdk.java.net/jeps/230 > [2] http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ From goetz.lindenmaier at sap.com Tue Oct 9 14:01:49 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Oct 2018 14:01:49 +0000 Subject: RFR(S): 8211856: [ppc, s390] ProblemList some failing tests. In-Reply-To: References: <898769097d8d40a6bdcd98fed93096d6@sap.com> <0e8691ca-f811-e74f-8d23-95d365f62075@oracle.com> Message-ID: <607dfd2723bb4415a788584e430a954d@sap.com> Hi Martin, Thanks for the review. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Tuesday, October 9, 2018 3:26 PM > To: Vladimir Kozlov ; jdk- > dev at openjdk.java.net; Lindenmaier, Goetz > Subject: RE: RFR(S): 8211856: [ppc, s390] ProblemList some failing tests. > > Hi G?tz, > > looks good to me, too. > I'm glad that it's not much more than SA and some jdk tests on AIX. > Thanks for updating. > > Best regards, > Martin > > > -----Original Message----- > From: jdk-dev On Behalf Of Vladimir > Kozlov > Sent: Montag, 8. Oktober 2018 19:11 > To: jdk-dev at openjdk.java.net > Subject: Re: RFR(S): 8211856: [ppc, s390] ProblemList some failing tests. > > Looks good to me. > > Thanks, > Vladimir > > On 10/8/18 6:56 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > The ppc and s390 ports are now part of OpenJDK for 3-4 releases. > > A great effort was taken to get all jtreg tests working. > > > > This change adds the few remaining issues to the ProblemsLists > > of jdk and hotspot after opening bugs for them. > > http://cr.openjdk.java.net/~goetz/wr18/8211856-problemList/01/ > > > > As these tests all fail in jdk11, I would like to downport this to jdk11u > > later on. > > > > Best regards, > > Goetz. > > From goetz.lindenmaier at sap.com Tue Oct 9 14:02:50 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 9 Oct 2018 14:02:50 +0000 Subject: RFR(S): 8211856: [ppc, s390] ProblemList some failing tests. In-Reply-To: <0e8691ca-f811-e74f-8d23-95d365f62075@oracle.com> References: <898769097d8d40a6bdcd98fed93096d6@sap.com> <0e8691ca-f811-e74f-8d23-95d365f62075@oracle.com> Message-ID: <421cb19d44ee4c51a53b64fe23f0f01d@sap.com> Hi Vladimir, Thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: jdk-dev On Behalf Of Vladimir > Kozlov > Sent: Monday, October 8, 2018 7:11 PM > To: jdk-dev at openjdk.java.net > Subject: Re: RFR(S): 8211856: [ppc, s390] ProblemList some failing tests. > > Looks good to me. > > Thanks, > Vladimir > > On 10/8/18 6:56 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > The ppc and s390 ports are now part of OpenJDK for 3-4 releases. > > A great effort was taken to get all jtreg tests working. > > > > This change adds the few remaining issues to the ProblemsLists > > of jdk and hotspot after opening bugs for them. > > http://cr.openjdk.java.net/~goetz/wr18/8211856-problemList/01/ > > > > As these tests all fail in jdk11, I would like to downport this to jdk11u > > later on. > > > > Best regards, > > Goetz. > > From erik.joelsson at oracle.com Tue Oct 9 16:50:27 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 9 Oct 2018 09:50:27 -0700 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks In-Reply-To: References: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> Message-ID: <25f85015-0835-7732-8711-04e4db71c432@oracle.com> Hello, In JarArchive.gmk, I would suggest using the MakeTargetDir/MakeDir macros. If my patch goes in first, you will likely get a conflict there. It looks like BuildMicrobenchmarks.gmk is missing in the webrev. /Erik On 2018-10-09 06:44, Magnus Ihse Bursie wrote: > > > On 2018-10-09 15:15, Claes Redestad wrote: >> Hi, >> >> please review the initial build support for JEP 230: Microbenchmark >> Suite[1]. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8061281/jdk.00/ > The build changes look good. (But I can't really review them as I > wrote most of them :-)) > > As you say, we also need to update documentation, especially > doc/testing.md, with the new micro test suite for run-test. > > /Magnus >> Bug: https://bugs.openjdk.java.net/browse/JDK-8061281 >> >> There are some added steps to be able to build the microbenchmark suite: >> >> export JMH_HOME=/path/to/jmh >> (mkdir -p $JMH_HOME; cd $JMH_HOME; bash >> make/devkit/createJMHBundle.sh; tar -zxvf jmh-1.21.tar.gz) >> bash configure --with-jmh=$JMH_HOME >> make build-microbenchmark >> >> This produces the JMH benchmarks under >> build/$CONF_NAME/images/test/micro/microbenchmarks.jar >> >> There is also support woven into the make run-test target (thanks to >> Magnus), allowing for integrated build and test: >> >> make run-test TEST="micro:java.lang.reflect" MICRO="OPTIONS=-f 1 -wi >> 2;RESULT_FORMAT=json" >> >> Remaining tasks before the JEP can be targetted is to write proper >> documentation and deciding which microbenchmarks to migrate from >> jmh-jdk-microbenchmarks[2]. >> >> Thanks! >> >> /Claes >> >> [1] http://openjdk.java.net/jeps/230 >> [2] http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ > From claes.redestad at oracle.com Tue Oct 9 17:02:32 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Oct 2018 19:02:32 +0200 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks In-Reply-To: <25f85015-0835-7732-8711-04e4db71c432@oracle.com> References: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> <25f85015-0835-7732-8711-04e4db71c432@oracle.com> Message-ID: <407da004-74aa-a9c4-6de8-f4467a849980@oracle.com> Hi, On 2018-10-09 18:50, Erik Joelsson wrote: > Hello, > > In JarArchive.gmk, I would suggest using the MakeTargetDir/MakeDir > macros. If my patch goes in first, you will likely get a conflict there. none of this will go in until the JEP is targetted, so feel free to move ahead and we'll follow suit. > > It looks like BuildMicrobenchmarks.gmk is missing in the webrev. Oops, all added files were missing. Updated in place with all files included. /Claes From erik.joelsson at oracle.com Tue Oct 9 21:30:58 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 9 Oct 2018 14:30:58 -0700 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks In-Reply-To: <407da004-74aa-a9c4-6de8-f4467a849980@oracle.com> References: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> <25f85015-0835-7732-8711-04e4db71c432@oracle.com> <407da004-74aa-a9c4-6de8-f4467a849980@oracle.com> Message-ID: The new files look good. /Erik On 2018-10-09 10:02, Claes Redestad wrote: > Hi, > > On 2018-10-09 18:50, Erik Joelsson wrote: >> Hello, >> >> In JarArchive.gmk, I would suggest using the MakeTargetDir/MakeDir >> macros. If my patch goes in first, you will likely get a conflict there. > > none of this will go in until the JEP is targetted, so feel free to > move ahead and we'll follow suit. > >> >> It looks like BuildMicrobenchmarks.gmk is missing in the webrev. > > Oops, all added files were missing. Updated in place with all files > included. > > /Claes From serguei.spitsyn at oracle.com Tue Oct 9 22:37:43 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 9 Oct 2018 15:37:43 -0700 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: I hereby nominate Gary Adams (gadams) to JDK Committer. Gary works for the Oracle Serviceability team and has contributed more than 35 changes. His contributions can be found here [3]. Votes are due by 16:00 pm PT, October 23, 2018. Only current JDK Committers [1] 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]. Serguei Spitsyn [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From david.holmes at oracle.com Tue Oct 9 23:05:25 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Oct 2018 09:05:25 +1000 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: Vote: yes David On 10/10/2018 8:37 AM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more > than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) > From yumin.qi at gmail.com Tue Oct 9 23:09:19 2018 From: yumin.qi at gmail.com (yumin qi) Date: Tue, 9 Oct 2018 16:09:19 -0700 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: Vote:Yes On Tue, Oct 9, 2018 at 3:38 PM wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more > than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) > From jiangli.zhou at oracle.com Tue Oct 9 23:11:08 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 9 Oct 2018 16:11:08 -0700 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: Vote:Yes Thanks, Jiangli On 10/9/18 3:37 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more > than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From frederic.parain at oracle.com Tue Oct 9 23:11:02 2018 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 9 Oct 2018 19:11:02 -0400 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: <694279AD-C4C4-46C6-9F06-924824B9FA26@oracle.com> Vote: yes Fred > On Oct 9, 2018, at 19:05, David Holmes wrote: > > Vote: yes > > David > > On 10/10/2018 8:37 AM, serguei.spitsyn at oracle.com wrote: >> I hereby nominate Gary Adams (gadams) to JDK Committer. >> Gary works for the Oracle Serviceability team and has contributed more than 35 changes. >> His contributions can be found here [3]. >> Votes are due by 16:00 pm PT, October 23, 2018. >> Only current JDK Committers [1] 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]. >> Serguei Spitsyn >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From chris.plummer at oracle.com Tue Oct 9 23:57:30 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 9 Oct 2018 16:57:30 -0700 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: <0f58103b-8c3c-8f87-9509-2d0672b2991e@oracle.com> Vote: yes On 10/9/18 3:37 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more > than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From luke.hutch at gmail.com Wed Oct 10 00:27:23 2018 From: luke.hutch at gmail.com (Luke Hutchison) Date: Tue, 9 Oct 2018 18:27:23 -0600 Subject: Finalizer being run while class still in use (escape analysis bug) Message-ID: A user of a library I maintain, ClassGraph, has reported that a finalizer is being called on a class while methods of the class are still running, indicating that the class, even though it overrides finalize(), is not being correctly marked as GlobalEscape, so that escape analysis is trying to garbage-collect the class too early. Is this mailing list the correct place to report this bug? Here is the Maven rule for ClassGraph (you will also need to add Scala deps) -- you will need version 4.2.8, since I put a mitigation in place in version 4.2.9: io.github.classgraph classgraph 4.2.8 Here is the Scala code that reproduces the problem 100% of the time: import io.github.classgraph.{ClassGraph, ClassInfo} import scala.collection.JavaConverters._ import scala.compat.Platform.ConcurrentModificationException while (true) { try { new ClassGraph().scan() .getResourcesMatchingPattern(".*".r.pattern) .asScala .map(_.getURL) } catch { case cme: ConcurrentModificationException => cme.printStackTrace() throw cme } } Then start the JVM with -XX:+DoEscapeAnalysis The code new ClassGraph().scan() returns a ScanResult, and then as soon as ScanResult::getResourcesMatchingPattern is called with the ScanResult as the invocation target, escape analysis sees that the ScanResult has "gone out of scope" (despite the fact that the ScanResult is the invocation target for a currently-running method), and immediately tries to garbage collect it. This should not happen (1) since an invocation target should never be marked for garbage collection while its methods are being run, and (2) since ScanResult overrides Object::finalize, so should have been marked as "GlobalEscape" by escape analysis. The finalizer for the ScanResult class calls ScanResult::close, which clears the allResources list: https://github.com/classgraph/classgraph/blob/b9e8165d34575378697a727888457abb164311b8/src/main/java/io/github/classgraph/ScanResult.java#L940 This results in a ConcurrentModificationException since ScanResult::getResourcesMatchingPattern is still iterating through allResources: https://github.com/classgraph/classgraph/blob/b9e8165d34575378697a727888457abb164311b8/src/main/java/io/github/classgraph/ScanResult.java#L383 I read somewhere (and it makes sense) that escape analysis is performed by the compiler, so maybe this is a Scala bug, but this behavior is triggered by the JVM switch -XX:+DoEscapeAnalysis , and I couldn't find any references to escape analysis information in the Java classfile format spec, so that leads me to think this may be a JVM bug (which is why I am asking on this list). Obviously having a garbage collector run a finalizer run while methods of the object are still running is a very serious bug. Any pointers as to where to report this issue would be appreciated. Thanks! From david.holmes at oracle.com Wed Oct 10 00:35:50 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Oct 2018 10:35:50 +1000 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: Message-ID: Hi Luke, Moving this over to hotspot-dev. If it is an issue with the JIT escape analysis then hotspot-compiler-dev would be the place to raise this. But a general finalization issue may hit GC and runtime as well, so I redirected to the broader hotspot-dev. Also note that finalizers can run while methods of a class instance are still in progress [1] "Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable." - this is one of the evil things about finalizers. So it may not be a bug, just surprising. Cheers, David [1] https://docs.oracle.com/javase/specs/jls/se11/html/jls-12.html#jls-12.6 On 10/10/2018 10:27 AM, Luke Hutchison wrote: > A user of a library I maintain, ClassGraph, has reported that a finalizer > is being called on a class while methods of the class are still running, > indicating that the class, even though it overrides finalize(), is not > being correctly marked as GlobalEscape, so that escape analysis is trying > to garbage-collect the class too early. Is this mailing list the correct > place to report this bug? > > Here is the Maven rule for ClassGraph (you will also need to add Scala > deps) -- you will need version 4.2.8, since I put a mitigation in place in > version 4.2.9: > > > io.github.classgraph > classgraph > 4.2.8 > > > Here is the Scala code that reproduces the problem 100% of the time: > > import io.github.classgraph.{ClassGraph, ClassInfo} > import scala.collection.JavaConverters._ > import scala.compat.Platform.ConcurrentModificationException > > while (true) { > try { > new ClassGraph().scan() > .getResourcesMatchingPattern(".*".r.pattern) > .asScala > .map(_.getURL) > } catch { > case cme: ConcurrentModificationException => > cme.printStackTrace() > throw cme > } > } > > Then start the JVM with -XX:+DoEscapeAnalysis > > The code new ClassGraph().scan() returns a ScanResult, and then as soon as > ScanResult::getResourcesMatchingPattern is called with the ScanResult as > the invocation target, escape analysis sees that the ScanResult has "gone > out of scope" (despite the fact that the ScanResult is the invocation > target for a currently-running method), and immediately tries to garbage > collect it. This should not happen (1) since an invocation target should > never be marked for garbage collection while its methods are being run, and > (2) since ScanResult overrides Object::finalize, so should have been marked > as "GlobalEscape" by escape analysis. > > The finalizer for the ScanResult class calls ScanResult::close, which > clears the allResources list: > > https://github.com/classgraph/classgraph/blob/b9e8165d34575378697a727888457abb164311b8/src/main/java/io/github/classgraph/ScanResult.java#L940 > > This results in a ConcurrentModificationException since > ScanResult::getResourcesMatchingPattern is still iterating through > allResources: > > https://github.com/classgraph/classgraph/blob/b9e8165d34575378697a727888457abb164311b8/src/main/java/io/github/classgraph/ScanResult.java#L383 > > I read somewhere (and it makes sense) that escape analysis is performed by > the compiler, so maybe this is a Scala bug, but this behavior is triggered > by the JVM switch -XX:+DoEscapeAnalysis , and I couldn't find any > references to escape analysis information in the Java classfile format > spec, so that leads me to think this may be a JVM bug (which is why I am > asking on this list). > > Obviously having a garbage collector run a finalizer run while methods of > the object are still running is a very serious bug. Any pointers as to > where to report this issue would be appreciated. Thanks! > From roger.riggs at oracle.com Wed Oct 10 00:39:47 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 9 Oct 2018 20:39:47 -0400 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: <8e29340f-b090-c8a8-e9c9-6b8a6f299b6f@oracle.com> Vote: Yes On 10/9/18 6:37 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. From jcbeyler at google.com Wed Oct 10 00:40:43 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 9 Oct 2018 17:40:43 -0700 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: <0f58103b-8c3c-8f87-9509-2d0672b2991e@oracle.com> References: <0f58103b-8c3c-8f87-9509-2d0672b2991e@oracle.com> Message-ID: Vote: yes On Tue, Oct 9, 2018 at 4:58 PM Chris Plummer wrote: > Vote: yes > > On 10/9/18 3:37 PM, serguei.spitsyn at oracle.com wrote: > > I hereby nominate Gary Adams (gadams) to JDK Committer. > > > > Gary works for the Oracle Serviceability team and has contributed more > > than 35 changes. > > His contributions can be found here [3]. > > > > Votes are due by 16:00 pm PT, October 23, 2018. > > > > Only current JDK Committers [1] 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]. > > > > Serguei Spitsyn > > > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/projects/#committer-vote > > [3] > > > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) > > > -- Thanks, Jc From martinrb at google.com Wed Oct 10 00:51:39 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 9 Oct 2018 17:51:39 -0700 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: Message-ID: Search for calls to Reference.reachabilityFence(this); in the jdk sources. On Tue, Oct 9, 2018 at 5:35 PM, David Holmes wrote: > Hi Luke, > > Moving this over to hotspot-dev. If it is an issue with the JIT escape > analysis then hotspot-compiler-dev would be the place to raise this. But a > general finalization issue may hit GC and runtime as well, so I redirected > to the broader hotspot-dev. > > Also note that finalizers can run while methods of a class instance are > still in progress [1] > > "Optimizing transformations of a program can be designed that reduce the > number of objects that are reachable to be less than those which would > naively be considered reachable." > > - this is one of the evil things about finalizers. So it may not be a > bug, just surprising. > > Cheers, > David > > [1] https://docs.oracle.com/javase/specs/jls/se11/html/jls-12. > html#jls-12.6 > > > On 10/10/2018 10:27 AM, Luke Hutchison wrote: > >> A user of a library I maintain, ClassGraph, has reported that a finalizer >> is being called on a class while methods of the class are still running, >> indicating that the class, even though it overrides finalize(), is not >> being correctly marked as GlobalEscape, so that escape analysis is trying >> to garbage-collect the class too early. Is this mailing list the correct >> place to report this bug? >> >> Here is the Maven rule for ClassGraph (you will also need to add Scala >> deps) -- you will need version 4.2.8, since I put a mitigation in place in >> version 4.2.9: >> >> >> io.github.classgraph >> classgraph >> 4.2.8 >> >> >> Here is the Scala code that reproduces the problem 100% of the time: >> >> import io.github.classgraph.{ClassGraph, ClassInfo} >> import scala.collection.JavaConverters._ >> import scala.compat.Platform.ConcurrentModificationException >> >> while (true) { >> try { >> new ClassGraph().scan() >> .getResourcesMatchingPattern(".*".r.pattern) >> .asScala >> .map(_.getURL) >> } catch { >> case cme: ConcurrentModificationException => >> cme.printStackTrace() >> throw cme >> } >> } >> >> Then start the JVM with -XX:+DoEscapeAnalysis >> >> The code new ClassGraph().scan() returns a ScanResult, and then as soon as >> ScanResult::getResourcesMatchingPattern is called with the ScanResult as >> the invocation target, escape analysis sees that the ScanResult has "gone >> out of scope" (despite the fact that the ScanResult is the invocation >> target for a currently-running method), and immediately tries to garbage >> collect it. This should not happen (1) since an invocation target should >> never be marked for garbage collection while its methods are being run, >> and >> (2) since ScanResult overrides Object::finalize, so should have been >> marked >> as "GlobalEscape" by escape analysis. >> >> The finalizer for the ScanResult class calls ScanResult::close, which >> clears the allResources list: >> >> https://github.com/classgraph/classgraph/blob/b9e8165d345753 >> 78697a727888457abb164311b8/src/main/java/io/github/ >> classgraph/ScanResult.java#L940 >> >> This results in a ConcurrentModificationException since >> ScanResult::getResourcesMatchingPattern is still iterating through >> allResources: >> >> https://github.com/classgraph/classgraph/blob/b9e8165d345753 >> 78697a727888457abb164311b8/src/main/java/io/github/ >> classgraph/ScanResult.java#L383 >> >> I read somewhere (and it makes sense) that escape analysis is performed by >> the compiler, so maybe this is a Scala bug, but this behavior is triggered >> by the JVM switch -XX:+DoEscapeAnalysis , and I couldn't find any >> references to escape analysis information in the Java classfile format >> spec, so that leads me to think this may be a JVM bug (which is why I am >> asking on this list). >> >> Obviously having a garbage collector run a finalizer run while methods of >> the object are still running is a very serious bug. Any pointers as to >> where to report this issue would be appreciated. Thanks! >> >> From sharath.ballal at oracle.com Wed Oct 10 03:50:35 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 10 Oct 2018 03:50:35 +0000 (UTC) Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: <49e1cf37-a5db-4b14-8364-4936e80a8445@default> Vote: yes Thanks, Sharath -----Original Message----- From: Serguei Spitsyn Sent: Wednesday, October 10, 2018 4:08 AM To: jdk-dev Subject: CFV: New JDK Committer: Gary Adams I hereby nominate Gary Adams (gadams) to JDK Committer. Gary works for the Oracle Serviceability team and has contributed more than 35 changes. His contributions can be found here [3]. Votes are due by 16:00 pm PT, October 23, 2018. Only current JDK Committers [1] 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]. Serguei Spitsyn [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From volker.simonis at gmail.com Wed Oct 10 05:57:34 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Oct 2018 07:57:34 +0200 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: Vote: yes On Wed, Oct 10, 2018 at 12:38 AM wrote: > > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more > than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From volker.simonis at gmail.com Wed Oct 10 07:31:48 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Oct 2018 09:31:48 +0200 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: Message-ID: Hi Luke, I think the behaviour you see in not related to Escape Analysis at all. It should also occur if you run with -XX:-DoEscapeAnalysis (note that -XX:+DoEscapeAnalysis is the default). I also think that this behaviour doesn't break the Java specification. You have to carefully read the section cited by David. Consider the following small, stand alone program which should simulate your use case quite well: ================================================= import java.util.ArrayList; public class EAFinalizer { private static ArrayList cal = new ArrayList(10_000); static { for (int i = 0; i < 10_000; i++) cal.add(i); } private static ArrayList sink = new ArrayList(); private ArrayList al; public EAFinalizer(ArrayList al) { this.al = new ArrayList(al); } public static void main(String[] args) { while(true) { EAFinalizer eaf = new EAFinalizer(cal); System.err.println("Iterating " + eaf); for (Integer i : eaf.al) { // Create some garbage to trigger GC and finalization sink.add(new int[i.toString().length() * 1_000]); } // System.err.println("Iterated " + eaf); } } @Override protected void finalize() throws Throwable { System.err.println("Finalizing " + this); al.clear(); } } ================================================== Running this program (even with -XX:-DoEscapeAnalysis) will give you: $ java -XX:-DoEscapeAnalysis EAFinalizer Iterating EAFinalizer at 5ecddf8f Iterating EAFinalizer at 3f102e87 Iterating EAFinalizer at 27abe2cd Iterating EAFinalizer at 5f5a92bb Iterating EAFinalizer at 6fdb1f78 Iterating EAFinalizer at 51016012 Iterating EAFinalizer at 29444d75 Iterating EAFinalizer at 2280cdac Finalizing EAFinalizer at 2280cdac Finalizing EAFinalizer at 29444d75 Exception in thread "main" java.util.ConcurrentModificationException at java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1042) at java.base/java.util.ArrayList$Itr.next(ArrayList.java:996) at EAFinalizer.main(EAFinalizer.java:21) The problem with the program is that in the JIT compiled version of "test()" the EAFinalizer object "eaf" is not reachable in the for loop any more (because the JIT compiler is smart enough to detect that after extracting the AraryList "al" from "eaf", "eaf" is no longer needed). So when a GC is being triggered in the loop because the allocation of the integer array fails, the VM can safely garbage collect the "eaf" object and call its finalizer (notice that within the loop we only reference "eaf"s ArrayList field "al", but not the containing EAFinalizer object). You can easily fix this little toy example by uncommenting the second System.println statement in the "main()" method. This outputs "eaf" and thus keeps it alive. You can also run the program in interpreted mode ("-Xint") in which case you won't see the problem as well. That's because the Interpreter doesn't optimizes as eagerly as the JIT compiler and keeps "eaf" alive for the whole life time of the corresponding method invocation. That's actually what most people naivly expect to be the "guaranteed" life time of an object, but as the specification tells us, that's not required by the standard. If it would, the JIT would miss a whole lot of optimization opportunities. Regards, Volker On Wed, Oct 10, 2018 at 2:36 AM David Holmes wrote: > > Hi Luke, > > Moving this over to hotspot-dev. If it is an issue with the JIT escape > analysis then hotspot-compiler-dev would be the place to raise this. But > a general finalization issue may hit GC and runtime as well, so I > redirected to the broader hotspot-dev. > > Also note that finalizers can run while methods of a class instance are > still in progress [1] > > "Optimizing transformations of a program can be designed that reduce the > number of objects that are reachable to be less than those which would > naively be considered reachable." > > - this is one of the evil things about finalizers. So it may not be a > bug, just surprising. > > Cheers, > David > > [1] https://docs.oracle.com/javase/specs/jls/se11/html/jls-12.html#jls-12.6 > > On 10/10/2018 10:27 AM, Luke Hutchison wrote: > > A user of a library I maintain, ClassGraph, has reported that a finalizer > > is being called on a class while methods of the class are still running, > > indicating that the class, even though it overrides finalize(), is not > > being correctly marked as GlobalEscape, so that escape analysis is trying > > to garbage-collect the class too early. Is this mailing list the correct > > place to report this bug? > > > > Here is the Maven rule for ClassGraph (you will also need to add Scala > > deps) -- you will need version 4.2.8, since I put a mitigation in place in > > version 4.2.9: > > > > > > io.github.classgraph > > classgraph > > 4.2.8 > > > > > > Here is the Scala code that reproduces the problem 100% of the time: > > > > import io.github.classgraph.{ClassGraph, ClassInfo} > > import scala.collection.JavaConverters._ > > import scala.compat.Platform.ConcurrentModificationException > > > > while (true) { > > try { > > new ClassGraph().scan() > > .getResourcesMatchingPattern(".*".r.pattern) > > .asScala > > .map(_.getURL) > > } catch { > > case cme: ConcurrentModificationException => > > cme.printStackTrace() > > throw cme > > } > > } > > > > Then start the JVM with -XX:+DoEscapeAnalysis > > > > The code new ClassGraph().scan() returns a ScanResult, and then as soon as > > ScanResult::getResourcesMatchingPattern is called with the ScanResult as > > the invocation target, escape analysis sees that the ScanResult has "gone > > out of scope" (despite the fact that the ScanResult is the invocation > > target for a currently-running method), and immediately tries to garbage > > collect it. This should not happen (1) since an invocation target should > > never be marked for garbage collection while its methods are being run, and > > (2) since ScanResult overrides Object::finalize, so should have been marked > > as "GlobalEscape" by escape analysis. > > > > The finalizer for the ScanResult class calls ScanResult::close, which > > clears the allResources list: > > > > https://github.com/classgraph/classgraph/blob/b9e8165d34575378697a727888457abb164311b8/src/main/java/io/github/classgraph/ScanResult.java#L940 > > > > This results in a ConcurrentModificationException since > > ScanResult::getResourcesMatchingPattern is still iterating through > > allResources: > > > > https://github.com/classgraph/classgraph/blob/b9e8165d34575378697a727888457abb164311b8/src/main/java/io/github/classgraph/ScanResult.java#L383 > > > > I read somewhere (and it makes sense) that escape analysis is performed by > > the compiler, so maybe this is a Scala bug, but this behavior is triggered > > by the JVM switch -XX:+DoEscapeAnalysis , and I couldn't find any > > references to escape analysis information in the Java classfile format > > spec, so that leads me to think this may be a JVM bug (which is why I am > > asking on this list). > > > > Obviously having a garbage collector run a finalizer run while methods of > > the object are still running is a very serious bug. Any pointers as to > > where to report this issue would be appreciated. Thanks! > > From aph at redhat.com Wed Oct 10 09:05:58 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Oct 2018 10:05:58 +0100 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: Message-ID: On 10/10/2018 01:27 AM, Luke Hutchison wrote: > Obviously having a garbage collector run a finalizer run while methods of > the object are still running is a very serious bug. It's not, it's expected behaviour. Methods are not tracked for liveness analysis and as soon as an object is garbage collected its finalizer may be called. See https://docs.oracle.com/javase/9/docs/api/java/lang/ref/Reference.html#reachabilityFence-java.lang.Object- You will have to makes sure that there is a reachabilityFence? invocation after any calls which require an object to be kept alive. The problem with using finalizers is that finalizers may be run too soon (as here,) too late, or never. The "never" possibility really does happen: sometimes a generational collector moves objects to the old generation, and as long as there is little memory pressure only the young generations are collected. You may run out of file handles long before you run out of memory. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From luke.hutch at gmail.com Wed Oct 10 09:10:01 2018 From: luke.hutch at gmail.com (Luke Hutchison) Date: Wed, 10 Oct 2018 03:10:01 -0600 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: Message-ID: Hi Volker, Thanks for the standalone example, and I agree that your example does not violate the spec, because after the last reference to "eaf" is used in "for (Integer i : eaf.al)", the eaf object is free to be garbage collected. However, this is not an example of the behavior I was illustrating, because the for loop is running within a *static* method, main. I specifically mentioned non-static methods, so that a running method can access "this" at any time (and "this" will never "go out of scope"). My point was that if any *non-static* method of an object instance is currently running (i.e. whenever an object is "currently serving as an invocation target"), that object should never be considered unreachable. I believe that I did not misread the spec, and that this is covered by the wording, "A reachable object is any object that can be accessed in any potential continuing computation from any live thread", since if a non-static method of an object is currently running, that object not only "can be accessed" by a live thread, it *is* currently being accessed by a live thread. In fact, if you minimally modify your code example to put the loop inside a non-static method, this program no longer throws ConcurrentModificationException, illustrating that at least for the example you gave, the compiler and Hotspot are doing the right thing. The following code will iterate until OutOfMemoryError. ================================================= import java.util.ArrayList; public class EAFinalizer { private static ArrayList cal = new ArrayList(10_000); static { for (int i = 0; i < 10_000; i++) cal.add(i); } private static ArrayList sink = new ArrayList(); private ArrayList al; public EAFinalizer(ArrayList al) { this.al = new ArrayList(al); } public static void main(String[] args) { while(true) { EAFinalizer eaf = new EAFinalizer(cal); System.err.println("Iterating " + eaf); eaf.iterate(); // System.err.println("Iterated " + eaf); } } private void iterate() { for (Integer i : al) { // Create some garbage to trigger GC and finalization sink.add(new int[i.toString().length() * 1_000]); } } @Override protected void finalize() throws Throwable { System.err.println("Finalizing " + this); al.clear(); } } ================================================= The reason I didn't give a minimal testcase like the above for the behavior I am seeing is that I have not been able to duplicate this behavior except by running the actual code that was reported to me by the user. Thanks, Luke On Wed, Oct 10, 2018 at 1:32 AM Volker Simonis wrote: > Hi Luke, > > I think the behaviour you see in not related to Escape Analysis at > all. It should also occur if you run with -XX:-DoEscapeAnalysis (note > that -XX:+DoEscapeAnalysis is the default). I also think that this > behaviour doesn't break the Java specification. You have to carefully > read the section cited by David. > > Consider the following small, stand alone program which should > simulate your use case quite well: > > ================================================= > import java.util.ArrayList; > > public class EAFinalizer { > > private static ArrayList cal = new ArrayList(10_000); > static { > for (int i = 0; i < 10_000; i++) cal.add(i); > } > private static ArrayList sink = new ArrayList(); > > private ArrayList al; > > public EAFinalizer(ArrayList al) { > this.al = new ArrayList(al); > } > > public static void main(String[] args) { > while(true) { > EAFinalizer eaf = new EAFinalizer(cal); > System.err.println("Iterating " + eaf); > for (Integer i : eaf.al) { > // Create some garbage to trigger GC and finalization > sink.add(new int[i.toString().length() * 1_000]); > } > // System.err.println("Iterated " + eaf); > } > } > > @Override > protected void finalize() throws Throwable { > System.err.println("Finalizing " + this); > al.clear(); > } > } > ================================================== > > Running this program (even with -XX:-DoEscapeAnalysis) will give you: > > $ java -XX:-DoEscapeAnalysis EAFinalizer > Iterating EAFinalizer at 5ecddf8f > Iterating EAFinalizer at 3f102e87 > Iterating EAFinalizer at 27abe2cd > Iterating EAFinalizer at 5f5a92bb > Iterating EAFinalizer at 6fdb1f78 > Iterating EAFinalizer at 51016012 > Iterating EAFinalizer at 29444d75 > Iterating EAFinalizer at 2280cdac > Finalizing EAFinalizer at 2280cdac > Finalizing EAFinalizer at 29444d75 > Exception in thread "main" java.util.ConcurrentModificationException > at > java.base/java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1042) > at java.base/java.util.ArrayList$Itr.next(ArrayList.java:996) > at EAFinalizer.main(EAFinalizer.java:21) > > The problem with the program is that in the JIT compiled version of > "test()" the EAFinalizer object "eaf" is not reachable in the for loop > any more (because the JIT compiler is smart enough to detect that > after extracting the AraryList "al" from "eaf", "eaf" is no longer > needed). So when a GC is being triggered in the loop because the > allocation of the integer array fails, the VM can safely garbage > collect the "eaf" object and call its finalizer (notice that within > the loop we only reference "eaf"s ArrayList field "al", but not the > containing EAFinalizer object). > > You can easily fix this little toy example by uncommenting the second > System.println statement in the "main()" method. This outputs "eaf" > and thus keeps it alive. You can also run the program in interpreted > mode ("-Xint") in which case you won't see the problem as well. That's > because the Interpreter doesn't optimizes as eagerly as the JIT > compiler and keeps "eaf" alive for the whole life time of the > corresponding method invocation. That's actually what most people > naivly expect to be the "guaranteed" life time of an object, but as > the specification tells us, that's not required by the standard. If it > would, the JIT would miss a whole lot of optimization opportunities. > > Regards, > Volker > > From aph at redhat.com Wed Oct 10 09:16:13 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Oct 2018 10:16:13 +0100 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: Message-ID: <1a687eaf-0d7c-bbb7-faf3-3707b4389586@redhat.com> On 10/10/2018 10:10 AM, Luke Hutchison wrote: > My point was that if any *non-static* method of an object instance > is currently running (i.e. whenever an object is "currently serving > as an invocation target"), that object should never be considered > unreachable. That's incorrect. > I believe that I did not misread the spec, and that this is covered > by the wording, "A reachable object is any object that can be > accessed in any potential continuing computation from any live > thread", since if a non-static method of an object is currently > running, that object not only "can be accessed" by a live thread, it > *is* currently being accessed by a live thread. No. Believe it or not, a live method does not constitute an access to an object. An object can die and be finalized even before one if its methods is entered. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From luke.hutch at gmail.com Wed Oct 10 09:39:37 2018 From: luke.hutch at gmail.com (Luke Hutchison) Date: Wed, 10 Oct 2018 03:39:37 -0600 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: <1a687eaf-0d7c-bbb7-faf3-3707b4389586@redhat.com> References: <1a687eaf-0d7c-bbb7-faf3-3707b4389586@redhat.com> Message-ID: On Wed, Oct 10, 2018 at 3:06 AM Andrew Haley wrote: > The problem with using finalizers is that finalizers may be run too > soon (as here,) too late, or never. The "never" possibility really > does happen: sometimes a generational collector moves objects to the > old generation, and as long as there is little memory pressure only > the young generations are collected. You may run out of file handles > long before you run out of memory. I know there are a lot of downsides to finalizers, and I have made it clear in the documentation of my library that they should assign the object concerned in a try-with-resources block. The finalizer is simply there to clean up resources if the user neglects to follow this advice, which is common in Scala, since it doesn't have try-with-resources, so the user has to manually close the object in a "finally" block. I'm not as concerned with the "may never be run" case, since that is really on the users of the library. I'm more concerned about the "may be run while still in scope" case, since that can break things in very surprising ways. So given a class class A { void someMethod() { try { // ... } finally { Reference.reachabilityFence(this); } } } how is it that a call new A().someMethod() does not have a race condition between the "new A()" instance being invoked and reachability analysis realizing that there is a "this" reference in the finally block? Is it always true that there is an overlap between the reference to the invocation target being held and the reference to "this" in the method body being considered as reachable? Or stated as the inverse, is it guaranteed that there will be no gap in time (albeit infinitessimally small) between method invocation and the running of the method in which there will be no reference to the "new A()" object, where the finalizer could still be run? On Wed, Oct 10, 2018 at 3:16 AM Andrew Haley wrote: > > I believe that I did not misread the spec, and that this is covered > > by the wording, "A reachable object is any object that can be > > accessed in any potential continuing computation from any live > > thread", since if a non-static method of an object is currently > > running, that object not only "can be accessed" by a live thread, it > > *is* currently being accessed by a live thread. > > No. Believe it or not, a live method does not constitute an access > to an object. An object can die and be finalized even before one > if its methods is entered. > That is highly surprising. This makes finalizers a lot less reliable and more difficult to use than they could be. Wouldn't it make sense to consider the invocation targets in the stack during liveness analysis, so that out of the cases you gave, "finalizers may be run too soon (as here,) too late, or never", at least the "too soon" case is fixed? From aph at redhat.com Wed Oct 10 09:50:51 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Oct 2018 10:50:51 +0100 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: <1a687eaf-0d7c-bbb7-faf3-3707b4389586@redhat.com> Message-ID: <19a5a48f-9c73-76be-813c-0bb093b8dc73@redhat.com> On 10/10/2018 10:39 AM, Luke Hutchison wrote: > > class A { > void someMethod() { > try { > // ... > } finally { > Reference.reachabilityFence(this); > } > } > } > > how is it that a call > > new A().someMethod() > > does not have a race condition between the "new A()" instance being > invoked and reachability analysis realizing that there is a "this" > reference in the finally block? Is it always true that there is an > overlap between the reference to the invocation target being held > and the reference to "this" in the method body being considered as > reachable? You need two threads to have a race condition. I'm not sure what you're trying to ask: the reachabilityFence must run strictly after the body of the try clause, and it the object will be reachable until then. > Or stated as the inverse, is it guaranteed that there will be no gap in > time (albeit infinitessimally small) between method invocation and the > running of the method in which there will be no reference to the "new A()" > object, where the finalizer could still be run? The finalizer cannot be run as long as the object is reachable. The object is reachable until the reachabilityFence. > On Wed, Oct 10, 2018 at 3:16 AM Andrew Haley wrote: > >>> I believe that I did not misread the spec, and that this is covered >>> by the wording, "A reachable object is any object that can be >>> accessed in any potential continuing computation from any live >>> thread", since if a non-static method of an object is currently >>> running, that object not only "can be accessed" by a live thread, it >>> *is* currently being accessed by a live thread. >> >> No. Believe it or not, a live method does not constitute an access >> to an object. An object can die and be finalized even before one >> if its methods is entered. > > That is highly surprising. Yes, it is . You are not the first to be surprised by this. > This makes finalizers a lot less reliable and more difficult to use > than they could be. > > Wouldn't it make sense to consider the invocation targets in the stack > during liveness analysis, so that out of the cases you gave, "finalizers > may be run too soon (as here,) too late, or never", at least the "too soon" > case is fixed? We considered doing that; the discussion is online somewhere. I was in favour of doing what you suggest, but there is some performance impact of preserving liveness for all methods. In the end it was decided that we'd provide reachabilityFence. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From bsrbnd at gmail.com Wed Oct 10 10:37:28 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 10 Oct 2018 12:37:28 +0200 Subject: Primitive boolean array packing In-Reply-To: References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> <62d7984a-78dc-82a4-15aa-6deeebf95342@redhat.com> <882cb210-5870-2292-e78f-62857abdc54f@redhat.com> Message-ID: On Mon, 8 Oct 2018 at 19:18, B. Blaser wrote: > > On Mon, 8 Oct 2018 at 17:19, Andrew Haley wrote: > > > > On 10/08/2018 12:16 PM, B. Blaser wrote: > > > The current prototype was intended to scrupulously implement what the > > > JVMS explicitly allows for baload/bastore instructions. > > > But helper intrinsics might be good alternatives too, we could try both. > > > > So I tried it with a rough C++/assembly language test, and it doesn't > > make much sense to use this for default boolean arrays. The update > > sequence on AArch64 is > > > > 0: ldxrb w2, [x0]; > > and w2, w2, w1 > > stxrb w3, w2, [x0] > > cbnz w3, 0b > > > > (combined with a bunch of uninteresting shifts and logical > > operations.) We have to load a byte in exclusive state, AND or OR it > > as appropriate, then store it, still in exclusive state. That gets us > > the atomicity we need. > > > > 10**9 random set operations on an 8 Mbit array take 0.550s; with a > > boolean array the time is 0.150s. This is the local overhead of the > > load/store exclusive. > > Reducing memory consumption has a price which doesn't seem too > expensive, fortunately. On x86, I guess we have BTS/BTR (bit set and reset) with the LOCK prefix to assure atomicity. I'll do some experiment and update the prototype accordingly. Bernard From harold.seigel at oracle.com Wed Oct 10 11:33:14 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Wed, 10 Oct 2018 07:33:14 -0400 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: Vote: Yes Harold On 10/9/2018 6:37 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more > than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From sean.mullan at oracle.com Wed Oct 10 12:13:38 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 10 Oct 2018 08:13:38 -0400 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: <61f29144-e8a9-9637-c994-38f753c554b1@oracle.com> Vote: yes --Sean On 10/9/18 6:37 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more > than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) > From bhanu.prakash.gopularam at oracle.com Wed Oct 10 13:04:57 2018 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Wed, 10 Oct 2018 18:34:57 +0530 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: Vote: Yes Thanks, -Bhanu > On 10-Oct-2018, at 4:07 AM, serguei.spitsyn at oracle.com wrote: > > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From karen.kinnear at oracle.com Wed Oct 10 13:10:44 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 10 Oct 2018 09:10:44 -0400 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: <9FBB49CB-C80D-4DAA-AA4B-2AE94C6F1CB5@oracle.com> vote: yes thanks, Karen > On Oct 9, 2018, at 6:37 PM, serguei.spitsyn at oracle.com wrote: > > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From eric.caspole at oracle.com Wed Oct 10 13:16:24 2018 From: eric.caspole at oracle.com (Eric Caspole) Date: Wed, 10 Oct 2018 09:16:24 -0400 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: Vote: yes Regards, Eric On 10/9/2018 6:37 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more > than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From gromero at linux.vnet.ibm.com Wed Oct 10 13:35:14 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 10 Oct 2018 10:35:14 -0300 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: <82f161fc-a004-7d27-32fa-60edfc75d2c5@linux.vnet.ibm.com> Vote: yes On 10/09/2018 07:37 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) > From szegedia at gmail.com Wed Oct 10 14:00:59 2018 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 10 Oct 2018 16:00:59 +0200 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: <1a687eaf-0d7c-bbb7-faf3-3707b4389586@redhat.com> Message-ID: > On 2018. Oct 10., at 11:39, Luke Hutchison wrote: > > So given a class > > class A { > void someMethod() { > try { > // ... > } finally { > Reference.reachabilityFence(this); > } > } > } > > how is it that a call > > new A().someMethod() > > does not have a race condition between the "new A()" instance being invoked > and reachability analysis realizing that there is a "this" reference in the > finally block? Is it always true that there is an overlap between the > reference to the invocation target being held and the reference to "this" > in the method body being considered as reachable? > > Or stated as the inverse, is it guaranteed that there will be no gap in > time (albeit infinitessimally small) between method invocation and the > running of the method in which there will be no reference to the "new A()" > object, where the finalizer could still be run? The ? statically decidable ? existence of the call to reachabilityFence with ?this? being passed into it (or call to anything else really? System.out.println would do too) is enough to ensure that the reference must live until at least the fence call was invoked (note: not necessarily until it returns, but that?s academical). There?s no race condition. FWIW, most of these optimizations only kick in after inlining - someMethod() would get inlined into the body of the method that created the new A() instance and then the resulting merged code with inlined body can be analyzed as a unit. I think you would most likely not even notice this in scenarios that don?t involve inlining, but honestly it?s possible to have a JIT that could decide to mark a local variable dead immediately after it got loaded on stack for a call if there are no further uses of it. Even so, from reachability point of view it?s an atomic operation to pop the arguments off the stack in the caller frame and assign them to parameter local variables in the callee frame. Having a gap in the reachability while transitioning from caller context to callee context would be a glaring bug indeed. Attila. From szegedia at gmail.com Wed Oct 10 14:01:40 2018 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 10 Oct 2018 16:01:40 +0200 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: <19a5a48f-9c73-76be-813c-0bb093b8dc73@redhat.com> References: <1a687eaf-0d7c-bbb7-faf3-3707b4389586@redhat.com> <19a5a48f-9c73-76be-813c-0bb093b8dc73@redhat.com> Message-ID: <719DC264-C858-43D2-9589-178564F67EC2@gmail.com> > On 2018. Oct 10., at 11:50, Andrew Haley wrote: > > On 10/10/2018 10:39 AM, Luke Hutchison wrote: >> [?] >> does not have a race condition between the "new A()" instance being >> invoked and reachability analysis realizing that there is a "this" >> reference in the finally block? Is it always true that there is an >> overlap between the reference to the invocation target being held >> and the reference to "this" in the method body being considered as >> reachable? > > You need two threads to have a race condition. I'm not sure what > you're trying to ask: the reachabilityFence must run strictly after > the body of the try clause, and it the object will be reachable until > then. I believe the finalizer thread is the second thread he had in mind. > [?] >>> >>> No. Believe it or not, a live method does not constitute an access >>> to an object. An object can die and be finalized even before one >>> if its methods is entered. >> >> That is highly surprising. > > Yes, it is . You are not the first to be surprised by this. > >> This makes finalizers a lot less reliable and more difficult to use >> than they could be. >> >> Wouldn't it make sense to consider the invocation targets in the stack >> during liveness analysis, so that out of the cases you gave, "finalizers >> may be run too soon (as here,) too late, or never", at least the "too soon" >> case is fixed? > > We considered doing that; the discussion is online somewhere. I was in > favour of doing what you suggest, but there is some performance impact > of preserving liveness for all methods. In the end it was decided that > we'd provide reachabilityFence. I think the general consensus is that finalization is a shunned feature[1]. Weakening optimizations, or really making any tradeoff no matter how small for the purpose of improving finalization ergonomics is not going to happen as there?s no perceived value in doing it. Attila. -- [1] unofficial term I just made up, but I like the ring of it. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim.barrett at oracle.com Wed Oct 10 15:53:50 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 10 Oct 2018 11:53:50 -0400 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: <719DC264-C858-43D2-9589-178564F67EC2@gmail.com> References: <1a687eaf-0d7c-bbb7-faf3-3707b4389586@redhat.com> <19a5a48f-9c73-76be-813c-0bb093b8dc73@redhat.com> <719DC264-C858-43D2-9589-178564F67EC2@gmail.com> Message-ID: > On Oct 10, 2018, at 10:01 AM, Attila Szegedi wrote: > > I think the general consensus is that finalization is a shunned feature[1]. Weakening optimizations, or really making any tradeoff no matter how small for the purpose of improving finalization ergonomics is not going to happen as there?s no perceived value in doing it. Finalization was deprecated in JDK 9 (*). There's an ongoing (though progressing slowly) process of eliminating its usage in the JDK. Sometime after that it may go away entirely, or perhaps require some sort of explicit opt-in, making it possible to eliminate various GC overheads associated with it. (*) Use PhantomReference, or a helper like java.lang.ref.Cleaner. Though that change the liveness question in this thread. From lois.foltan at oracle.com Wed Oct 10 16:04:46 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 10 Oct 2018 12:04:46 -0400 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: Vote: yes Lois On 10/9/2018 6:37 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more > than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From igor.ignatyev at oracle.com Wed Oct 10 17:05:52 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 10 Oct 2018 10:05:52 -0700 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: <01E605EB-AA55-4420-BF45-D4591A7FF411@oracle.com> Vote: yes -- Igor > On Oct 9, 2018, at 3:37 PM, serguei.spitsyn at oracle.com wrote: > > I hereby nominate Gary Adams (gadams) to JDK Committer. From dean.long at oracle.com Wed Oct 10 17:37:49 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 10 Oct 2018 10:37:49 -0700 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: Vote: yes dl On 10/9/18 3:37 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more > than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From david.lloyd at redhat.com Wed Oct 10 20:19:27 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 10 Oct 2018 15:19:27 -0500 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: <1a687eaf-0d7c-bbb7-faf3-3707b4389586@redhat.com> <19a5a48f-9c73-76be-813c-0bb093b8dc73@redhat.com> <719DC264-C858-43D2-9589-178564F67EC2@gmail.com> Message-ID: On Wed, Oct 10, 2018 at 2:57 PM Luke Hutchison wrote: > On Wed, Oct 10, 2018 at 9:53 AM Kim Barrett wrote: > > Finalization was deprecated in JDK 9 (*). There's an ongoing (though > > progressing slowly) process of eliminating its usage in the JDK. > > Sometime after that it may go away entirely, or perhaps require some > > sort of explicit opt-in, making it possible to eliminate various GC > > overheads associated with it. > [..] > It would be a much better API contract to state that "if you override > finalize(), some code optimizations may not kick in" rather than "if you > override finalize(), things will almost certainly break, and you get to > keep all the pieces". Unfortunately this doesn't really make a difference: finalize() is broken for reasons beyond the "early" cleanup problem, and the "early" cleanup problem actually also applies equally to PhantomReference- and Cleaner-based solutions, as well as other *Reference types. This email thread may have obscured the fact that the two issues are really unconnected. One thing that always (safely) forces references to stay alive (apart from reachabilityFence(), which is the best solution) is calling either a non-static native method on that object, or otherwise passing the reference to a native method as a parameter or part of the graph that is reachable from a parameter. Since finalizers often deal with native resources, sometimes this prevents the problem from appearing in the first place. Another easy-ish solution is synchronization. If your impactful methods execute under a synchronized block, and your finalize() or cleanup operations also operates under the same block, then premature cleanup cannot happen. Obviously you can't use the object itself in the PhantomReference/Cleaner case otherwise the object will never be enqueued. As Andrew said, you could make your own fence using a volatile field write/read. I think it might be enough to write the field at the fence point and read the field in finalize(), though a JMM ace would have to confirm that. -- - DML From luke.hutch at gmail.com Wed Oct 10 19:56:01 2018 From: luke.hutch at gmail.com (Luke Hutchison) Date: Wed, 10 Oct 2018 13:56:01 -0600 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: <1a687eaf-0d7c-bbb7-faf3-3707b4389586@redhat.com> <19a5a48f-9c73-76be-813c-0bb093b8dc73@redhat.com> <719DC264-C858-43D2-9589-178564F67EC2@gmail.com> Message-ID: On Wed, Oct 10, 2018 at 9:53 AM Kim Barrett wrote: > Finalization was deprecated in JDK 9 (*). There's an ongoing (though > progressing slowly) process of eliminating its usage in the JDK. > Sometime after that it may go away entirely, or perhaps require some > sort of explicit opt-in, making it possible to eliminate various GC > overheads associated with it. > > (*) Use PhantomReference, or a helper like java.lang.ref.Cleaner. > Though that change the liveness question in this thread. > Yes, I saw both the deprecation of finalization and the introduction of Cleaner -- though there will be a lot of legacy code and legacy runtime environments that are going to stick around for a long time, especially given the problems so many people are having moving to JPMS for non-trivial usecases. What would be wrong with simply disabling inlining altogether for any classes that override finalize()? Inlining seems to be the main sticking point. I would strongly prefer to take a performance hit over having finalization being so broken. Running finalizers late or never is much less of a problem than running them early, since running them late or never *may* lead to resource leaks, but running them early *will almost certainly* break everything that uses finalizers at some point. It would be a much better API contract to state that "if you override finalize(), some code optimizations may not kick in" rather than "if you override finalize(), things will almost certainly break, and you get to keep all the pieces". From hboehm at google.com Wed Oct 10 23:58:47 2018 From: hboehm at google.com (Hans Boehm) Date: Wed, 10 Oct 2018 16:58:47 -0700 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: <5daeb9a2-0e87-29e6-87e3-fd7a1cda2dba@cs.oswego.edu> References: <5daeb9a2-0e87-29e6-87e3-fd7a1cda2dba@cs.oswego.edu> Message-ID: From: Luke Hutchison On Wed, Oct 10, 2018 at 9:53 AM Kim Barrett wrote: > Finalization was deprecated in JDK 9 (*). There's an ongoing (though > progressing slowly) process of eliminating its usage in the JDK. > Sometime after that it may go away entirely, or perhaps require some > sort of explicit opt-in, making it possible to eliminate various GC > overheads associated with it. > > (*) Use PhantomReference, or a helper like java.lang.ref.Cleaner. > Though that change the liveness question in this thread. > Yes, I saw both the deprecation of finalization and the introduction of Cleaner -- though there will be a lot of legacy code and legacy runtime environments that are going to stick around for a long time, especially given the problems so many people are having moving to JPMS for non-trivial usecases. What would be wrong with simply disabling inlining altogether for any classes that override finalize()? Inlining seems to be the main sticking point. I would strongly prefer to take a performance hit over having finalization being so broken. Running finalizers late or never is much less of a problem than running them early, since running them late or never *may* lead to resource leaks, but running them early *will almost certainly* break everything that uses finalizers at some point. It would be a much better API contract to state that "if you override finalize(), some code optimizations may not kick in" rather than "if you override finalize(), things will almost certainly break, and you get to keep all the pieces". I don't think inlining is the real problem. The general problem is that just because a field of an object is still in use, does not mean that the containing object is still reachable. The register holding the reference may have been reused. e.g. for the field value itself. The receiver reference inside a method is really just like any other parameter. And it's common to pass parameters in registers that can be reused once we no longer need the parameter values, e.g. because we've retrieved the fields we need. One could solve this by preventing elimination of dead references. But, it's hard to do this only where it matters. Doing it everywhere is an option, but hasn't gotten a lot of traction. There is a more elaborate proposal to make this easier than reachabilityFence at https://docs.google.com/document/d/1yMC4VzZobMQTrVAraMy7xBdWPCJ0p7G5r_43yaqsj-s/edit?usp=sharing Currently reachabilityFence is by far the best solution. (Passing the reference to an existing native method, e.g. by removing "static" is more subtle, but otherwise as good when it works.) I believe the cost of reachabilityFence in implementations that support it is near zero; all it has to do is keep a value around on the stack or in a register. In my experience, it's quite hard to portably, efficiently, and robustly implement reachabilityFence() where it's not already supported. Passing it to another Java method may work, but is not portable. ReachabilityFence still has the substantial disadvantage that it often needs to be used in many methods after referring to a field that is cleaned up by a Cleaner or finalizer, etc. The above proposal allows the field declaration to be modified, instead of every method that touches it. But the programmer still needs to know that there is an issue. (@ReachabilitySensitive is a placeholder name. @Cleaned is the current front runner in my vicinity.) Hans From jini.george at oracle.com Thu Oct 11 04:31:23 2018 From: jini.george at oracle.com (Jini George) Date: Thu, 11 Oct 2018 10:01:23 +0530 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: <756bd557-7daa-a2f3-ff13-f5487b43762b@oracle.com> Vote: yes -jini On 10/10/2018 11:27 AM, Volker Simonis wrote: > Vote: yes > > On Wed, Oct 10, 2018 at 12:38 AM wrote: >> >> I hereby nominate Gary Adams (gadams) to JDK Committer. >> >> Gary works for the Oracle Serviceability team and has contributed more >> than 35 changes. >> His contributions can be found here [3]. >> >> Votes are due by 16:00 pm PT, October 23, 2018. >> >> Only current JDK Committers [1] 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]. >> >> Serguei Spitsyn >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3] >> http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From erik.osterlund at oracle.com Thu Oct 11 05:42:36 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 11 Oct 2018 07:42:36 +0200 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: <5daeb9a2-0e87-29e6-87e3-fd7a1cda2dba@cs.oswego.edu> Message-ID: <2712E10A-816A-4844-AB13-81A52F3586C1@oracle.com> Hi Hans, Would users be happier if e.g. try with resources could be relied upon having things reachable in a scope for this pattern? try (SlipperyObject x = getSlipperyObject()) { // x is strongly reachable in this scope } // x won?t die until here Seems more intuitive for me to reason about the reachability in a scope than manually analysing the uses of locals. I suppose you would have to implement AutoCloseable to be allowed to use such a construct. But a SlipperyObject class could maybe wrap that and even call reachability fence in its close method for portability. The trailing close function might already have the same effect as reachabilityFence. Just an idea. Thanks, /Erik > On 11 Oct 2018, at 01:58, Hans Boehm wrote: > > From: Luke Hutchison > >> On Wed, Oct 10, 2018 at 9:53 AM Kim Barrett wrote: >> Finalization was deprecated in JDK 9 (*). There's an ongoing (though >> progressing slowly) process of eliminating its usage in the JDK. >> Sometime after that it may go away entirely, or perhaps require some >> sort of explicit opt-in, making it possible to eliminate various GC >> overheads associated with it. >> >> (*) Use PhantomReference, or a helper like java.lang.ref.Cleaner. >> Though that change the liveness question in this thread. >> > Yes, I saw both the deprecation of finalization and the introduction of > Cleaner -- though there will be a lot of legacy code and legacy runtime > environments that are going to stick around for a long time, especially > given the problems so many people are having moving to JPMS for non-trivial > usecases. > What would be wrong with simply disabling inlining altogether for any > classes that override finalize()? Inlining seems to be the main sticking > point. I would strongly prefer to take a performance hit over having > finalization being so broken. Running finalizers late or never is much less > of a problem than running them early, since running them late or never > *may* lead to resource leaks, but running them early *will almost > certainly* break everything that uses finalizers at some point. > It would be a much better API contract to state that "if you override > finalize(), some code optimizations may not kick in" rather than "if you > override finalize(), things will almost certainly break, and you get to > keep all the pieces". > > > I don't think inlining is the real problem. The general problem is that > just because a field > of an object is still in use, does not mean that the containing object is > still reachable. > The register holding the reference may have been reused. e.g. for the field > value itself. > The receiver reference inside a method is really just like any other > parameter. And it's > common to pass parameters in registers that can be reused once we no longer > need > the parameter values, e.g. because we've retrieved the fields we need. > > One could solve this by preventing elimination of dead references. But, > it's hard to do this > only where it matters. Doing it everywhere is an option, but hasn't gotten > a lot of traction. > There is a more elaborate proposal to make this easier than > reachabilityFence at > https://docs.google.com/document/d/1yMC4VzZobMQTrVAraMy7xBdWPCJ0p7G5r_43yaqsj-s/edit?usp=sharing > > Currently reachabilityFence is by far the best solution. (Passing the > reference to an > existing native method, e.g. by removing "static" is more subtle, but > otherwise as good when > it works.) I believe the cost of reachabilityFence in implementations that > support it is near zero; all it has to do is keep a value around on the > stack or in a register. > In my experience, it's quite hard to portably, efficiently, and robustly > implement reachabilityFence() > where it's not already supported. Passing it to another Java method may > work, but is not > portable. > > ReachabilityFence still has the substantial disadvantage that it often > needs to be used in many methods after referring to a field that is cleaned > up by a Cleaner or finalizer, etc. The > above proposal allows the field declaration to be modified, instead of > every method that > touches it. But the programmer still needs to know that there is an issue. > (@ReachabilitySensitive is a placeholder name. @Cleaned is the current > front runner in > my vicinity.) > > Hans From dmitry.markov at oracle.com Thu Oct 11 08:44:17 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Thu, 11 Oct 2018 09:44:17 +0100 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: <0449E348-DEB3-4622-A70B-2C43E3F6AEF0@oracle.com> Vote: yes Thanks, Dmitry > On 9 Oct 2018, at 23:37, serguei.spitsyn at oracle.com wrote: > > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From aph at redhat.com Thu Oct 11 09:29:11 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Oct 2018 10:29:11 +0100 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: <1a687eaf-0d7c-bbb7-faf3-3707b4389586@redhat.com> <19a5a48f-9c73-76be-813c-0bb093b8dc73@redhat.com> <719DC264-C858-43D2-9589-178564F67EC2@gmail.com> Message-ID: <63077d5e-56ad-6f9d-5a05-082bbee7c953@redhat.com> On Wed, Oct 10, 2018 at 9:53 AM Kim Barrett wrote: > Finalization was deprecated in JDK 9 (*). There's an ongoing (though > progressing slowly) process of eliminating its usage in the JDK. > Sometime after that it may go away entirely, or perhaps require some > sort of explicit opt-in, making it possible to eliminate various GC > overheads associated with it. > > (*) Use PhantomReference, or a helper like java.lang.ref.Cleaner. > Though that change the liveness question in this thread. It doesn't matter whether finalization is used or PhantomReferences, or whatever. The problem of "early" collection remains the same on every possible mechanism which relies on the GC to trigger cleanup, so reachabilityFence still has to be used to prevent early collectiona from happening. The existence of PhantomReference does show, however, why treating classes with finalizers in a special way is pointless. Hans Boehm's proposal for an annotation such as @Cleaned on the class makes the most sense, IMO. But we can probably live with reachabilityFence, although it's a horrible name. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dalibor.topic at oracle.com Thu Oct 11 10:12:28 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 11 Oct 2018 12:12:28 +0200 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: <756bd557-7daa-a2f3-ff13-f5487b43762b@oracle.com> References: <756bd557-7daa-a2f3-ff13-f5487b43762b@oracle.com> Message-ID: Vote: Yes. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 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 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, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From kim.barrett at oracle.com Thu Oct 11 17:24:19 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 11 Oct 2018 13:24:19 -0400 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: <63077d5e-56ad-6f9d-5a05-082bbee7c953@redhat.com> References: <1a687eaf-0d7c-bbb7-faf3-3707b4389586@redhat.com> <19a5a48f-9c73-76be-813c-0bb093b8dc73@redhat.com> <719DC264-C858-43D2-9589-178564F67EC2@gmail.com> <63077d5e-56ad-6f9d-5a05-082bbee7c953@redhat.com> Message-ID: > On Oct 11, 2018, at 5:29 AM, Andrew Haley wrote: > > On Wed, Oct 10, 2018 at 9:53 AM Kim Barrett wrote: >> Finalization was deprecated in JDK 9 (*). There's an ongoing (though >> progressing slowly) process of eliminating its usage in the JDK. >> Sometime after that it may go away entirely, or perhaps require some >> sort of explicit opt-in, making it possible to eliminate various GC >> overheads associated with it. >> >> (*) Use PhantomReference, or a helper like java.lang.ref.Cleaner. >> Though that change the liveness question in this thread. > > It doesn't matter whether finalization is used or PhantomReferences, > or whatever. The problem of "early" collection remains the same on > every possible mechanism which relies on the GC to trigger cleanup, so > reachabilityFence still has to be used to prevent early collectiona > from happening. Correct, and sorry for the ?typo?; that was supposed to be "Though that doesn?t change the liveness question in this thread." From sean.coffey at oracle.com Thu Oct 11 17:54:10 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 11 Oct 2018 18:54:10 +0100 Subject: Tagging proposal for JDK GA releases In-Reply-To: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> References: <7e7efb47-61cf-f249-fa94-3c26bbc0ba8d@oracle.com> Message-ID: Thanks for the feedback to date. Given the support expressed for this change, and the lack of objections, I'll propose the necessary jcheck changes to the Code Tools Project. Once approved, I'll ask the Leads of the relevant JDK Projects to begin using the new tag format each time a JDK release achieves the GA milestone. regards, Sean. On 03/10/2018 15:54, Se?n Coffey wrote: > I'd like to propose an enhancement to the JDK build-tagging > convention to help users more easily identify JDK GA releases > via Mercurial tag names. > > The concept is quite simple and lets people identify snapshots > of GA releases in Mercurial history without having to know the > build number of the GA release. > > For example, to obtain JDK 10.0.2 GA sources today, one issues the > `hg update -r jdk-10.0.2+13` command. With the proposed > enhancement, `hg update -r jdk-10.0.2-ga` could have been used. > It's proposed that the new ga tag would be in addition to the regular > GA build number tag. It would be added to the relevant repository > once the GA milestone has been reached. > > This new convention would be used for future JDK releases and is > tracked via JDK-8180946[1]. If the changes are adopted, I can > look at retroactively adding labels for all feature JDK GA releases > since JDK 7 to the JDK feature-release main-line repository. > > To accommodate the new tag format, some simple jcheck edits > would be required. Test checks would also be added. > > Comments? > > regards, > Sean. > > [1] https://bugs.openjdk.java.net/browse/JDK-8180946 From hboehm at google.com Thu Oct 11 19:56:03 2018 From: hboehm at google.com (Hans Boehm) Date: Thu, 11 Oct 2018 12:56:03 -0700 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: <2712E10A-816A-4844-AB13-81A52F3586C1@oracle.com> References: <5daeb9a2-0e87-29e6-87e3-fd7a1cda2dba@cs.oswego.edu> <2712E10A-816A-4844-AB13-81A52F3586C1@oracle.com> Message-ID: On Wed, Oct 10, 2018 at 10:42 PM Erik Osterlund wrote: > > Hi Hans, > > Would users be happier if e.g. try with resources could be relied upon having things reachable in a scope for this pattern? > > try (SlipperyObject x = getSlipperyObject()) { > // x is strongly reachable in this scope > } > // x won?t die until here > > Seems more intuitive for me to reason about the reachability in a scope than manually analysing the uses of locals. > > I suppose you would have to implement AutoCloseable to be allowed to use such a construct. But a SlipperyObject class could maybe wrap that and even call reachability fence in its close method for portability. > > The trailing close function might already have the same effect as reachabilityFence. > > Just an idea. > > Thanks, > /Erik > I think the easiest and most common use case is one in which a class C includes a field that needs to be explicitly cleaned up when an instance of C is dropped. (Unfortunately even libcore contains a bunch of more complicated patterns, but let's ignore those here.) In that case, the alternatives are basically: Current: class C { private long f; // A handle to some resource needing explicit cleaning. ... Foo someMethod(C that) { try { ... access f and that.f ... } finally { reachabilityFence(this); reachabilityFence(that); } ... repeat for other methods ... } IIUC, with your proposal, it becomes class C { private long f; // A handle to some resource needing explicit cleaning. ... Foo someMethod(C that) { try (C me = this; c myThat = that) { ... access f and that.f, or equivalently me.f and myThat.f ... } ... repeat for other methods ... } That's clearly shorter by a constant factor. But to me it doesn't look consistent with the normal try-with-resources statement. My alternative proposal would reduce this to: class C { @Cleaned private long f; // A handle to some resource needing explicit cleaning. ... Foo someMethod(C that) { ... access f and that.f ... } ... Other methods also need no special treatment ... } This has the advantage that the annotation is confined to one place, arguably where it belongs. The annotation overhead is shorter by a factor of O(). It doesn't get around the fact that this is really difficult to explain to a non-compiler-expert in full detail. But I think it's possible to quickly explain the annotation in a way that will make sense to most people and will generally lead them to correct code. Full disclosure: This remains messy in some cases, notably if you let f escape from C by handing it to a caller. There's some argument that that should never happen for a properly designed API. It puts the caller into the position of explicitly having to reason about object lifetimes. Unfortunately things like this do seem to be hard to avoid ins some cases. Even in the messy cases, so far I've almost always found @Cleaned to be more convenient than explicit reachabilityFences. From Peter.B.Kessler at Oracle.COM Thu Oct 11 22:42:40 2018 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Thu, 11 Oct 2018 15:42:40 -0700 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: <5daeb9a2-0e87-29e6-87e3-fd7a1cda2dba@cs.oswego.edu> <2712E10A-816A-4844-AB13-81A52F3586C1@oracle.com> Message-ID: <87596f65-79f1-64ac-96f8-8a315ad1f1d0@Oracle.COM> The JavaDoc for `Reference.reachabilityFence(Object ref)` [http://hg.openjdk.java.net/jdk/jdk/file/62523934374c/src/java.base/share/classes/java/lang/ref/Reference.java#l509] says @param ref the reference. If {@code null}, this method has no effect. It might be true that if the actual parameter is a constant `null` the method has no effect. I understand the intent of the method if applied to a simple variable (e.g., `this`). What is the effect of calling the method with a complex expression that yields an `Object`? How does the compiler know which lifetime to extend? When is the actual parameter evaluated? What if the complex expression yields `null`? Does the method still have "no effect"? The try-with-resource solution also operates on expressions, but there it is more obvious what to make a strong reference to to keep a particular Object reachable. Hans's `@Cleaned` annotation can only be applied to fields, not expressions. Does that make it less useful? ... peter On 10/11/18 12:56 PM, Hans Boehm wrote: > On Wed, Oct 10, 2018 at 10:42 PM Erik Osterlund > wrote: >> >> Hi Hans, >> >> Would users be happier if e.g. try with resources could be relied upon >> having things reachable in a scope for this pattern? >> >> try (SlipperyObject x = getSlipperyObject()) { >> // x is strongly reachable in this scope >> } >> // x won?t die until here >> >> Seems more intuitive for me to reason about the reachability in a scope >> than manually analysing the uses of locals. >> >> I suppose you would have to implement AutoCloseable to be allowed to use >> such a construct. But a SlipperyObject class could maybe wrap that and even >> call reachability fence in its close method for portability. >> >> The trailing close function might already have the same effect as >> reachabilityFence. >> >> Just an idea. >> >> Thanks, >> /Erik >> > > I think the easiest and most common use case is one in which a class C > includes a field that needs to be explicitly cleaned up when an instance of > C is dropped. > (Unfortunately even libcore contains a bunch of more complicated patterns, > but let's ignore those here.) > > In that case, the alternatives are basically: > > Current: > > class C { > private long f; // A handle to some resource needing explicit cleaning. > ... > Foo someMethod(C that) { > try { > ... access f and that.f ... > } finally { > reachabilityFence(this); > reachabilityFence(that); > } > ... repeat for other methods ... > } > > IIUC, with your proposal, it becomes > > class C { > private long f; // A handle to some resource needing explicit cleaning. > ... > Foo someMethod(C that) { > try (C me = this; c myThat = that) { > ... access f and that.f, or equivalently me.f and myThat.f ... > } > ... repeat for other methods ... > } > > That's clearly shorter by a constant factor. But to me it doesn't look > consistent with the normal try-with-resources statement. > > My alternative proposal would reduce this to: > > class C { > @Cleaned private long f; // A handle to some resource needing explicit > cleaning. > ... > Foo someMethod(C that) { > ... access f and that.f ... > } > ... Other methods also need no special treatment ... > } > > This has the advantage that the annotation is confined to one place, > arguably where it belongs. The annotation overhead is shorter by a factor > of O(). It doesn't get around the fact that this is > really difficult to explain to a non-compiler-expert in full detail. But I > think it's possible to quickly explain the annotation in a way that will > make sense to most people and will generally lead them to correct code. > > Full disclosure: This remains messy in some cases, notably if you let f > escape from C by handing it to a caller. There's some argument that that > should never happen for a properly designed API. It puts the caller into > the position of explicitly having to reason about object lifetimes. > Unfortunately things like this do seem to be hard to avoid ins some cases. > Even in the messy cases, so far I've almost always found @Cleaned to be > more convenient than explicit reachabilityFences. > From hboehm at google.com Thu Oct 11 23:34:53 2018 From: hboehm at google.com (Hans Boehm) Date: Thu, 11 Oct 2018 16:34:53 -0700 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: <87596f65-79f1-64ac-96f8-8a315ad1f1d0@Oracle.COM> References: <5daeb9a2-0e87-29e6-87e3-fd7a1cda2dba@cs.oswego.edu> <2712E10A-816A-4844-AB13-81A52F3586C1@oracle.com> <87596f65-79f1-64ac-96f8-8a315ad1f1d0@Oracle.COM> Message-ID: On Thu, Oct 11, 2018 at 3:42 PM Peter B. Kessler wrote: > The JavaDoc for `Reference.reachabilityFence(Object ref)` [ > http://hg.openjdk.java.net/jdk/jdk/file/62523934374c/src/java.base/share/classes/java/lang/ref/Reference.java#l509] > says > > @param ref the reference. If {@code null}, this method has no > effect. > > It might be true that if the actual parameter is a constant `null` the > method has no effect. I understand the intent of the method if applied to > a simple variable (e.g., `this`). What is the effect of calling the method > with a complex expression that yields an `Object`? How does the compiler > know which lifetime to extend? When is the actual parameter evaluated? > What if the complex expression yields `null`? Does the method still have > "no effect"? > Peter - Logically, the call to reachabilityFence() needs to be compiled like any other call, with the argument evaluated before the call. The argument needs to look reachable to the garbage collector at the point of the call, as it would for a real call. But the call doesn't actually do anything; it just ensures that the argument is around at that point. But the compiler can't "know" that the call doesn't do anything and the argument is dead; it must be treated as live up to the call, in spite of the fact that it's not used. (The compiler also can't "know" much else about the call, since we don't want it to move the call up past other memory accesses. I gather that for hotspot this isn't much of an issue.) In reality, the fact the the GC only runs at certain points allows this to be relaxed a little. If you pass null, then the target of null needs to be reachable at that point. Which is vacuously true. > The try-with-resource solution also operates on expressions, but there it > is more obvious what to make a strong reference to to keep a particular > Object reachable. > > Hans's `@Cleaned` annotation can only be applied to fields, not > expressions. Does that make it less useful? > The proposal currently defines it in terms of implied reachabilityFences on objects that are dereferenced to get to the annotated field. The simplest implementation is intended to be that we perform no dead reference elimination, i.e. keep all references around to the end of their scope, in methods that access an @Cleaned field. The detailed rules are there to allow implementations to do better. There may be corner cases in which reachabilityFence() is more useful. I'm not proposing to get rid of it. Hans > ... peter > > On 10/11/18 12:56 PM, Hans Boehm wrote: > > On Wed, Oct 10, 2018 at 10:42 PM Erik Osterlund < > erik.osterlund at oracle.com> > > wrote: > >> > >> Hi Hans, > >> > >> Would users be happier if e.g. try with resources could be relied upon > >> having things reachable in a scope for this pattern? > >> > >> try (SlipperyObject x = getSlipperyObject()) { > >> // x is strongly reachable in this scope > >> } > >> // x won?t die until here > >> > >> Seems more intuitive for me to reason about the reachability in a scope > >> than manually analysing the uses of locals. > >> > >> I suppose you would have to implement AutoCloseable to be allowed to use > >> such a construct. But a SlipperyObject class could maybe wrap that and > even > >> call reachability fence in its close method for portability. > >> > >> The trailing close function might already have the same effect as > >> reachabilityFence. > >> > >> Just an idea. > >> > >> Thanks, > >> /Erik > >> > > > > I think the easiest and most common use case is one in which a class C > > includes a field that needs to be explicitly cleaned up when an instance > of > > C is dropped. > > (Unfortunately even libcore contains a bunch of more complicated > patterns, > > but let's ignore those here.) > > > > In that case, the alternatives are basically: > > > > Current: > > > > class C { > > private long f; // A handle to some resource needing explicit > cleaning. > > ... > > Foo someMethod(C that) { > > try { > > ... access f and that.f ... > > } finally { > > reachabilityFence(this); > > reachabilityFence(that); > > } > > ... repeat for other methods ... > > } > > > > IIUC, with your proposal, it becomes > > > > class C { > > private long f; // A handle to some resource needing explicit > cleaning. > > ... > > Foo someMethod(C that) { > > try (C me = this; c myThat = that) { > > ... access f and that.f, or equivalently me.f and myThat.f ... > > } > > ... repeat for other methods ... > > } > > > > That's clearly shorter by a constant factor. But to me it doesn't look > > consistent with the normal try-with-resources statement. > > > > My alternative proposal would reduce this to: > > > > class C { > > @Cleaned private long f; // A handle to some resource needing explicit > > cleaning. > > ... > > Foo someMethod(C that) { > > ... access f and that.f ... > > } > > ... Other methods also need no special treatment ... > > } > > > > This has the advantage that the annotation is confined to one place, > > arguably where it belongs. The annotation overhead is shorter by a factor > > of O(). It doesn't get around the fact that this is > > really difficult to explain to a non-compiler-expert in full detail. But > I > > think it's possible to quickly explain the annotation in a way that will > > make sense to most people and will generally lead them to correct code. > > > > Full disclosure: This remains messy in some cases, notably if you let f > > escape from C by handing it to a caller. There's some argument that that > > should never happen for a properly designed API. It puts the caller into > > the position of explicitly having to reason about object lifetimes. > > Unfortunately things like this do seem to be hard to avoid ins some > cases. > > Even in the messy cases, so far I've almost always found @Cleaned to be > > more convenient than explicit reachabilityFences. > > > > From jan.vomlel at gmail.com Fri Oct 12 09:33:45 2018 From: jan.vomlel at gmail.com (Jan Vomlel) Date: Fri, 12 Oct 2018 11:33:45 +0200 Subject: ImageIO PNG error on java 11 Message-ID: <5d0adc44-6e75-d97d-7ccf-01ffd362adcc@gmail.com> When I try to read some png files, I get exception: ??? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readMetadata(PNGImageReader.java:891) ??? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.getImageMetadata(PNGImageReader.java:1799) ??? Caused by: javax.imageio.IIOException: tEXt chunk length is not proper ??? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.parse_tEXt_chunk(PNGImageReader.java:575) ??? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readMetadata(PNGImageReader.java:847) ??? .. 28 more|| I think there are errors in file PNGImageReader. For example on line 574: ??? if (textLength <= 0) { ??????? throw new IIOException("tEXt chunk length is not proper"); ??? } Right condition is: ??? if (textLength < 0) { ??????? throw new IIOException("tEXt chunk length is not proper"); ??? } Similar problem is on a few other lines. It was caused by commit: http://hg.openjdk.java.net/jdk/jdk/rev/fb62f481671e On java 10 it is working. Bug can be tested on the image: https://user-images.githubusercontent.com/12710508/46531012-fc1c4f80-c89b-11e8-91ec-65a81ae63f0f.png From sean.coffey at oracle.com Fri Oct 12 09:54:36 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 12 Oct 2018 10:54:36 +0100 Subject: ImageIO PNG error on java 11 In-Reply-To: <5d0adc44-6e75-d97d-7ccf-01ffd362adcc@gmail.com> References: <5d0adc44-6e75-d97d-7ccf-01ffd362adcc@gmail.com> Message-ID: Thanks for the report. I see you've already reported this issue via https://bugreport.java.com/bugreport/ Now tracked via https://bugs.openjdk.java.net/browse/JDK-8212116 You can continue the conversation via 2d-dev mailing list, if necessary. Regards, Sean. On 12/10/18 10:33, Jan Vomlel wrote: > When I try to read some png files, I get exception: > > at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readMetadata(PNGImageReader.java:891) > at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.getImageMetadata(PNGImageReader.java:1799) > Caused by: javax.imageio.IIOException: tEXt chunk length is not > proper > at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.parse_tEXt_chunk(PNGImageReader.java:575) > at > java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readMetadata(PNGImageReader.java:847) > .. 28 more|| > > I think there are errors in file PNGImageReader. For example on line 574: > if (textLength <= 0) { > throw new IIOException("tEXt chunk length is not proper"); > } > > Right condition is: > if (textLength < 0) { > throw new IIOException("tEXt chunk length is not proper"); > } > Similar problem is on a few other lines. > > It was caused by commit: > http://hg.openjdk.java.net/jdk/jdk/rev/fb62f481671e > > On java 10 it is working. > > Bug can be tested on the image: > https://user-images.githubusercontent.com/12710508/46531012-fc1c4f80-c89b-11e8-91ec-65a81ae63f0f.png > > > > > > > > > > > > > > From daniel.daugherty at oracle.com Fri Oct 12 16:05:12 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 12 Oct 2018 12:05:12 -0400 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: Vote: yes Dan On 10/9/18 6:37 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more > than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) > From thomas.stuefe at gmail.com Fri Oct 12 16:39:29 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 12 Oct 2018 18:39:29 +0200 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: Vote: yes On Wed, Oct 10, 2018 at 12:38 AM wrote: > > I hereby nominate Gary Adams (gadams) to JDK Committer. > > Gary works for the Oracle Serviceability team and has contributed more > than 35 changes. > His contributions can be found here [3]. > > Votes are due by 16:00 pm PT, October 23, 2018. > > Only current JDK Committers [1] 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]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gary.adams%40oracle.com%22)+or+author(gadams))+and+not+desc(%22Merge%22) From javalists at cbfiddle.com Fri Oct 12 16:47:31 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 12 Oct 2018 09:47:31 -0700 Subject: JDK 11 minimum macOS release In-Reply-To: <1B3FF51F-C662-4247-B93F-E8F40D368FE0@cbfiddle.com> References: <1B3FF51F-C662-4247-B93F-E8F40D368FE0@cbfiddle.com> Message-ID: <2EF41F7D-5863-4ECC-A8CB-2D2264E99741@cbfiddle.com> Let me rephrase the question. Is there any known technical issue regarding JDK 11 running on macOS 10.10? Alan > On Oct 1, 2018, at 1:06 PM, Alan Snyder wrote: > > I notice that the Oracle installation page [1] for JDK 11 says that macOS 10.11 is required. (The OpenJDK release page [2] says nothing.) > > The code itself is built for macOS 10.9. > > Why the difference? > > Alan > > [1] https://docs.oracle.com/en/java/javase/11/install/overview-jdk-installation.html > [2] http://jdk.java.net/11/ > From volker.simonis at gmail.com Fri Oct 12 16:50:14 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 12 Oct 2018 18:50:14 +0200 Subject: Finalizer being run while class still in use (escape analysis bug) In-Reply-To: References: <5daeb9a2-0e87-29e6-87e3-fd7a1cda2dba@cs.oswego.edu> <2712E10A-816A-4844-AB13-81A52F3586C1@oracle.com> <87596f65-79f1-64ac-96f8-8a315ad1f1d0@Oracle.COM> Message-ID: On Fri, Oct 12, 2018 at 11:57 AM Hans Boehm wrote: > > On Thu, Oct 11, 2018 at 3:42 PM Peter B. Kessler > wrote: > > > The JavaDoc for `Reference.reachabilityFence(Object ref)` [ > > http://hg.openjdk.java.net/jdk/jdk/file/62523934374c/src/java.base/share/classes/java/lang/ref/Reference.java#l509] > > says > > > > @param ref the reference. If {@code null}, this method has no > > effect. > > > > It might be true that if the actual parameter is a constant `null` the > > method has no effect. I understand the intent of the method if applied to > > a simple variable (e.g., `this`). What is the effect of calling the method > > with a complex expression that yields an `Object`? How does the compiler > > know which lifetime to extend? When is the actual parameter evaluated? > > What if the complex expression yields `null`? Does the method still have > > "no effect"? Hi Peter, that's an interesting question and when I first read it I was a little confused. However, I think you can easily understand the answer Hans gave below, if you extend the example from the API doc of reachabilityFence as follows: public void action() { Vector v = new Vector(); v.add(this) try { // ... int i = myIndex; Resource.update(externalResourceArray[i]); } finally { Reference.reachabilityFence(v.getFirst()); } } I this case, "v" will be kept alive and not "this" as in the original code. However, the Vector "v" obviously keeps a reference to "this", so "this" will be kept alive and reachable transitively. You can easily extend this to more complex examples. > > > Peter - > > Logically, the call to reachabilityFence() needs to be compiled like any > other call, with the argument evaluated before the call. The argument needs > to look reachable to the garbage collector at the point of the call, as it > would for a real call. But the call doesn't actually do anything; it just > ensures that the argument is around at that point. But the compiler can't > "know" that the call doesn't do anything and the argument is dead; it must > be treated as live up to the call, in spite of the fact that it's not used. > (The compiler also can't "know" much else about the call, since we don't > want it to move the call up past other memory accesses. I gather that for > hotspot this isn't much of an issue.) > > In reality, the fact the the GC only runs at certain points allows this to > be relaxed a little. > > If you pass null, then the target of null needs to be reachable at that > point. Which is vacuously true. > > > > The try-with-resource solution also operates on expressions, but there it > > is more obvious what to make a strong reference to to keep a particular > > Object reachable. > > > > Hans's `@Cleaned` annotation can only be applied to fields, not > > expressions. Does that make it less useful? > > > > The proposal currently defines it in terms of implied reachabilityFences on > objects that are dereferenced to get to the annotated field. The simplest > implementation is intended to be that we perform no dead reference > elimination, i.e. keep all references around to the end of their scope, in > methods that access an @Cleaned field. The detailed rules are there to > allow implementations to do better. > > There may be corner cases in which reachabilityFence() is more useful. I'm > not proposing to get rid of it. > > Hans > > > > ... peter > > > > On 10/11/18 12:56 PM, Hans Boehm wrote: > > > On Wed, Oct 10, 2018 at 10:42 PM Erik Osterlund < > > erik.osterlund at oracle.com> > > > wrote: > > >> > > >> Hi Hans, > > >> > > >> Would users be happier if e.g. try with resources could be relied upon > > >> having things reachable in a scope for this pattern? > > >> > > >> try (SlipperyObject x = getSlipperyObject()) { > > >> // x is strongly reachable in this scope > > >> } > > >> // x won?t die until here > > >> > > >> Seems more intuitive for me to reason about the reachability in a scope > > >> than manually analysing the uses of locals. > > >> > > >> I suppose you would have to implement AutoCloseable to be allowed to use > > >> such a construct. But a SlipperyObject class could maybe wrap that and > > even > > >> call reachability fence in its close method for portability. > > >> > > >> The trailing close function might already have the same effect as > > >> reachabilityFence. > > >> > > >> Just an idea. > > >> > > >> Thanks, > > >> /Erik > > >> > > > > > > I think the easiest and most common use case is one in which a class C > > > includes a field that needs to be explicitly cleaned up when an instance > > of > > > C is dropped. > > > (Unfortunately even libcore contains a bunch of more complicated > > patterns, > > > but let's ignore those here.) > > > > > > In that case, the alternatives are basically: > > > > > > Current: > > > > > > class C { > > > private long f; // A handle to some resource needing explicit > > cleaning. > > > ... > > > Foo someMethod(C that) { > > > try { > > > ... access f and that.f ... > > > } finally { > > > reachabilityFence(this); > > > reachabilityFence(that); > > > } > > > ... repeat for other methods ... > > > } > > > > > > IIUC, with your proposal, it becomes > > > > > > class C { > > > private long f; // A handle to some resource needing explicit > > cleaning. > > > ... > > > Foo someMethod(C that) { > > > try (C me = this; c myThat = that) { > > > ... access f and that.f, or equivalently me.f and myThat.f ... > > > } > > > ... repeat for other methods ... > > > } > > > > > > That's clearly shorter by a constant factor. But to me it doesn't look > > > consistent with the normal try-with-resources statement. > > > > > > My alternative proposal would reduce this to: > > > > > > class C { > > > @Cleaned private long f; // A handle to some resource needing explicit > > > cleaning. > > > ... > > > Foo someMethod(C that) { > > > ... access f and that.f ... > > > } > > > ... Other methods also need no special treatment ... > > > } > > > > > > This has the advantage that the annotation is confined to one place, > > > arguably where it belongs. The annotation overhead is shorter by a factor > > > of O(). It doesn't get around the fact that this is > > > really difficult to explain to a non-compiler-expert in full detail. But > > I > > > think it's possible to quickly explain the annotation in a way that will > > > make sense to most people and will generally lead them to correct code. > > > > > > Full disclosure: This remains messy in some cases, notably if you let f > > > escape from C by handing it to a caller. There's some argument that that > > > should never happen for a properly designed API. It puts the caller into > > > the position of explicitly having to reason about object lifetimes. > > > Unfortunately things like this do seem to be hard to avoid ins some > > cases. > > > Even in the messy cases, so far I've almost always found @Cleaned to be > > > more convenient than explicit reachabilityFences. > > > > > > > From jesper.wilhelmsson at oracle.com Fri Oct 12 18:43:05 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Fri, 12 Oct 2018 20:43:05 +0200 Subject: Result: New JDK Reviewer: Jini George Message-ID: Voting for Jini George [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Thanks, /Jesper [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-September/001978.html From vladimir.x.ivanov at oracle.com Fri Oct 12 19:15:43 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 12 Oct 2018 12:15:43 -0700 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: <483b0476-e315-b9bb-bc4f-88151c6805a8@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 09/10/2018 15:37, serguei.spitsyn at oracle.com wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. From brent.christian at oracle.com Sat Oct 13 00:03:14 2018 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 12 Oct 2018 17:03:14 -0700 Subject: CFV: New JDK Committer: Gary Adams In-Reply-To: References: Message-ID: Vote: yes On 10/9/18 3:37 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Gary Adams (gadams) to JDK Committer. > From sven.reimers at gmail.com Sun Oct 14 19:42:14 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 14 Oct 2018 21:42:14 +0200 Subject: Probable bug within sun.management.StackTraceElementCompositeData Message-ID: Hi all, I hope this is the correct e-mailing list. During out testing of Apache NetBeans 10 we discovered a problem with self sampling capability of NetBeans. Digging further into this problem (NETBEANS-1359 ) I debugged through the code and it seems that there is a problem with the order of the values and the order of the attributes. >From the code I see the order of the values is final Object[] stackTraceElementItemValues = { ste.getClassLoaderName(), ste.getModuleName(), ste.getModuleVersion(), ste.getClassName(), ste.getMethodName(), ste.getFileName(), ste.getLineNumber(), ste.isNativeMethod(), }; compared to the order of the attributes private static final String[] V5_ATTRIBUTES = { CLASS_NAME, METHOD_NAME, FILE_NAME, LINE_NUMBER, NATIVE_METHOD, }; private static final String[] V9_ATTRIBUTES = { CLASS_LOADER_NAME, MODULE_NAME, MODULE_VERSION, }; private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = Stream.of(V5_ATTRIBUTES, V9_ATTRIBUTES).flatMap(Arrays::stream) .toArray(String[]::new); which can be expanded to CLASS_NAME, METHOD_NAME, FILE_NAME, LINE_NUMBER, NATIVE_METHOD, CLASS_LOADER_NAME, MODULE_NAME, MODULE_VERSION, With the difference in ordering you will get an exception in CompositeDataSupport, if you try to convert things (lines 228ff) // Check each value, if not null, is of the open type defined for the // corresponding item for (String name : namesFromType) { Object value = items.get(name); if (value != null) { OpenType itemType = compositeType.getType(name); if (!itemType.isValue(value)) { throw new OpenDataException( "Argument value of wrong type for item " + name + ": value " + value + ", type " + itemType); } } } which is hard to compensate from the caller side. I think the change, which introduced this was https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470 The proposed patch seems simple, just change the ordering of the attributes private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = Stream.of(V9_ATTRIBUTES, V5_ATTRIBUTES).flatMap(Arrays::stream) .toArray(String[]::new); or change the value ordering to fit the attributes order. Can anyone confirm the analysis? Thanks -Sven -- Sven Reimers * Senior Expert Software Architect * Java Champion * Apache NetBeans Committer * * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 From david.holmes at oracle.com Sun Oct 14 22:52:07 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Oct 2018 08:52:07 +1000 Subject: Probable bug within sun.management.StackTraceElementCompositeData In-Reply-To: References: Message-ID: Hi Sven, Moving to serviceability-dev mailing list. Please don't reply to jdk-dev. Thanks, David On 15/10/2018 5:42 AM, Sven Reimers wrote: > Hi all, > > I hope this is the correct e-mailing list. During out testing of Apache > NetBeans 10 we discovered a problem with self sampling capability of > NetBeans. Digging further into this problem (NETBEANS-1359 > ) I debugged through > the code and it seems that there is a problem with the order of the values > and the order of the attributes. > > From the code I see the order of the values is > > final Object[] stackTraceElementItemValues = { > ste.getClassLoaderName(), > ste.getModuleName(), > ste.getModuleVersion(), > ste.getClassName(), > ste.getMethodName(), > ste.getFileName(), > ste.getLineNumber(), > ste.isNativeMethod(), > }; > > compared to the order of the attributes > > > private static final String[] V5_ATTRIBUTES = { > CLASS_NAME, > METHOD_NAME, > FILE_NAME, > LINE_NUMBER, > NATIVE_METHOD, > }; > > private static final String[] V9_ATTRIBUTES = { > CLASS_LOADER_NAME, > MODULE_NAME, > MODULE_VERSION, > }; > > private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = > Stream.of(V5_ATTRIBUTES, V9_ATTRIBUTES).flatMap(Arrays::stream) > .toArray(String[]::new); > > which can be expanded to > > CLASS_NAME, > METHOD_NAME, > FILE_NAME, > LINE_NUMBER, > NATIVE_METHOD, > CLASS_LOADER_NAME, > MODULE_NAME, > MODULE_VERSION, > > With the difference in ordering you will get an exception in > CompositeDataSupport, if you try to convert things (lines 228ff) > > // Check each value, if not null, is of the open type defined for > the > // corresponding item > for (String name : namesFromType) { > Object value = items.get(name); > if (value != null) { > OpenType itemType = compositeType.getType(name); > if (!itemType.isValue(value)) { > throw new OpenDataException( > "Argument value of wrong type for item " + name > + > ": value " + value + ", type " + itemType); > } > } > } > > which is hard to compensate from the caller side. > > I think the change, which introduced this was > > https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470 > > The proposed patch seems simple, just change the ordering of the attributes > > private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = > Stream.of(V9_ATTRIBUTES, V5_ATTRIBUTES).flatMap(Arrays::stream) > .toArray(String[]::new); > > or change the value ordering to fit the attributes order. > > Can anyone confirm the analysis? > > Thanks > > -Sven > From erik.joelsson at oracle.com Mon Oct 15 15:50:27 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 15 Oct 2018 08:50:27 -0700 Subject: JDK 11 minimum macOS release In-Reply-To: <2EF41F7D-5863-4ECC-A8CB-2D2264E99741@cbfiddle.com> References: <1B3FF51F-C662-4247-B93F-E8F40D368FE0@cbfiddle.com> <2EF41F7D-5863-4ECC-A8CB-2D2264E99741@cbfiddle.com> Message-ID: Hello Alan, I do not know of a technical issue. The platforms Oracle list as supported have been tested by Oracle. Given that we set 10.9 as the minimum macosx version in the build, the binaries are likely to work fine on 10.9 and up, but it hasn't actually been tested. /Erik On 2018-10-12 09:47, Alan Snyder wrote: > Let me rephrase the question. > > Is there any known technical issue regarding JDK 11 running on macOS 10.10? > > Alan > > > >> On Oct 1, 2018, at 1:06 PM, Alan Snyder wrote: >> >> I notice that the Oracle installation page [1] for JDK 11 says that macOS 10.11 is required. (The OpenJDK release page [2] says nothing.) >> >> The code itself is built for macOS 10.9. >> >> Why the difference? >> >> Alan >> >> [1] https://docs.oracle.com/en/java/javase/11/install/overview-jdk-installation.html >> [2] http://jdk.java.net/11/ >> From javalists at cbfiddle.com Mon Oct 15 16:16:47 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 15 Oct 2018 09:16:47 -0700 Subject: JDK 11 minimum macOS release In-Reply-To: References: <1B3FF51F-C662-4247-B93F-E8F40D368FE0@cbfiddle.com> <2EF41F7D-5863-4ECC-A8CB-2D2264E99741@cbfiddle.com> Message-ID: <781A9463-CB70-4DE9-963D-58026EA1A08F@cbfiddle.com> Thanks. Would it be appropriate for the OpenJDK release page to say something about the OS releases that are believed to work? I notice the JDK 10 release has such a page: http://jdk.java.net/10/supported Alan > On Oct 15, 2018, at 8:50 AM, Erik Joelsson wrote: > > Hello Alan, > > I do not know of a technical issue. The platforms Oracle list as supported have been tested by Oracle. Given that we set 10.9 as the minimum macosx version in the build, the binaries are likely to work fine on 10.9 and up, but it hasn't actually been tested. > > /Erik > > > On 2018-10-12 09:47, Alan Snyder wrote: >> Let me rephrase the question. >> >> Is there any known technical issue regarding JDK 11 running on macOS 10.10? >> >> Alan >> >> >> >>> On Oct 1, 2018, at 1:06 PM, Alan Snyder wrote: >>> >>> I notice that the Oracle installation page [1] for JDK 11 says that macOS 10.11 is required. (The OpenJDK release page [2] says nothing.) >>> >>> The code itself is built for macOS 10.9. >>> >>> Why the difference? >>> >>> Alan >>> >>> [1] https://docs.oracle.com/en/java/javase/11/install/overview-jdk-installation.html >>> [2] http://jdk.java.net/11/ >>> > From lovejavaee888 at gmail.com Tue Oct 16 13:21:21 2018 From: lovejavaee888 at gmail.com (Soft Jason) Date: Tue, 16 Oct 2018 21:21:21 +0800 Subject: jdk-dev Message-ID: From david.holmes at oracle.com Wed Oct 17 04:14:15 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Oct 2018 14:14:15 +1000 Subject: hg.openjdk.java.net outage Message-ID: The web interface is giving python errors, or else formats the page in a crude low-tech way. The hg interface is giving "abort: HTTP Error 500: Internal Server Error" David From tim.bell at oracle.com Wed Oct 17 06:02:31 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 16 Oct 2018 23:02:31 -0700 Subject: hg.openjdk.java.net outage In-Reply-To: References: Message-ID: <5BC6D077.7020206@oracle.com> On 10/16/18 21:14, David Holmes wrote: > The web interface is giving python errors, or else formats the page in a > crude low-tech way. > > The hg interface is giving "abort: HTTP Error 500: Internal Server Error" I restarted the hgweb.fcgi processes. Both web and hg interfaces are working for me now. Please try them again. Let us know on ops at openjdk.java.net if anything is unexpected. Tim From sgehwolf at redhat.com Wed Oct 17 08:32:02 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 17 Oct 2018 10:32:02 +0200 Subject: http://jdk.java.net/11/ points at wrong hg tag Message-ID: Hi, Going to http://jdk.java.net/11/ reads in the "Notes" section: """ To obtain the source code for these builds, clone the JDK 11.0.1 Mercurial repository and update to the tag jdk-11+28. """ Two issues: 1) "Mercurial repository" is a link pointing to [1]. That was for GA, update builds should point to jdk-updates/jdk11u. 2) "update to the tag jdk-11+28" is wrong. It should be "update to the tag jdk-11.0.1+13" if I'm not mistaken. Thanks, Severin From tim.bell at oracle.com Wed Oct 17 17:10:45 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 17 Oct 2018 10:10:45 -0700 Subject: http://jdk.java.net/11/ points at wrong hg tag In-Reply-To: References: Message-ID: <5BC76D15.9040904@oracle.com> Severin: > Going to http://jdk.java.net/11/ reads in the "Notes" section: Thank you for pointing this out. The link and instructions have been repaired. Tim From claes.redestad at oracle.com Thu Oct 18 21:03:19 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 18 Oct 2018 23:03:19 +0200 Subject: RFR: 8061282: Migrate jmh-jdk-microbenchmarks into the JDK Message-ID: <4d3b9f40-31f2-9d3a-000f-906700055de5@oracle.com> Hi, as the final part of JEP 230: Microbenchmarks Suite, I propose migrating all microbenchmarks from the codetools jmh-jdk-microbenchmarks project into the JDK: http://cr.openjdk.java.net/~redestad/8061282/jdk.00/ This is built on top of the patch for JDK-8061281, and makes the entirety of this suite readily available to build, run and experiment with from the main jdk repos. While the future of the codetools jmh-jdk-microbenchmarks project is out of scope for JEP 230, it has been suggested it could be kept alive as a stabilization target and that stable microbenchmarks should be kept out of the jdk. That discussion is partly out of scope here, but I believe it makes sense to keep a copy in the JDK suite precisely because the benchmark will be compiled with the platform javac, meaning a different set of bugs, regressions and improvements will be discoverable. Two micros, org.openjdk.bench.java.lang.invoke.Indify and org.opendjk.bench.java.lang.reflect.GetAnnotation need special build treatment and will need to be dealt with in a follow-up. Thanks! /Claes From eric.caspole at oracle.com Thu Oct 18 21:14:32 2018 From: eric.caspole at oracle.com (Eric Caspole) Date: Thu, 18 Oct 2018 17:14:32 -0400 Subject: RFR: 8061282: Migrate jmh-jdk-microbenchmarks into the JDK In-Reply-To: <4d3b9f40-31f2-9d3a-000f-906700055de5@oracle.com> References: <4d3b9f40-31f2-9d3a-000f-906700055de5@oracle.com> Message-ID: <325e6311-c6a6-58dc-b9a4-0786fcb52d9d@oracle.com> Looks good! Eric On 10/18/18 17:03, Claes Redestad wrote: > Hi, > > as the final part of JEP 230: Microbenchmarks Suite, I propose migrating > all microbenchmarks from the codetools jmh-jdk-microbenchmarks project > into the JDK: > > http://cr.openjdk.java.net/~redestad/8061282/jdk.00/ > > This is built on top of the patch for JDK-8061281, and makes the > entirety of this suite readily available to build, run and experiment > with from the main jdk repos. > > While the future of the codetools jmh-jdk-microbenchmarks project is out > of scope for JEP 230, it has been suggested it could be kept alive as a > stabilization target and that stable microbenchmarks should be kept out > of the jdk. That discussion is partly out of scope here, but I believe > it makes sense to keep a copy in the JDK suite precisely because the > benchmark will be compiled with the platform javac, meaning a different > set of bugs, regressions and improvements will be discoverable. > > Two micros, org.openjdk.bench.java.lang.invoke.Indify and > org.opendjk.bench.java.lang.reflect.GetAnnotation need special build > treatment and will need to be dealt with in a follow-up. > > Thanks! > > /Claes From bsrbnd at gmail.com Fri Oct 19 15:42:59 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 19 Oct 2018 17:42:59 +0200 Subject: Bit set intrinsic (was: Primitive boolean array packing) In-Reply-To: References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> <62d7984a-78dc-82a4-15aa-6deeebf95342@redhat.com> Message-ID: On Mon, 8 Oct 2018 at 10:53, Andrew Haley wrote: > > On 10/07/2018 08:54 PM, Aleksey Shipilev wrote: > > > Of course, if you do packed boolean[] with locked/CAS-ed writes or > > otherwise guarantee the absence of word tearing, it does not break > > the spec. > > Exactly. it's an interesting idea for large bit vectors, and it could > well generate good code. However, it probably makes more sense to > implement it as a bit vector class with suitable helper intrinsics. So, I turned the existing prototype into a bit set intrinsic (System.setBit()) as I agree with Andrew that it would make more sense than modifying baload/bastore: http://cr.openjdk.java.net/~bsrbnd/boolpack/webrev.01/ The current x86_64 implementation uses BTS/BTR (bit set and reset) instructions as Roman suggested with the LOCK prefix to assure atomicity and thus avoiding any word-tearing problem that Aleksey mentioned. Note that BTS/BTR are locking 32-bit words but AND/OR (8-bit) could be used instead, also in conjunction with LOCK. I tried example [1] with both synchronized BitSet and dedicated intrinsic on x86_64 (8 cores) which revealed that the intrinsic would be at least 2-3x faster than the synchronized set. Then, to the question of how much do we need this, BitSet usages in the JDK is a beginning of answer: $ find ./src/ -name '*.java' -type f -print | xargs grep -e "BitSet" -e "BitArray" There are also other places like javac flags [2] or EnumSet [3] where the same thing is remade by hand. Finally, note that using the intrinsic inside EnumSet would probably make it 2-3x faster than using a SynchronizedCollection [4] in multi-threaded environments. While I agree with Maurizio that Panama structs might be well suited in some situations requiring a rigid layout like javac flags, I think they are only complementary to bit arrays but not a replacement (see EnumSet, etc...). I've seen that Panama is also about exploring hardware optimizations, so maybe the latest intrinsic prototype could be a good starting point for this (hotspot:tier1 being OK)? In any case, feedbacks about this intrinsic would be welcome. Thanks, Bernard [1] https://docs.oracle.com/javase/specs/jls/se11/html/jls-17.html#jls-17.6 [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-September/012504.html [3] http://hg.openjdk.java.net/jdk/jdk/file/cb94f3a51aed/src/java.base/share/classes/java/util/JumboEnumSet.java#l44 [4] http://hg.openjdk.java.net/jdk/jdk/file/cb94f3a51aed/src/java.base/share/classes/java/util/Collections.java#l1998 From Sergey.Bylokhov at oracle.com Fri Oct 19 21:56:20 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 19 Oct 2018 14:56:20 -0700 Subject: CFV: New JDK Committer: Krishna Addepalli Message-ID: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> I hereby nominate Krishna Addepalli to JDK Committer. Krishna is currently a JDK Author and a member of the client team at Oracle. He has made 22 contributions to JDK: http://hg.openjdk.java.net/jdk/client/search/?rev=author(%22kaddepalli%22)&revcount=2000 http://hg.openjdk.java.net/jdk/jdk/log?rev=krishna.addepalli%40oracle.com Votes are due by November 2, 2018. Only current JDK Committers [1] 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]. Sergey Bylokhov [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From philip.race at oracle.com Fri Oct 19 22:58:26 2018 From: philip.race at oracle.com (Philip Race) Date: Fri, 19 Oct 2018 15:58:26 -0700 Subject: CFV: New JDK Committer: Krishna Addepalli In-Reply-To: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> Message-ID: <5BCA6192.80108@oracle.com> Vote: yes. -phil. From bourges.laurent at gmail.com Sat Oct 20 05:58:41 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sat, 20 Oct 2018 07:58:41 +0200 Subject: CFV: New JDK Committer: Krishna Addepalli In-Reply-To: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> Message-ID: Vote: yes. Laurent Le ven. 19 oct. 2018 ? 23:58, Sergey Bylokhov a ?crit : > I hereby nominate Krishna Addepalli to JDK Committer. > > Krishna is currently a JDK Author and a member of the client team at > Oracle. > He has made 22 contributions to JDK: > > http://hg.openjdk.java.net/jdk/client/search/?rev=author(%22kaddepalli%22)&revcount=2000 > http://hg.openjdk.java.net/jdk/jdk/log?rev=krishna.addepalli%40oracle.com > > Votes are due by November 2, 2018. > > Only current JDK Committers [1] 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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From aph at redhat.com Sun Oct 21 09:38:09 2018 From: aph at redhat.com (Andrew Haley) Date: Sun, 21 Oct 2018 10:38:09 +0100 Subject: Bit set intrinsic In-Reply-To: References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> <62d7984a-78dc-82a4-15aa-6deeebf95342@redhat.com> Message-ID: On 10/19/2018 04:42 PM, B. Blaser wrote: > I tried example [1] with both synchronized BitSet and dedicated > intrinsic on x86_64 (8 cores) which revealed that the intrinsic would > be at least 2-3x faster than the synchronized set. Which makes it very useful for things like highly-concurrent Bloom Filters. Here's an example of current usage: https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/BloomFilter.java https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/util/Memory.java If we can provide a really fast on/off-heap bitset in standard Java the need for this Unsafe hackery will go away. It's interesting that the Cassandra Bloom Filter is not thread safe; I don't know why this is. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shashidhara.veerabhadraiah at oracle.com Mon Oct 22 04:28:48 2018 From: shashidhara.veerabhadraiah at oracle.com (Shashidhara Veerabhadraiah) Date: Sun, 21 Oct 2018 21:28:48 -0700 (PDT) Subject: CFV: New JDK Committer: Krishna Addepalli In-Reply-To: References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> Message-ID: <3c7250cb-79fb-4374-9e07-4f4acde6565c@default> Vote: Yes. Thanks and regards, Shashi -----Original Message----- From: Laurent Bourg?s [mailto:bourges.laurent at gmail.com] Sent: Saturday, October 20, 2018 11:29 AM To: Sergey Bylokhov Cc: jdk-dev at openjdk.java.net Subject: Re: CFV: New JDK Committer: Krishna Addepalli Vote: yes. Laurent Le ven. 19 oct. 2018 ? 23:58, Sergey Bylokhov a ?crit : > I hereby nominate Krishna Addepalli to JDK Committer. > > Krishna is currently a JDK Author and a member of the client team at > Oracle. > He has made 22 contributions to JDK: > > http://hg.openjdk.java.net/jdk/client/search/?rev=author(%22kaddepalli > %22)&revcount=2000 > http://hg.openjdk.java.net/jdk/jdk/log?rev=krishna.addepalli%40oracle. > com > > Votes are due by November 2, 2018. > > Only current JDK Committers [1] 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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From jayathirth.d.v at oracle.com Mon Oct 22 04:37:08 2018 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Mon, 22 Oct 2018 10:07:08 +0530 Subject: CFV: New JDK Committer: Krishna Addepalli In-Reply-To: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> Message-ID: Vote : Yes Thanks, Jay > On 20-Oct-2018, at 3:26 AM, Sergey Bylokhov wrote: > > I hereby nominate Krishna Addepalli to JDK Committer. > > Krishna is currently a JDK Author and a member of the client team at Oracle. > He has made 22 contributions to JDK: > http://hg.openjdk.java.net/jdk/client/search/?rev=author(%22kaddepalli%22)&revcount=2000 > http://hg.openjdk.java.net/jdk/jdk/log?rev=krishna.addepalli%40oracle.com > > Votes are due by November 2, 2018. > > Only current JDK Committers [1] 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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From prasanta.sadhukhan at oracle.com Mon Oct 22 05:29:35 2018 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 22 Oct 2018 10:59:35 +0530 Subject: CFV: New JDK Committer: Krishna Addepalli In-Reply-To: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> Message-ID: <20d87d78-0c7c-d00d-3cfe-8e9ef4e6c860@oracle.com> Vote: yes Regards Prasanta On 20-Oct-18 3:26 AM, Sergey Bylokhov wrote: > I hereby nominate Krishna Addepalli to JDK Committer. > > Krishna is currently a JDK Author and a member of the client team at > Oracle. > He has made 22 contributions to JDK: > http://hg.openjdk.java.net/jdk/client/search/?rev=author(%22kaddepalli%22)&revcount=2000 > > http://hg.openjdk.java.net/jdk/jdk/log?rev=krishna.addepalli%40oracle.com > > Votes are due by November 2, 2018. > > Only current JDK Committers [1] 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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From prem.balakrishnan at oracle.com Mon Oct 22 05:47:46 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Sun, 21 Oct 2018 22:47:46 -0700 (PDT) Subject: CFV: New JDK Committer: Krishna Addepalli In-Reply-To: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> Message-ID: <9792db1f-7f0b-4660-aacb-b50b0d4edda7@default> Vote: YES Regards, Prem -----Original Message----- From: Sergey Bylokhov Sent: Saturday, October 20, 2018 3:26 AM To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Committer: Krishna Addepalli I hereby nominate Krishna Addepalli to JDK Committer. Krishna is currently a JDK Author and a member of the client team at Oracle. He has made 22 contributions to JDK: http://hg.openjdk.java.net/jdk/client/search/?rev=author(%22kaddepalli%22)&revcount=2000 http://hg.openjdk.java.net/jdk/jdk/log?rev=krishna.addepalli%40oracle.com Votes are due by November 2, 2018. Only current JDK Committers [1] 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]. Sergey Bylokhov [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From pankaj.b.bansal at oracle.com Mon Oct 22 05:53:15 2018 From: pankaj.b.bansal at oracle.com (Pankaj Bansal) Date: Sun, 21 Oct 2018 22:53:15 -0700 (PDT) Subject: CFV: New JDK Committer: Krishna Addepalli In-Reply-To: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> Message-ID: <4f426dce-d2cf-4b71-a04e-02574047e015@default> Yes Regards, Pankaj -----Original Message----- From: Sergey Bylokhov Sent: Saturday, October 20, 2018 3:26 AM To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Committer: Krishna Addepalli I hereby nominate Krishna Addepalli to JDK Committer. Krishna is currently a JDK Author and a member of the client team at Oracle. He has made 22 contributions to JDK: http://hg.openjdk.java.net/jdk/client/search/?rev=author(%22kaddepalli%22)&revcount=2000 http://hg.openjdk.java.net/jdk/jdk/log?rev=krishna.addepalli%40oracle.com Votes are due by November 2, 2018. Only current JDK Committers [1] 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]. Sergey Bylokhov [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From manajit.halder at oracle.com Mon Oct 22 07:35:36 2018 From: manajit.halder at oracle.com (Manajit Halder) Date: Mon, 22 Oct 2018 13:05:36 +0530 Subject: CFV: New JDK Committer: Krishna Addepalli In-Reply-To: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> Message-ID: <8f230f72-0387-adec-3acd-fdd000dc6373@oracle.com> Vote: Yes Regards, Manajit On 20/10/18 3:26 AM, Sergey Bylokhov wrote: > I hereby nominate Krishna Addepalli to JDK Committer. > > Krishna is currently a JDK Author and a member of the client team at > Oracle. > He has made 22 contributions to JDK: > http://hg.openjdk.java.net/jdk/client/search/?rev=author(%22kaddepalli%22)&revcount=2000 > > http://hg.openjdk.java.net/jdk/jdk/log?rev=krishna.addepalli%40oracle.com > > Votes are due by November 2, 2018. > > Only current JDK Committers [1] 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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From vyom.tewari at oracle.com Mon Oct 22 07:30:34 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Mon, 22 Oct 2018 13:00:34 +0530 Subject: CFV: New JDK Committer: Krishna Addepalli In-Reply-To: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> Message-ID: <4765ac6c-c6e8-5bfd-5c07-368001007e16@oracle.com> Vote: yes Vyom On 20/10/18 3:26 AM, Sergey Bylokhov wrote: > I hereby nominate Krishna Addepalli to JDK Committer. > > Krishna is currently a JDK Author and a member of the client team at > Oracle. > He has made 22 contributions to JDK: > http://hg.openjdk.java.net/jdk/client/search/?rev=author(%22kaddepalli%22)&revcount=2000 > > http://hg.openjdk.java.net/jdk/jdk/log?rev=krishna.addepalli%40oracle.com > > Votes are due by November 2, 2018. > > Only current JDK Committers [1] 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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From bhanu.prakash.gopularam at oracle.com Mon Oct 22 07:52:14 2018 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Mon, 22 Oct 2018 13:22:14 +0530 Subject: CFV: New JDK Committer: Krishna Addepalli In-Reply-To: <4765ac6c-c6e8-5bfd-5c07-368001007e16@oracle.com> References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> <4765ac6c-c6e8-5bfd-5c07-368001007e16@oracle.com> Message-ID: <942329AD-B56E-4348-B71F-72DC3A738C01@oracle.com> Vote: yes Thanks, Bhanu > On 22-Oct-2018, at 1:00 PM, vyom tewari wrote: > > Vote: yes > > Vyom > > On 20/10/18 3:26 AM, Sergey Bylokhov wrote: >> I hereby nominate Krishna Addepalli to JDK Committer. >> >> Krishna is currently a JDK Author and a member of the client team at Oracle. >> He has made 22 contributions to JDK: >> http://hg.openjdk.java.net/jdk/client/search/?rev=author(%22kaddepalli%22)&revcount=2000 >> http://hg.openjdk.java.net/jdk/jdk/log?rev=krishna.addepalli%40oracle.com >> >> Votes are due by November 2, 2018. >> >> Only current JDK Committers [1] 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]. >> >> Sergey Bylokhov >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote From christoph.langer at sap.com Mon Oct 22 08:13:15 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 22 Oct 2018 08:13:15 +0000 Subject: New JDK Committer: Krishna Addepalli In-Reply-To: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> Message-ID: <77dbc86ccc804b2b9258b15571a77ef2@sap.com> Vote: yes Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Sergey > Bylokhov > Sent: Freitag, 19. Oktober 2018 23:56 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Krishna Addepalli > > I hereby nominate Krishna Addepalli to JDK Committer. > > Krishna is currently a JDK Author and a member of the client team at Oracle. > He has made 22 contributions to JDK: > http://hg.openjdk.java.net/jdk/client/search/?rev=author(%22kaddepalli%2 > 2)&revcount=2000 > http://hg.openjdk.java.net/jdk/jdk/log?rev=krishna.addepalli%40oracle.com > > Votes are due by November 2, 2018. > > Only current JDK Committers [1] 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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From stefan.johansson at oracle.com Mon Oct 22 09:09:51 2018 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 22 Oct 2018 11:09:51 +0200 Subject: CFV: New JDK Committer: Leo Korinth Message-ID: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> I hereby nominate Leo Korinth (lkorinth) to JDK Committer. Leo is working in the HotSpot GC team at Oracle and has contributed 18 changes over the last year [3]. Votes are due by 12.00 pm CET, November 5th, 2018. Only current JDK Committers [1] 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]. Thank you, Stefan [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From erik.osterlund at oracle.com Mon Oct 22 09:13:01 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 22 Oct 2018 11:13:01 +0200 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <5BCD949D.9010409@oracle.com> Vote: yes /Erik On 2018-10-22 11:09, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 > changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From claes.redestad at oracle.com Mon Oct 22 09:38:08 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 22 Oct 2018 11:38:08 +0200 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <059d299d-b0ce-e1bd-a933-bae231ef5234@oracle.com> Vote: yes /Claes On 2018-10-22 11:09, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 > changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From thomas.schatzl at oracle.com Mon Oct 22 09:32:32 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 22 Oct 2018 11:32:32 +0200 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <78daacea68b34e6b6cd0d4b5aa4a94f244121ced.camel@oracle.com> Vote: yes On Mon, 2018-10-22 at 11:09 +0200, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed > 18 > changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From robbin.ehn at oracle.com Mon Oct 22 09:41:51 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 22 Oct 2018 11:41:51 +0200 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: Vote: yes /Robbin On 10/22/18 11:09 AM, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 changes > over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From stefan.johansson at oracle.com Mon Oct 22 11:33:31 2018 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 22 Oct 2018 13:33:31 +0200 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <0af29cac-7d9d-17e0-1bad-7cacc278f3e3@oracle.com> Vote: yes On 2018-10-22 11:09, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 > changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From bsrbnd at gmail.com Mon Oct 22 11:56:02 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 22 Oct 2018 13:56:02 +0200 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: Vote: yes Regards, Bernard On Mon, 22 Oct 2018 at 11:13, Stefan Johansson wrote: > > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 > changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From robin.westberg at oracle.com Mon Oct 22 13:33:42 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Mon, 22 Oct 2018 15:33:42 +0200 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: Vote: yes Best regards, Robin > On 22 Oct 2018, at 11:09, Stefan Johansson wrote: > > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From sangheon.kim at oracle.com Mon Oct 22 13:45:56 2018 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Mon, 22 Oct 2018 06:45:56 -0700 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: Vote: yes Thanks, Sangheon On 10/22/18 2:09 AM, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 > changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From patric.hedlin at oracle.com Mon Oct 22 13:57:54 2018 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Mon, 22 Oct 2018 15:57:54 +0200 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <5BCD949D.9010409@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> <5BCD949D.9010409@oracle.com> Message-ID: <9dffc9e8-be48-2a0d-6c94-cf5a8b4c1cfc@oracle.com> Vote: yes /Patric On 10/22/2018 11:13 AM, Erik ?sterlund wrote: > Vote: yes > > /Erik > > On 2018-10-22 11:09, Stefan Johansson wrote: >> I hereby nominate Leo Korinth (lkorinth) to JDK Committer. >> >> Leo is working in the HotSpot GC team at Oracle and has contributed >> 18 changes over the last year [3]. >> >> Votes are due by 12.00 pm CET, November 5th, 2018. >> >> Only current JDK Committers [1] 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]. >> >> Thank you, >> Stefan >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 > From tobias.hartmann at oracle.com Mon Oct 22 14:16:45 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 22 Oct 2018 16:16:45 +0200 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: Vote: yes On 22.10.18 11:09, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From coleen.phillimore at oracle.com Mon Oct 22 14:34:36 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 22 Oct 2018 10:34:36 -0400 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: Vote: yes On 10/22/18 5:09 AM, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 > changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From jesper.wilhelmsson at oracle.com Mon Oct 22 15:12:00 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Mon, 22 Oct 2018 08:12:00 -0700 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: Vote: Yes /Jesper > On 22 Oct 2018, at 02:09, Stefan Johansson wrote: > > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From erik.joelsson at oracle.com Mon Oct 22 17:05:18 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 22 Oct 2018 10:05:18 -0700 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <3d0017ef-95a1-2a50-e943-33c0a152d84c@oracle.com> Vote: yes On 2018-10-22 02:09, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 > changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From vladimir.x.ivanov at oracle.com Mon Oct 22 21:01:40 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 22 Oct 2018 14:01:40 -0700 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <75a00f8a-475e-8d7b-1073-32c0d80e91ad@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 22/10/2018 02:09, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. From serguei.spitsyn at oracle.com Mon Oct 22 23:16:36 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Oct 2018 16:16:36 -0700 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <2db84091-1b30-3139-bf8c-edfdd6877798@oracle.com> Vote: yes From igor.ignatyev at oracle.com Tue Oct 23 00:03:44 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 22 Oct 2018 17:03:44 -0700 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <4563EE6D-A5A3-4962-82A5-FD693343C2D8@oracle.com> Vote: yes -- Igor > On Oct 22, 2018, at 2:09 AM, Stefan Johansson wrote: > > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. From jcbeyler at google.com Tue Oct 23 02:39:08 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 22 Oct 2018 19:39:08 -0700 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <4563EE6D-A5A3-4962-82A5-FD693343C2D8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> <4563EE6D-A5A3-4962-82A5-FD693343C2D8@oracle.com> Message-ID: Vote: yes On Mon, Oct 22, 2018 at 5:04 PM Igor Ignatyev wrote: > Vote: yes > > -- Igor > > > On Oct 22, 2018, at 2:09 AM, Stefan Johansson < > stefan.johansson at oracle.com> wrote: > > > > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > -- Thanks, Jc From dmitry.markov at oracle.com Tue Oct 23 11:39:56 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Tue, 23 Oct 2018 12:39:56 +0100 Subject: CFV: New JDK Committer: Krishna Addepalli In-Reply-To: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> Message-ID: <98679BD6-1C95-4378-8E98-8E900D9392B8@oracle.com> Vote: yes. Thanks, Dmitry > On 19 Oct 2018, at 22:56, Sergey Bylokhov wrote: > > I hereby nominate Krishna Addepalli to JDK Committer. > > Krishna is currently a JDK Author and a member of the client team at Oracle. > He has made 22 contributions to JDK: > http://hg.openjdk.java.net/jdk/client/search/?rev=author(%22kaddepalli%22)&revcount=2000 > http://hg.openjdk.java.net/jdk/jdk/log?rev=krishna.addepalli%40oracle.com > > Votes are due by November 2, 2018. > > Only current JDK Committers [1] 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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From Roger.Riggs at oracle.com Tue Oct 23 20:32:04 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 23 Oct 2018 16:32:04 -0400 Subject: CFV: New JDK Committer: Krishna Addepalli In-Reply-To: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> Message-ID: Vote: Yes On 10/19/2018 05:56 PM, Sergey Bylokhov wrote: > I hereby nominate Krishna Addepalli to JDK Committer. From Roger.Riggs at oracle.com Tue Oct 23 20:34:56 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 23 Oct 2018 16:34:56 -0400 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <16d3e899-8b7b-d721-b2dc-ed895b84a3ff@oracle.com> Vote: yes On 10/22/2018 05:09 AM, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. From jiangli.zhou at oracle.com Wed Oct 24 00:09:18 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 23 Oct 2018 17:09:18 -0700 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <788186CB-2719-401A-9803-397467E06885@oracle.com> Vote: yes Thanks, Jiangli > On Oct 22, 2018, at 2:09 AM, Stefan Johansson wrote: > > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From serguei.spitsyn at oracle.com Wed Oct 24 04:18:09 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Oct 2018 21:18:09 -0700 Subject: Result: New JDK Committer: Gary Adams In-Reply-To: <5af67146-91d7-5b5d-bad5-4fc42561b7c9@oracle.com> References: <5af67146-91d7-5b5d-bad5-4fc42561b7c9@oracle.com> Message-ID: Voting for Gary Adams [1] is now closed. Yes: 25 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Serguei Spitsyn [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-October/002053.html From kim.barrett at oracle.com Wed Oct 24 14:19:01 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 24 Oct 2018 10:19:01 -0400 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <8134592F-B2CB-4850-8C52-30E2BF6AE7CD@oracle.com> vote: yes > On Oct 22, 2018, at 5:09 AM, Stefan Johansson wrote: > > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From erik.helin at oracle.com Wed Oct 24 16:19:21 2018 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 24 Oct 2018 09:19:21 -0700 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <7a39c218-14e8-f85a-2e72-040a1ddcac6e@oracle.com> Vote: yes Thanks, Erik On 10/22/2018 02:09 AM, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 > changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From robert at liguorisoftware.com Fri Oct 26 16:39:19 2018 From: robert at liguorisoftware.com (robert at liguorisoftware.com) Date: Fri, 26 Oct 2018 09:39:19 -0700 Subject: JMathConstant submission for upcoming JDK Message-ID: Hi Chris, I wrote this simple utility class you may want to use in an upcoming version of the JDK. Btw, I'm the author of the Java Pocket Guide. :) Or is there a better place I can submit simple code like this for the JDK? Thanks, Robert import java.math.BigDecimal; public class JMathConstant { private JMathConstant() { } // ZERO, 1/2 AND ONE public static final BigDecimal ZERO = new BigDecimal("0.0"); public static final BigDecimal LANDAUS = new BigDecimal("0.5"); public static final BigDecimal ONE = new BigDecimal("1.0"); public static final BigDecimal LEGENDRE = new BigDecimal("1.0"); // SILVER AND GOLD public static final BigDecimal ARCHIMEDES_RATIO = new BigDecimal("3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001927876611 1959092164201989"); public static final BigDecimal UNKNOWN_NAME = new BigDecimal("2.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001927876611 1959092164201989"); public static final BigDecimal SILVER_RATIO = new BigDecimal("2.4142135623730950488"); public static final BigDecimal PYTHAGORAS = new BigDecimal("1.4142135623730950488"); public static final BigDecimal GOLDEN_RATIO = new BigDecimal("1.61803398874989484820458683436563811772030917980576286213544862270526046281890"); public static final BigDecimal INVERSE_GOLDEN_RATIO = new BigDecimal("0.61803398874989484820458683436563811772030917980576286213544862270526046281890"); // ADDITIONAL RATIO CONSTANTS public static final BigDecimal FEIGENBAUMS_RATIO_1 = new BigDecimal("4.66920160910299067185320382046620161"); public static final BigDecimal FEIGENBAUMS_RATIO_2 = new BigDecimal("2.50290787509589282228390287321821578"); // OTHERS public static final BigDecimal MEISSEL_MERTENS = new BigDecimal("0.26149721284764278375542683860869585"); public static final BigDecimal BERNSTEINS = new BigDecimal("0.28016949902386913303"); public static final BigDecimal GAUSS_KKUZMIN_WIRSING = new BigDecimal("0.30366300289873265859744812190155623"); public static final BigDecimal HAFNER_SARNAK_MCCURLEY = new BigDecimal("0.35323637185499598454351655043268201"); public static final BigDecimal OMEGA = new BigDecimal("0.56714329040978387299996866221035555"); public static final BigDecimal EULER_MASCHERONI = new BigDecimal("0.57721"); public static final BigDecimal GOLOMB_DICKMAN = new BigDecimal("0.6243299885435508709929363831083724"); public static final BigDecimal CAHEN = new BigDecimal("0.6434105463"); public static final BigDecimal TWO_PRIME = new BigDecimal("0.6601618158468695739281211001455577"); public static final BigDecimal LAPLANE_LIMIT = new BigDecimal("0.66274341934918158097474209710925290"); public static final BigDecimal EMBREE_TREFETHEN = new BigDecimal("0.70258"); public static final BigDecimal LANDAU_RAMANUJAN = new BigDecimal("0.76422365358922066299069873125009232"); public static final BigDecimal ALLADI_GRINSTEAD = new BigDecimal("0.8093940205"); public static final BigDecimal BRUN = new BigDecimal("0.8705883800"); public static final BigDecimal CATALANS = new BigDecimal("0.91596559417721901505460351493238411"); public static final BigDecimal LENGYELS = new BigDecimal("1.0986858055"); public static final BigDecimal VISWANATHS = new BigDecimal("1.13198824"); public static final BigDecimal APERYS = new BigDecimal("1.20205690315959428539973816151144999"); public static final BigDecimal GLAISHER_KINKELIN = new BigDecimal("1.2824271291"); public static final BigDecimal CONWAYS = new BigDecimal("1.30357726903429639125709911215255189"); public static final BigDecimal MILLS = new BigDecimal("1.30637788386308069046861449260260571"); public static final BigDecimal PLASTIC = new BigDecimal("1.32471795724474602596090885447809734"); public static final BigDecimal RAMANUJAN_SOLDNER = new BigDecimal("1.45136923488338105028396848589202744"); public static final BigDecimal PORTERS = new BigDecimal("1.4670780794"); public static final BigDecimal BACKHOUSE = new BigDecimal("1.45607494858268967139959535111654356"); public static final BigDecimal LIEBS_SQUARE_ICE = new BigDecimal("1.5396007178"); public static final BigDecimal ERDOS_BORWEIN = new BigDecimal("1.60669515241529176378330152319092458"); public static final BigDecimal NIVENS = new BigDecimal("1.70521114010536776428855145343450816"); public static final BigDecimal THEODORUS = new BigDecimal("1.73205080756887729352744634150587236"); public static final BigDecimal BRUNS = new BigDecimal("1.9021605823"); public static final BigDecimal UNIVERSAL_PARABOLIC = new BigDecimal("2.29558714939263807403429804918949039"); public static final BigDecimal SIERPINSKI = new BigDecimal("2.58498175957925321706589358738317116"); public static final BigDecimal KHINCHIN = new BigDecimal("2.68545200106530644530971483548179569"); public static final BigDecimal NAPIERS = new BigDecimal("2.7182818284590452353602874713527"); public static final BigDecimal FRANSEN_ROBINSON = new BigDecimal("2.80777024202851936522150118655777293"); public static final BigDecimal LEVYS = new BigDecimal("3.27582291872181115978768188245384386"); public static final BigDecimal RECIPROCAL_FIBONACCI = new BigDecimal("3.35988566624317755317201130291892717"); public static final BigDecimal GRAVITY = new BigDecimal("32.17404856"); // ft/sec^2 public static final BigDecimal NEAR_ONE = new BigDecimal("0.999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999"); public static final BigDecimal DIVIDE_BY_998001 = new BigDecimal("0.000001002003004005006007008009010011012013014015016017018019020021022023024025026027028029030031032033034035036037038039040041042043044045046047048049050051052053054055056057058059060061062063064065066067068069070071072073074075076077078079080081082083084085086087088089090091092093094095096097098099100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327 32832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966 06616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929 93994995996997999"); // ALTERNATE NAMES public static final BigDecimal PI = ARCHIMEDES_RATIO; public static void main(String[] args) { System.out.println("MEISSEL_MERTENS CONSTANT: " + MEISSEL_MERTENS); } } Robert From hohensee at amazon.com Fri Oct 26 17:49:31 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 26 Oct 2018 17:49:31 +0000 Subject: JMathConstant submission for upcoming JDK In-Reply-To: References: Message-ID: <45477CFC-5C52-4EE1-9807-CD203A410D25@amazon.com> This would go to core-libs-dev, and would be a spec change since it adds a class. The concept could be expanded to BigInteger, Long, Integer, etc. Instead of adding a class, one could add these constants directly to BigDecimal (and the others), but that would also be a spec change since it adds public members. You should file a JBS bug. If you don't have access to JBS, I'd be happy to file it for you. Thanks, Paul ?On 10/26/18, 9:41 AM, "jdk-dev on behalf of robert at liguorisoftware.com" wrote: Hi Chris, I wrote this simple utility class you may want to use in an upcoming version of the JDK. Btw, I'm the author of the Java Pocket Guide. :) Or is there a better place I can submit simple code like this for the JDK? Thanks, Robert import java.math.BigDecimal; public class JMathConstant { private JMathConstant() { } // ZERO, 1/2 AND ONE public static final BigDecimal ZERO = new BigDecimal("0.0"); public static final BigDecimal LANDAUS = new BigDecimal("0.5"); public static final BigDecimal ONE = new BigDecimal("1.0"); public static final BigDecimal LEGENDRE = new BigDecimal("1.0"); // SILVER AND GOLD public static final BigDecimal ARCHIMEDES_RATIO = new BigDecimal("3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019 27876611 1959092164201989"); public static final BigDecimal UNKNOWN_NAME = new BigDecimal("2.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019 27876611 1959092164201989"); public static final BigDecimal SILVER_RATIO = new BigDecimal("2.4142135623730950488"); public static final BigDecimal PYTHAGORAS = new BigDecimal("1.4142135623730950488"); public static final BigDecimal GOLDEN_RATIO = new BigDecimal("1.61803398874989484820458683436563811772030917980576286213544862270526046281890"); public static final BigDecimal INVERSE_GOLDEN_RATIO = new BigDecimal("0.61803398874989484820458683436563811772030917980576286213544862270526046281890"); // ADDITIONAL RATIO CONSTANTS public static final BigDecimal FEIGENBAUMS_RATIO_1 = new BigDecimal("4.66920160910299067185320382046620161"); public static final BigDecimal FEIGENBAUMS_RATIO_2 = new BigDecimal("2.50290787509589282228390287321821578"); // OTHERS public static final BigDecimal MEISSEL_MERTENS = new BigDecimal("0.26149721284764278375542683860869585"); public static final BigDecimal BERNSTEINS = new BigDecimal("0.28016949902386913303"); public static final BigDecimal GAUSS_KKUZMIN_WIRSING = new BigDecimal("0.30366300289873265859744812190155623"); public static final BigDecimal HAFNER_SARNAK_MCCURLEY = new BigDecimal("0.35323637185499598454351655043268201"); public static final BigDecimal OMEGA = new BigDecimal("0.56714329040978387299996866221035555"); public static final BigDecimal EULER_MASCHERONI = new BigDecimal("0.57721"); public static final BigDecimal GOLOMB_DICKMAN = new BigDecimal("0.6243299885435508709929363831083724"); public static final BigDecimal CAHEN = new BigDecimal("0.6434105463"); public static final BigDecimal TWO_PRIME = new BigDecimal("0.6601618158468695739281211001455577"); public static final BigDecimal LAPLANE_LIMIT = new BigDecimal("0.66274341934918158097474209710925290"); public static final BigDecimal EMBREE_TREFETHEN = new BigDecimal("0.70258"); public static final BigDecimal LANDAU_RAMANUJAN = new BigDecimal("0.76422365358922066299069873125009232"); public static final BigDecimal ALLADI_GRINSTEAD = new BigDecimal("0.8093940205"); public static final BigDecimal BRUN = new BigDecimal("0.8705883800"); public static final BigDecimal CATALANS = new BigDecimal("0.91596559417721901505460351493238411"); public static final BigDecimal LENGYELS = new BigDecimal("1.0986858055"); public static final BigDecimal VISWANATHS = new BigDecimal("1.13198824"); public static final BigDecimal APERYS = new BigDecimal("1.20205690315959428539973816151144999"); public static final BigDecimal GLAISHER_KINKELIN = new BigDecimal("1.2824271291"); public static final BigDecimal CONWAYS = new BigDecimal("1.30357726903429639125709911215255189"); public static final BigDecimal MILLS = new BigDecimal("1.30637788386308069046861449260260571"); public static final BigDecimal PLASTIC = new BigDecimal("1.32471795724474602596090885447809734"); public static final BigDecimal RAMANUJAN_SOLDNER = new BigDecimal("1.45136923488338105028396848589202744"); public static final BigDecimal PORTERS = new BigDecimal("1.4670780794"); public static final BigDecimal BACKHOUSE = new BigDecimal("1.45607494858268967139959535111654356"); public static final BigDecimal LIEBS_SQUARE_ICE = new BigDecimal("1.5396007178"); public static final BigDecimal ERDOS_BORWEIN = new BigDecimal("1.60669515241529176378330152319092458"); public static final BigDecimal NIVENS = new BigDecimal("1.70521114010536776428855145343450816"); public static final BigDecimal THEODORUS = new BigDecimal("1.73205080756887729352744634150587236"); public static final BigDecimal BRUNS = new BigDecimal("1.9021605823"); public static final BigDecimal UNIVERSAL_PARABOLIC = new BigDecimal("2.29558714939263807403429804918949039"); public static final BigDecimal SIERPINSKI = new BigDecimal("2.58498175957925321706589358738317116"); public static final BigDecimal KHINCHIN = new BigDecimal("2.68545200106530644530971483548179569"); public static final BigDecimal NAPIERS = new BigDecimal("2.7182818284590452353602874713527"); public static final BigDecimal FRANSEN_ROBINSON = new BigDecimal("2.80777024202851936522150118655777293"); public static final BigDecimal LEVYS = new BigDecimal("3.27582291872181115978768188245384386"); public static final BigDecimal RECIPROCAL_FIBONACCI = new BigDecimal("3.35988566624317755317201130291892717"); public static final BigDecimal GRAVITY = new BigDecimal("32.17404856"); // ft/sec^2 public static final BigDecimal NEAR_ONE = new BigDecimal("0.9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999"); public static final BigDecimal DIVIDE_BY_998001 = new BigDecimal("0.0000010020030040050060070080090100110120130140150160170180190200210220230240250260270280290300310320330340350360370380390400410420430440450460470480490500510520530540550560570580590600610620630640650660670680690700710720730740750760770780790800810820830840850860870880890900910920930940950960970980991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243 25326327 328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657 65865966 066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999 09919929 93994995996997999"); // ALTERNATE NAMES public static final BigDecimal PI = ARCHIMEDES_RATIO; public static void main(String[] args) { System.out.println("MEISSEL_MERTENS CONSTANT: " + MEISSEL_MERTENS); } } Robert From robert at liguorisoftware.com Fri Oct 26 17:58:47 2018 From: robert at liguorisoftware.com (robert at liguorisoftware.com) Date: Fri, 26 Oct 2018 10:58:47 -0700 Subject: JMathConstant submission for upcoming JDK In-Reply-To: <45477CFC-5C52-4EE1-9807-CD203A410D25@amazon.com> References: <45477CFC-5C52-4EE1-9807-CD203A410D25@amazon.com> Message-ID: <1e6d8a95fd20bd9a93a1a7d16b7ca6bb@liguorisoftware.com> Please file it as you have suggestion, along with your suggestions for improvement. Sincerely, Robert Liguori From roshanmangal at gmail.com Sat Oct 27 10:08:41 2018 From: roshanmangal at gmail.com (roshan mangal) Date: Sat, 27 Oct 2018 15:38:41 +0530 Subject: Request for addition of properties for HashMap's Load Factor Message-ID: Hi All, HashMap's performance significantly depends on Load Factor. A lower value of Load Factor will increase the table size but will reduce collision and boost performance. It would be helpful if we can have "LoadFactor" as a tunable based on application usage. Currently, only two options are available for setting of Load Factor's value. 1. Use the default value of Load Factor i.e. 0.75 or, 2. Use application provided value, which is used during HashMap's object creation in the constructor. Application user has no option to change it to get a better-optimized value as per usage. I am proposing an additional option, which is java property(-D) driven LoadFactor for three classes listed below 1. src/java.base/share/classes/java/util/HashMap.java 2. src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java 3. src/java.base/share/classes/java/util/WeakHashMap.java note: If other classes need Load Factor java property, we can add there also. I have tuned Load Factor for Specjbb2015 and got 1% to 2% improvement on the multi-JVM max-JOPS score at loadfactor=0.6. Please find a patch for load factor properties addition in jdk12 below. Usage: -Djava.util.HashMap.loadfactor=< value between 0 to 1 > -Djava.util.concurrent.ConcurrentHashMap.loadfactor=< value between 0 to 1 > -Djava.util.WeakHashMap.loadfactor=< value between 0 to 1 > ############################# PATCH ################################## diff -r 2e495bbdc2b7 src/java.base/share/classes/java/util/HashMap.java --- a/src/java.base/share/classes/java/util/HashMap.java Mon Oct 22 14:03:06 2018 +0800 +++ b/src/java.base/share/classes/java/util/HashMap.java Sat Oct 27 20:31:19 2018 +0530 @@ -35,7 +35,7 @@ import java.util.function.Consumer; import java.util.function.Function; import jdk.internal.misc.SharedSecrets; +import sun.security.action.GetPropertyAction; /** * Hash table based implementation of the {@code Map} interface. This * implementation provides all of the optional map operations, and permits @@ -243,9 +243,9 @@ static final int MAXIMUM_CAPACITY = 1 << 30; /** - * The load factor used when none specified in constructor. + * The load factor used when none specified in constructor or property. */ - static final float DEFAULT_LOAD_FACTOR = 0.75f; + static float DEFAULT_LOAD_FACTOR = 0.75f; /** * The bin count threshold for using a tree rather than list for a @@ -426,7 +426,7 @@ * * @serial */ - final float loadFactor; + float loadFactor; /* ---------------- Public operations -------------- */ @@ -461,6 +461,16 @@ */ public HashMap(int initialCapacity) { this(initialCapacity, DEFAULT_LOAD_FACTOR); + + Properties props = GetPropertyAction.privilegedGetProperties(); + if( props != null ) { + String loadfactor = + props.getProperty("java.util.HashMap.loadfactor"); + float LOAD_FACTOR = ( loadfactor == null || loadfactor.isEmpty() ) ? DEFAULT_LOAD_FACTOR : Float.parseFloat(loadfactor); + DEFAULT_LOAD_FACTOR = ( LOAD_FACTOR < 0 || LOAD_FACTOR > 1.0 ) ? DEFAULT_LOAD_FACTOR : LOAD_FACTOR ; + } + this.loadFactor = DEFAULT_LOAD_FACTOR; + } /** @@ -468,7 +478,17 @@ * (16) and the default load factor (0.75). */ public HashMap() { + this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted + + Properties props = GetPropertyAction.privilegedGetProperties(); + if( props != null ) { + String loadfactor = + props.getProperty("java.util.HashMap.loadfactor"); + float LOAD_FACTOR = ( loadfactor == null || loadfactor.isEmpty() ) ? DEFAULT_LOAD_FACTOR : Float.parseFloat(loadfactor); + DEFAULT_LOAD_FACTOR = ( LOAD_FACTOR < 0 || LOAD_FACTOR > 1.0 ) ? DEFAULT_LOAD_FACTOR : LOAD_FACTOR ; + } + this.loadFactor = DEFAULT_LOAD_FACTOR; } /** @@ -481,6 +501,14 @@ * @throws NullPointerException if the specified map is null */ public HashMap(Map m) { + Properties props = GetPropertyAction.privilegedGetProperties(); + if( props != null ) { + String loadfactor = + props.getProperty("java.util.HashMap.loadfactor"); + float LOAD_FACTOR = ( loadfactor == null || loadfactor.isEmpty() ) ? DEFAULT_LOAD_FACTOR : Float.parseFloat(loadfactor); + DEFAULT_LOAD_FACTOR = ( LOAD_FACTOR < 0 || LOAD_FACTOR > 1.0 ) ? DEFAULT_LOAD_FACTOR : LOAD_FACTOR ; + } + this.loadFactor = DEFAULT_LOAD_FACTOR; putMapEntries(m, false); } diff -r 2e495bbdc2b7 src/java.base/share/classes/java/util/WeakHashMap.java --- a/src/java.base/share/classes/java/util/WeakHashMap.java Mon Oct 22 14:03:06 2018 +0800 +++ b/src/java.base/share/classes/java/util/WeakHashMap.java Sat Oct 27 20:31:19 2018 +0530 @@ -31,7 +31,7 @@ import java.util.function.BiConsumer; import java.util.function.BiFunction; import java.util.function.Consumer; +import sun.security.action.GetPropertyAction; /** * Hash table based implementation of the {@code Map} interface, with @@ -152,7 +152,19 @@ /** * The load factor used when none specified in constructor. */ - private static final float DEFAULT_LOAD_FACTOR = 0.75f; + private static float DEFAULT_LOAD_FACTOR = 0.75f; + + static { + Properties props = GetPropertyAction.privilegedGetProperties(); + if( props != null ){ + final String loadfactor = + props.getProperty("java.util.WeakHashMap.loadfactor"); + + float LOAD_FACTOR = ( loadfactor == null || loadfactor.isEmpty() ) ? DEFAULT_LOAD_FACTOR : Float.parseFloat(loadfactor); + DEFAULT_LOAD_FACTOR = ( LOAD_FACTOR < 0 || LOAD_FACTOR > 1.0 ) ? DEFAULT_LOAD_FACTOR : LOAD_FACTOR ; + } + + } /** * The table, resized as necessary. Length MUST Always be a power of two. diff -r 2e495bbdc2b7 src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java --- a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java Mon Oct 22 14:03:06 2018 +0800 +++ b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java Sat Oct 27 20:31:19 2018 +0530 @@ -69,7 +69,8 @@ import java.util.function.ToLongFunction; import java.util.stream.Stream; import jdk.internal.misc.Unsafe; +import sun.security.action.GetPropertyAction; +import java.util.Properties; /** * A hash table supporting full concurrency of retrievals and * high expected concurrency for updates. This class obeys the @@ -532,7 +533,7 @@ * simpler to use expressions such as {@code n - (n >>> 2)} for * the associated resizing threshold. */ - private static final float LOAD_FACTOR = 0.75f; + private static float LOAD_FACTOR = 0.75f; /** * The bin count threshold for using a tree rather than list for a @@ -891,6 +892,15 @@ */ public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) { + Properties props = GetPropertyAction.privilegedGetProperties(); + if( props != null ) { + final String loadfactor_str = + props.getProperty("java.util.concurrent.ConcurrentHashMap.loadfactor"); + float PROP_LOAD_FACTOR = ( loadfactor_str == null || loadfactor_str.isEmpty() ) ? LOAD_FACTOR : Float.parseFloat(loadfactor_str); + LOAD_FACTOR = ( PROP_LOAD_FACTOR < 0 || PROP_LOAD_FACTOR > 1.0 ) ? LOAD_FACTOR : PROP_LOAD_FACTOR ; + // Modify if property is set + loadFactor = ( loadfactor_str == null || loadfactor_str.isEmpty() ) ? loadFactor : LOAD_FACTOR; + } if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0) throw new IllegalArgumentException(); if (initialCapacity < concurrencyLevel) // Use at least as many bins ###################################################################### Thanks, Roshan Mangal From bourges.laurent at gmail.com Sun Oct 28 08:41:30 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sun, 28 Oct 2018 09:41:30 +0100 Subject: Hg web down Message-ID: Hi, http://hg.openjdk.java.net/jdk is broken: Python 2.6.8: /oj/bin/python Sun Oct 28 08:40:22 2018 A problem occurred in a Python script. Here is the sequence of function calls leading up to the error, in the order they occurred. /usr/lib/python2.6/site-packages/flup-1.0.3.dev_20110405-py2.6.egg/flup/server/fcgi_base.py in run(self=) 572 573 try: 574 protocolStatus, appStatus = self.server.handler(self) 575 except: 576 traceback.print_exc(file=self.stderr) protocolStatus undefined, appStatus undefined, self = , self.server = , self.server.handler = > /usr/lib/python2.6/site-packages/flup-1.0.3.dev_20110405-py2.6.egg/flup/server/fcgi_base.py in handler(self=, req=) 1159 result = self.application(environ, start_response) 1160 try: 1161 for data in result: 1162 if data: 1163 write(data) Thanks in advance, Laurent From claes.redestad at oracle.com Sun Oct 28 14:06:34 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 28 Oct 2018 15:06:34 +0100 Subject: Request for addition of properties for HashMap's Load Factor In-Reply-To: References: Message-ID: Hi, I'd prefer something like this to change the value of the constants rather than add a property lookup in a lot of constructors, which might cause regressions in some applications. There might be upcoming ways to initialize such read-only properties before we load in System.getProperties (and thus CHM) so we can retain the finality of the load factor constants. One could also easily imagine a jlink plugin that allows you to customize the constants: this would allow you to tune for your deployments centrally without having to sprinkle -Dproperties everywhere. /Claes On 2018-10-27 12:08, roshan mangal wrote: > Hi All, > > HashMap's performance significantly depends on Load Factor. A lower value > of Load Factor will increase the table size but will reduce collision and > boost performance. > It would be helpful if we can have "LoadFactor" as a tunable based on > application usage. > > Currently, only two options are available for setting of Load Factor's > value. > > 1. Use the default value of Load Factor i.e. 0.75 or, > 2. Use application provided value, which is used during HashMap's object > creation in the constructor. > > Application user has no option to change it to get a better-optimized value > as per usage. > > I am proposing an additional option, which is java property(-D) driven > LoadFactor for three classes listed below > > 1. src/java.base/share/classes/java/util/HashMap.java > 2. src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java > 3. src/java.base/share/classes/java/util/WeakHashMap.java > note: If other classes need Load Factor java property, we can add there > also. > > I have tuned Load Factor for Specjbb2015 and got 1% to 2% improvement on > the multi-JVM max-JOPS score at loadfactor=0.6. > > Please find a patch for load factor properties addition in jdk12 below. > Usage: > -Djava.util.HashMap.loadfactor=< value between 0 to 1 > > -Djava.util.concurrent.ConcurrentHashMap.loadfactor=< value between 0 to 1 >> -Djava.util.WeakHashMap.loadfactor=< value between 0 to 1 > > ############################# PATCH ################################## > diff -r 2e495bbdc2b7 src/java.base/share/classes/java/util/HashMap.java > --- a/src/java.base/share/classes/java/util/HashMap.java Mon Oct 22 > 14:03:06 2018 +0800 > +++ b/src/java.base/share/classes/java/util/HashMap.java Sat Oct 27 > 20:31:19 2018 +0530 > @@ -35,7 +35,7 @@ > import java.util.function.Consumer; > import java.util.function.Function; > import jdk.internal.misc.SharedSecrets; > +import sun.security.action.GetPropertyAction; > /** > * Hash table based implementation of the {@code Map} interface. This > * implementation provides all of the optional map operations, and permits > @@ -243,9 +243,9 @@ > static final int MAXIMUM_CAPACITY = 1 << 30; > > /** > - * The load factor used when none specified in constructor. > + * The load factor used when none specified in constructor or property. > */ > - static final float DEFAULT_LOAD_FACTOR = 0.75f; > + static float DEFAULT_LOAD_FACTOR = 0.75f; > > /** > * The bin count threshold for using a tree rather than list for a > @@ -426,7 +426,7 @@ > * > * @serial > */ > - final float loadFactor; > + float loadFactor; > > /* ---------------- Public operations -------------- */ > > @@ -461,6 +461,16 @@ > */ > public HashMap(int initialCapacity) { > this(initialCapacity, DEFAULT_LOAD_FACTOR); > + > + Properties props = GetPropertyAction.privilegedGetProperties(); > + if( props != null ) { > + String loadfactor = > + props.getProperty("java.util.HashMap.loadfactor"); > + float LOAD_FACTOR = ( loadfactor == null || loadfactor.isEmpty() > ) ? DEFAULT_LOAD_FACTOR : Float.parseFloat(loadfactor); > + DEFAULT_LOAD_FACTOR = ( LOAD_FACTOR < 0 || LOAD_FACTOR > 1.0 ) ? > DEFAULT_LOAD_FACTOR : LOAD_FACTOR ; > + } > + this.loadFactor = DEFAULT_LOAD_FACTOR; > + > } > > /** > @@ -468,7 +478,17 @@ > * (16) and the default load factor (0.75). > */ > public HashMap() { > + > this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields > defaulted > + > + Properties props = GetPropertyAction.privilegedGetProperties(); > + if( props != null ) { > + String loadfactor = > + props.getProperty("java.util.HashMap.loadfactor"); > + float LOAD_FACTOR = ( loadfactor == null || loadfactor.isEmpty() > ) ? DEFAULT_LOAD_FACTOR : Float.parseFloat(loadfactor); > + DEFAULT_LOAD_FACTOR = ( LOAD_FACTOR < 0 || LOAD_FACTOR > 1.0 ) ? > DEFAULT_LOAD_FACTOR : LOAD_FACTOR ; > + } > + this.loadFactor = DEFAULT_LOAD_FACTOR; > } > > /** > @@ -481,6 +501,14 @@ > * @throws NullPointerException if the specified map is null > */ > public HashMap(Map m) { > + Properties props = GetPropertyAction.privilegedGetProperties(); > + if( props != null ) { > + String loadfactor = > + props.getProperty("java.util.HashMap.loadfactor"); > + float LOAD_FACTOR = ( loadfactor == null || loadfactor.isEmpty() > ) ? DEFAULT_LOAD_FACTOR : Float.parseFloat(loadfactor); > + DEFAULT_LOAD_FACTOR = ( LOAD_FACTOR < 0 || LOAD_FACTOR > 1.0 ) ? > DEFAULT_LOAD_FACTOR : LOAD_FACTOR ; > + } > + > this.loadFactor = DEFAULT_LOAD_FACTOR; > putMapEntries(m, false); > } > diff -r 2e495bbdc2b7 src/java.base/share/classes/java/util/WeakHashMap.java > --- a/src/java.base/share/classes/java/util/WeakHashMap.java Mon Oct 22 > 14:03:06 2018 +0800 > +++ b/src/java.base/share/classes/java/util/WeakHashMap.java Sat Oct 27 > 20:31:19 2018 +0530 > @@ -31,7 +31,7 @@ > import java.util.function.BiConsumer; > import java.util.function.BiFunction; > import java.util.function.Consumer; > +import sun.security.action.GetPropertyAction; > > /** > * Hash table based implementation of the {@code Map} interface, with > @@ -152,7 +152,19 @@ > /** > * The load factor used when none specified in constructor. > */ > - private static final float DEFAULT_LOAD_FACTOR = 0.75f; > + private static float DEFAULT_LOAD_FACTOR = 0.75f; > + > + static { > + Properties props = GetPropertyAction.privilegedGetProperties(); > + if( props != null ){ > + final String loadfactor = > + props.getProperty("java.util.WeakHashMap.loadfactor"); > + > + float LOAD_FACTOR = ( loadfactor == null || loadfactor.isEmpty() ) > ? DEFAULT_LOAD_FACTOR : Float.parseFloat(loadfactor); > + DEFAULT_LOAD_FACTOR = ( LOAD_FACTOR < 0 || LOAD_FACTOR > 1.0 ) ? > DEFAULT_LOAD_FACTOR : LOAD_FACTOR ; > + } > + > + } > > /** > * The table, resized as necessary. Length MUST Always be a power of > two. > diff -r 2e495bbdc2b7 > src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java > --- > a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java > Mon Oct 22 14:03:06 2018 +0800 > +++ > b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java > Sat Oct 27 20:31:19 2018 +0530 > @@ -69,7 +69,8 @@ > import java.util.function.ToLongFunction; > import java.util.stream.Stream; > import jdk.internal.misc.Unsafe; > +import sun.security.action.GetPropertyAction; > +import java.util.Properties; > /** > * A hash table supporting full concurrency of retrievals and > * high expected concurrency for updates. This class obeys the > @@ -532,7 +533,7 @@ > * simpler to use expressions such as {@code n - (n >>> 2)} for > * the associated resizing threshold. > */ > - private static final float LOAD_FACTOR = 0.75f; > + private static float LOAD_FACTOR = 0.75f; > > /** > * The bin count threshold for using a tree rather than list for a > @@ -891,6 +892,15 @@ > */ > public ConcurrentHashMap(int initialCapacity, > float loadFactor, int concurrencyLevel) { > + Properties props = GetPropertyAction.privilegedGetProperties(); > + if( props != null ) { > + final String loadfactor_str = > + > props.getProperty("java.util.concurrent.ConcurrentHashMap.loadfactor"); > + float PROP_LOAD_FACTOR = ( loadfactor_str == null || > loadfactor_str.isEmpty() ) ? LOAD_FACTOR : Float.parseFloat(loadfactor_str); > + LOAD_FACTOR = ( PROP_LOAD_FACTOR < 0 || PROP_LOAD_FACTOR > 1.0 ) ? > LOAD_FACTOR : PROP_LOAD_FACTOR ; > + // Modify if property is set > + loadFactor = ( loadfactor_str == null || loadfactor_str.isEmpty() > ) ? loadFactor : LOAD_FACTOR; > + } > if (!(loadFactor > 0.0f) || initialCapacity < 0 || > concurrencyLevel <= 0) > throw new IllegalArgumentException(); > if (initialCapacity < concurrencyLevel) // Use at least as many > bins > > ###################################################################### > > Thanks, > Roshan Mangal From per.liden at oracle.com Sun Oct 28 16:13:15 2018 From: per.liden at oracle.com (Per Liden) Date: Sun, 28 Oct 2018 17:13:15 +0100 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <23e75ee9-bbde-9e45-96c8-1d6a507311ab@oracle.com> Vote: yes /Per On 2018-10-22 11:09, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 > changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From martinrb at google.com Sun Oct 28 20:34:56 2018 From: martinrb at google.com (Martin Buchholz) Date: Sun, 28 Oct 2018 13:34:56 -0700 Subject: Request for addition of properties for HashMap's Load Factor In-Reply-To: References: Message-ID: Adding the proposed system properties is probably not going to happen - getting good results on specjbb is not the only goal. I agree with Claes that adding machinery to make it easier to create a modified JDK is a good direction. If nothing else, it's open source and you can build your own JDK with local mods. On Sun, Oct 28, 2018 at 7:06 AM, Claes Redestad wrote: > Hi, > > I'd prefer something like this to change the value of the constants rather > than > add a property lookup in a lot of constructors, which might cause > regressions in some > applications. > > There might be upcoming ways to initialize such read-only properties > before we load in > System.getProperties (and thus CHM) so we can retain the finality of the > load factor > constants. > > One could also easily imagine a jlink plugin that allows you to customize > the constants: > this would allow you to tune for your deployments centrally without having > to sprinkle > -Dproperties everywhere. > > /Claes > > > On 2018-10-27 12:08, roshan mangal wrote: > >> Hi All, >> >> HashMap's performance significantly depends on Load Factor. A lower value >> of Load Factor will increase the table size but will reduce collision and >> boost performance. >> It would be helpful if we can have "LoadFactor" as a tunable based on >> application usage. >> >> Currently, only two options are available for setting of Load Factor's >> value. >> >> 1. Use the default value of Load Factor i.e. 0.75 or, >> 2. Use application provided value, which is used during HashMap's object >> creation in the constructor. >> >> Application user has no option to change it to get a better-optimized >> value >> as per usage. >> >> I am proposing an additional option, which is java property(-D) driven >> LoadFactor for three classes listed below >> >> 1. src/java.base/share/classes/java/util/HashMap.java >> 2. src/java.base/share/classes/java/util/concurrent/ConcurrentH >> ashMap.java >> 3. src/java.base/share/classes/java/util/WeakHashMap.java >> note: If other classes need Load Factor java property, we can add there >> also. >> >> I have tuned Load Factor for Specjbb2015 and got 1% to 2% improvement on >> the multi-JVM max-JOPS score at loadfactor=0.6. >> >> Please find a patch for load factor properties addition in jdk12 below. >> Usage: >> -Djava.util.HashMap.loadfactor=< value between 0 to 1 > >> -Djava.util.concurrent.ConcurrentHashMap.loadfactor=< value between 0 to >> 1 >> >>> -Djava.util.WeakHashMap.loadfactor=< value between 0 to 1 > >>> >> ############################# PATCH ################################## >> diff -r 2e495bbdc2b7 src/java.base/share/classes/java/util/HashMap.java >> --- a/src/java.base/share/classes/java/util/HashMap.java Mon Oct 22 >> 14:03:06 2018 +0800 >> +++ b/src/java.base/share/classes/java/util/HashMap.java Sat Oct 27 >> 20:31:19 2018 +0530 >> @@ -35,7 +35,7 @@ >> import java.util.function.Consumer; >> import java.util.function.Function; >> import jdk.internal.misc.SharedSecrets; >> +import sun.security.action.GetPropertyAction; >> /** >> * Hash table based implementation of the {@code Map} interface. This >> * implementation provides all of the optional map operations, and >> permits >> @@ -243,9 +243,9 @@ >> static final int MAXIMUM_CAPACITY = 1 << 30; >> >> /** >> - * The load factor used when none specified in constructor. >> + * The load factor used when none specified in constructor or >> property. >> */ >> - static final float DEFAULT_LOAD_FACTOR = 0.75f; >> + static float DEFAULT_LOAD_FACTOR = 0.75f; >> >> /** >> * The bin count threshold for using a tree rather than list for a >> @@ -426,7 +426,7 @@ >> * >> * @serial >> */ >> - final float loadFactor; >> + float loadFactor; >> >> /* ---------------- Public operations -------------- */ >> >> @@ -461,6 +461,16 @@ >> */ >> public HashMap(int initialCapacity) { >> this(initialCapacity, DEFAULT_LOAD_FACTOR); >> + >> + Properties props = GetPropertyAction.privilegedGetProperties(); >> + if( props != null ) { >> + String loadfactor = >> + props.getProperty("java.util.HashMap.loadfactor"); >> + float LOAD_FACTOR = ( loadfactor == null || >> loadfactor.isEmpty() >> ) ? DEFAULT_LOAD_FACTOR : Float.parseFloat(loadfactor); >> + DEFAULT_LOAD_FACTOR = ( LOAD_FACTOR < 0 || LOAD_FACTOR > 1.0 ) >> ? >> DEFAULT_LOAD_FACTOR : LOAD_FACTOR ; >> + } >> + this.loadFactor = DEFAULT_LOAD_FACTOR; >> + >> } >> >> /** >> @@ -468,7 +478,17 @@ >> * (16) and the default load factor (0.75). >> */ >> public HashMap() { >> + >> this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields >> defaulted >> + >> + Properties props = GetPropertyAction.privilegedGetProperties(); >> + if( props != null ) { >> + String loadfactor = >> + props.getProperty("java.util.HashMap.loadfactor"); >> + float LOAD_FACTOR = ( loadfactor == null || >> loadfactor.isEmpty() >> ) ? DEFAULT_LOAD_FACTOR : Float.parseFloat(loadfactor); >> + DEFAULT_LOAD_FACTOR = ( LOAD_FACTOR < 0 || LOAD_FACTOR > 1.0 ) >> ? >> DEFAULT_LOAD_FACTOR : LOAD_FACTOR ; >> + } >> + this.loadFactor = DEFAULT_LOAD_FACTOR; >> } >> >> /** >> @@ -481,6 +501,14 @@ >> * @throws NullPointerException if the specified map is null >> */ >> public HashMap(Map m) { >> + Properties props = GetPropertyAction.privilegedGetProperties(); >> + if( props != null ) { >> + String loadfactor = >> + props.getProperty("java.util.HashMap.loadfactor"); >> + float LOAD_FACTOR = ( loadfactor == null || loadfactor.isEmpty() >> ) ? DEFAULT_LOAD_FACTOR : Float.parseFloat(loadfactor); >> + DEFAULT_LOAD_FACTOR = ( LOAD_FACTOR < 0 || LOAD_FACTOR > 1.0 ) ? >> DEFAULT_LOAD_FACTOR : LOAD_FACTOR ; >> + } >> + >> this.loadFactor = DEFAULT_LOAD_FACTOR; >> putMapEntries(m, false); >> } >> diff -r 2e495bbdc2b7 src/java.base/share/classes/ja >> va/util/WeakHashMap.java >> --- a/src/java.base/share/classes/java/util/WeakHashMap.java Mon Oct 22 >> 14:03:06 2018 +0800 >> +++ b/src/java.base/share/classes/java/util/WeakHashMap.java Sat Oct 27 >> 20:31:19 2018 +0530 >> @@ -31,7 +31,7 @@ >> import java.util.function.BiConsumer; >> import java.util.function.BiFunction; >> import java.util.function.Consumer; >> +import sun.security.action.GetPropertyAction; >> >> /** >> * Hash table based implementation of the {@code Map} interface, with >> @@ -152,7 +152,19 @@ >> /** >> * The load factor used when none specified in constructor. >> */ >> - private static final float DEFAULT_LOAD_FACTOR = 0.75f; >> + private static float DEFAULT_LOAD_FACTOR = 0.75f; >> + >> + static { >> + Properties props = GetPropertyAction.privilegedGetProperties(); >> + if( props != null ){ >> + final String loadfactor = >> + props.getProperty("java.util.WeakHashMap.loadfactor"); >> + >> + float LOAD_FACTOR = ( loadfactor == null || loadfactor.isEmpty() >> ) >> ? DEFAULT_LOAD_FACTOR : Float.parseFloat(loadfactor); >> + DEFAULT_LOAD_FACTOR = ( LOAD_FACTOR < 0 || LOAD_FACTOR > 1.0 ) ? >> DEFAULT_LOAD_FACTOR : LOAD_FACTOR ; >> + } >> + >> + } >> >> /** >> * The table, resized as necessary. Length MUST Always be a power of >> two. >> diff -r 2e495bbdc2b7 >> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java >> --- >> a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java >> Mon Oct 22 14:03:06 2018 +0800 >> +++ >> b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java >> Sat Oct 27 20:31:19 2018 +0530 >> @@ -69,7 +69,8 @@ >> import java.util.function.ToLongFunction; >> import java.util.stream.Stream; >> import jdk.internal.misc.Unsafe; >> +import sun.security.action.GetPropertyAction; >> +import java.util.Properties; >> /** >> * A hash table supporting full concurrency of retrievals and >> * high expected concurrency for updates. This class obeys the >> @@ -532,7 +533,7 @@ >> * simpler to use expressions such as {@code n - (n >>> 2)} for >> * the associated resizing threshold. >> */ >> - private static final float LOAD_FACTOR = 0.75f; >> + private static float LOAD_FACTOR = 0.75f; >> >> /** >> * The bin count threshold for using a tree rather than list for a >> @@ -891,6 +892,15 @@ >> */ >> public ConcurrentHashMap(int initialCapacity, >> float loadFactor, int concurrencyLevel) { >> + Properties props = GetPropertyAction.privilegedGetProperties(); >> + if( props != null ) { >> + final String loadfactor_str = >> + >> props.getProperty("java.util.concurrent.ConcurrentHashMap.loadfactor"); >> + float PROP_LOAD_FACTOR = ( loadfactor_str == null || >> loadfactor_str.isEmpty() ) ? LOAD_FACTOR : Float.parseFloat(loadfactor_st >> r); >> + LOAD_FACTOR = ( PROP_LOAD_FACTOR < 0 || PROP_LOAD_FACTOR > 1.0 ) >> ? >> LOAD_FACTOR : PROP_LOAD_FACTOR ; >> + // Modify if property is set >> + loadFactor = ( loadfactor_str == null || loadfactor_str.isEmpty() >> ) ? loadFactor : LOAD_FACTOR; >> + } >> if (!(loadFactor > 0.0f) || initialCapacity < 0 || >> concurrencyLevel <= 0) >> throw new IllegalArgumentException(); >> if (initialCapacity < concurrencyLevel) // Use at least as >> many >> bins >> >> ###################################################################### >> >> Thanks, >> Roshan Mangal >> > > From tim.bell at oracle.com Mon Oct 29 02:44:41 2018 From: tim.bell at oracle.com (Tim Bell) Date: Sun, 28 Oct 2018 19:44:41 -0700 Subject: Hg web down In-Reply-To: References: Message-ID: <5BD67419.8020005@oracle.com> On 10/28/18 01:41, Laurent Bourg?s wrote: > http://hg.openjdk.java.net/jdk is broken: Web access is restored. I am still looking for the root cause. Thanks- Tim From magnus.ihse.bursie at oracle.com Mon Oct 29 08:13:18 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 29 Oct 2018 09:13:18 +0100 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: Vote: yes /Magnus On 2018-10-22 11:09, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 > changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From ajit.ghaisas at oracle.com Mon Oct 29 08:37:54 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Mon, 29 Oct 2018 14:07:54 +0530 Subject: CFV: New JDK Committer: Krishna Addepalli In-Reply-To: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> References: <6d6b4f43-8a12-e014-94dc-e6d785c3ec79@oracle.com> Message-ID: <9963783C-EAB4-4B35-9BE3-E813CC69F15C@oracle.com> Vote : Yes Regards, Ajit > On 20-Oct-2018, at 3:26 AM, Sergey Bylokhov wrote: > > I hereby nominate Krishna Addepalli to JDK Committer. > > Krishna is currently a JDK Author and a member of the client team at Oracle. > He has made 22 contributions to JDK: > http://hg.openjdk.java.net/jdk/client/search/?rev=author(%22kaddepalli%22)&revcount=2000 > http://hg.openjdk.java.net/jdk/jdk/log?rev=krishna.addepalli%40oracle.com > > Votes are due by November 2, 2018. > > Only current JDK Committers [1] 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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From nils.eliasson at oracle.com Mon Oct 29 08:44:25 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 29 Oct 2018 09:44:25 +0100 Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: Vote: yes // Nils On 2018-10-22 11:09, Stefan Johansson wrote: > I hereby nominate Leo Korinth (lkorinth) to JDK Committer. > > Leo is working in the HotSpot GC team at Oracle and has contributed 18 > changes over the last year [3]. > > Votes are due by 12.00 pm CET, November 5th, 2018. > > Only current JDK Committers [1] 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]. > > Thank you, > Stefan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From markus.gronlund at oracle.com Tue Oct 30 13:11:41 2018 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 30 Oct 2018 06:11:41 -0700 (PDT) Subject: CFV: New JDK Committer: Leo Korinth In-Reply-To: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> References: <2d0d49ad-8609-e1b7-eee5-819fba3a9dc8@oracle.com> Message-ID: <5428cd5e-b668-477d-9896-0b563bf4073d@default> Vote: yes Thanks Markus -----Original Message----- From: Stefan Johansson Sent: den 22 oktober 2018 11:10 To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Committer: Leo Korinth I hereby nominate Leo Korinth (lkorinth) to JDK Committer. Leo is working in the HotSpot GC team at Oracle and has contributed 18 changes over the last year [3]. Votes are due by 12.00 pm CET, November 5th, 2018. Only current JDK Committers [1] 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]. Thank you, Stefan [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=korinth&revcount=20 From bsrbnd at gmail.com Wed Oct 31 14:51:34 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Wed, 31 Oct 2018 15:51:34 +0100 Subject: Bit set intrinsic In-Reply-To: References: <9891ee55-7114-5b71-7a90-0c4e97deda2a@redhat.com> <05e00e85-046a-cdcb-7323-9e40f8a8fc86@redhat.com> <62d7984a-78dc-82a4-15aa-6deeebf95342@redhat.com> Message-ID: On Sun, 21 Oct 2018 at 11:38, Andrew Haley wrote: > > On 10/19/2018 04:42 PM, B. Blaser wrote: > > I tried example [1] with both synchronized BitSet and dedicated > > intrinsic on x86_64 (8 cores) which revealed that the intrinsic would > > be at least 2-3x faster than the synchronized set. > > Which makes it very useful for things like highly-concurrent Bloom > Filters. Here's an example of current usage: > > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/BloomFilter.java > > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/util/Memory.java > > If we can provide a really fast on/off-heap bitset in standard Java > the need for this Unsafe hackery will go away. > > It's interesting that the Cassandra Bloom Filter is not thread safe; I > don't know why this is. The last but not least, I implemented the c2 part (using the 8-bit AND/OR variant) to do sharper comparisons also on non-concurrent execution: http://cr.openjdk.java.net/~bsrbnd/boolpack/webrev.02/ With 10e6 iterations the lock latency seems to be more or less negligible and removing it would make the intrinsic about 10% faster than BitSet without synchronization. I used it naively inside RegularEnumSet without optimization nor atomicity guarantee only to evaluate its robustness and tier1 was successful. I'm not sure what would be the process for adding something like this to the JDK (maybe a JEP would be necessary?) but I cannot implement the intrinsic on other architectures myself. Also, I guess a more precise API specification along with advanced profiling would be necessary but I'm probably not an expert in these areas... In any case, I hope these experiments will be useful for something. Please let me know of any feedback, Bernard