From zgu at redhat.com Fri Sep 1 12:09:38 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 1 Sep 2017 08:09:38 -0400 Subject: RFR: Avoid evacuating filler objects in Shenandoah In-Reply-To: <49c17767-409b-d5b0-4324-1dcdbd233849@redhat.com> References: <956a87fe-bb2c-18af-f6f4-b436f5b063b0@redhat.com> <0fd195e1-f57a-7a6b-ed12-f13a4abc6256@redhat.com> <49c17767-409b-d5b0-4324-1dcdbd233849@redhat.com> Message-ID: <53ac79d1-2eea-0f57-670d-995680f0e810@redhat.com> specJVM run on to-gc1 (http://to-gc1.usersys.redhat.com:8080/job/zgu-specjvm-jdk10/1/console) has confirmed that evacuating fillers are rare cases, and not worth the effort. Please be aware, evacuation totals are in KB while filler sizes are in bytes. Thanks, -Zhengyu On 08/31/2017 08:14 AM, Zhengyu Gu wrote: > I did some performance runs late last night, it showed regression. > > Apparently, oop->is_filler() was not cheap, especially testing on marked > oops, which is not necessary. > > I refactored these code paths: > http://cr.openjdk.java.net/~zgu/shenandoah/sh_filler/webrev.01/index.html > > It still failed to show improvement on evacuation time. I suspect we > over estimated the number of fillers over TAMS. > > Therefore, I would like to withdraw this change and re-exam the > assumption is correct. > > Thanks, > > -Zhengyu > > > > On 08/31/2017 05:20 AM, Aleksey Shipilev wrote: >> On 08/30/2017 10:55 PM, Zhengyu Gu wrote: >>> Webrev: >>> http://cr.openjdk.java.net/~zgu/shenandoah/sh_filler/webrev.00/index.html >>> >> >> We need to do performance study for this first: checking the is_filler >> flag on marked_object_iterate >> path should be offset by the performance improvements. I did my >> initial experiments with -Xint to >> only care about native paths. Also, the initial estimate of 5-10% was >> gathered during full heap scan >> during verification. It may be the case that evacuation does not >> encounter filler objects all that much. >> >> Suggestion: revert marked_object_iterate, put p->is_filler() checks on >> interesting paths in e.g. >> evacuation and see if we indeed take that shortcut. Then, make >> CollectedHeap::fill_with_array inject >> fillers with either intArray or fillerArray, based on UseNewCode flag, >> and compare runtime performance. >> >> Thanks, >> -Aleksey >> From shade at redhat.com Fri Sep 1 12:11:01 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 Sep 2017 14:11:01 +0200 Subject: RFR: Avoid evacuating filler objects in Shenandoah In-Reply-To: <53ac79d1-2eea-0f57-670d-995680f0e810@redhat.com> References: <956a87fe-bb2c-18af-f6f4-b436f5b063b0@redhat.com> <0fd195e1-f57a-7a6b-ed12-f13a4abc6256@redhat.com> <49c17767-409b-d5b0-4324-1dcdbd233849@redhat.com> <53ac79d1-2eea-0f57-670d-995680f0e810@redhat.com> Message-ID: <36a668a2-8fb1-21a0-f086-5b7e9a164f8a@redhat.com> On 09/01/2017 02:09 PM, Zhengyu Gu wrote: > specJVM run on to-gc1 (http://to-gc1.usersys.redhat.com:8080/job/zgu-specjvm-jdk10/1/console) has > confirmed that evacuating fillers are rare cases, and not worth the effort. Okay then, false alarm. Thanks for trying this out! -Aleksey From pbeaman at onshape.com Sun Sep 3 21:07:19 2017 From: pbeaman at onshape.com (Peter Beaman) Date: Sun, 3 Sep 2017 17:07:19 -0400 Subject: Crash in openjdk8 while using ShenandoahGC Message-ID: Our Java application running on an AWS r3.xlarge instance under Ubuntu 14.04 crashed with the following after about 12 hours of fairly CPU- and GC-intense processing: # Internal Error (safepoint.cpp:314), pid=3384, tid=0x00007f7448f77700 # guarantee(PageArmed == 0) failed: invariant # # JRE version: OpenJDK Runtime Environment (8.0_141) (build 1.8.0_141-internal-15) # Java VM: OpenJDK 64-Bit Server VM (25.141-b15 mixed mode linux-amd64 compressed oops) The complete hs_err and gc.log files are available if useful. Unfortunately the machine was not equipped with enough storage to hold a crashdump file. I have not yet reproduced this, so do not yet know how easy or hard that may be. The JVM was built from source at tag jdk8u141-b15, JVM flags from gc.log: OpenJDK 64-Bit Server VM (25.141-b15) for linux-amd64 JRE (1.8.0_141-internal-15), built on Aug 30 2017 20:07:13 by "pbeaman" with gcc 4.8.4 Memory: 4k page, physical 31399920k(29785452k free), swap 0k(0k free) CommandLine flags: -XX:InitialHeapSize=22506635264 -XX:MaxHeapSize=22506635264 -XX:MaxMetaspaceSize=201326592 -XX:NumberOfGCLogFiles=10 -XX:-OmitStackTraceInFastThrow -XX:OnOutOfMemoryError=touch /opt/bti/OUT_OF_MEMORY -XX:+PrintAdaptiveSizePolicy -XX:+PrintGC -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:-UseGCLogFileRotation -XX:+UseShenandoahGC -XX:+UseStringDeduplication We are testing Shenandoah as a possible cure for long Full GC stop times in G1. Please let me know if there's a preferred channel for filing Shenandoah bugs. Thanks, Peter Beaman Onshape From rkennke at redhat.com Mon Sep 4 09:22:50 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 Sep 2017 11:22:50 +0200 Subject: Crash in openjdk8 while using ShenandoahGC In-Reply-To: References: Message-ID: <4947234f-522f-9531-0dc2-5282afb0cbad@redhat.com> Hi Peter, Thank you for testing Shenandoah and reporting this bug. Yes, the hs_err and gc log files would be very useful. Please upload it somewhere and post a link, if possible. Yes, for now, this is the preferred channel for filing Shenandoah bugs ;-) Best regards, Roman > Our Java application running on an AWS r3.xlarge instance under Ubuntu > 14.04 crashed with the following after about 12 hours of fairly CPU- and > GC-intense processing: > > # Internal Error (safepoint.cpp:314), pid=3384, tid=0x00007f7448f77700 > # guarantee(PageArmed == 0) failed: invariant > # > # JRE version: OpenJDK Runtime Environment (8.0_141) (build > 1.8.0_141-internal-15) > # Java VM: OpenJDK 64-Bit Server VM (25.141-b15 mixed mode linux-amd64 > compressed oops) > > The complete hs_err and gc.log files are available if useful. Unfortunately > the machine was not equipped with enough storage to hold a crashdump file. > I have not yet reproduced this, so do not yet know how easy or hard that > may be. > > The JVM was built from source at tag jdk8u141-b15, > > JVM flags from gc.log: > > OpenJDK 64-Bit Server VM (25.141-b15) for linux-amd64 JRE > (1.8.0_141-internal-15), built on Aug 30 2017 20:07:13 by "pbeaman" with > gcc 4.8.4 > Memory: 4k page, physical 31399920k(29785452k free), swap 0k(0k free) > CommandLine flags: -XX:InitialHeapSize=22506635264 > -XX:MaxHeapSize=22506635264 -XX:MaxMetaspaceSize=201326592 > -XX:NumberOfGCLogFiles=10 -XX:-OmitStackTraceInFastThrow > -XX:OnOutOfMemoryError=touch /opt/bti/OUT_OF_MEMORY > -XX:+PrintAdaptiveSizePolicy -XX:+PrintGC > -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps > -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution > -XX:+UseCompressedClassPointers -XX:+UseCompressedOops > -XX:-UseGCLogFileRotation -XX:+UseShenandoahGC -XX:+UseStringDeduplication > > We are testing Shenandoah as a possible cure for long Full GC stop times in > G1. > > Please let me know if there's a preferred channel for filing Shenandoah > bugs. From shade at redhat.com Mon Sep 4 09:37:13 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Sep 2017 11:37:13 +0200 Subject: Crash in openjdk8 while using ShenandoahGC In-Reply-To: References: Message-ID: On 09/03/2017 11:07 PM, Peter Beaman wrote: > Our Java application running on an AWS r3.xlarge instance under Ubuntu > 14.04 crashed with the following after about 12 hours of fairly CPU- and > GC-intense processing: > > # Internal Error (safepoint.cpp:314), pid=3384, tid=0x00007f7448f77700 > # guarantee(PageArmed == 0) failed: invariant Looking around OpenJDK bugtracker, I think this usually indicates the failure to reach safepoint due to a stall in some threads. The workaround most reports are suggesting is -XX:+UseCountedLoopsSafepoints, but Shenandoah should enable it implicitly in 8u. hs_err would probably tell a more complete story. > The JVM was built from source at tag jdk8u141-b15, Would you mind trying to build off our shenandoah/jdk8u tip? http://hg.openjdk.java.net/shenandoah/jdk8u/ -Aleksey From rkennke at redhat.com Mon Sep 4 13:15:11 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 Sep 2017 15:15:11 +0200 Subject: RFR: Add JVMTI notifications to Shenandoah GC pauses Message-ID: <551869c4-ae45-77c8-f60e-cef427e6dfb2@redhat.com> This adds notifications to JVMTI about GarbageCollectionStart and GarbageCollectionFinish. http://cr.openjdk.java.net/~rkennke/jvmti/webrev.00/ Test: hotspot_gc_shenandoah From shade at redhat.com Mon Sep 4 13:17:25 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Sep 2017 15:17:25 +0200 Subject: RFR: Add JVMTI notifications to Shenandoah GC pauses In-Reply-To: <551869c4-ae45-77c8-f60e-cef427e6dfb2@redhat.com> References: <551869c4-ae45-77c8-f60e-cef427e6dfb2@redhat.com> Message-ID: <89cd412f-198f-28fd-71f9-5282aeec3286@redhat.com> On 09/04/2017 03:15 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/jvmti/webrev.00/ Okay! But I still do not get why can't we use VM_GC_Operation superclass for this. -Aleksey From rkennke at redhat.com Mon Sep 4 13:45:33 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 Sep 2017 15:45:33 +0200 Subject: RFR: Add JVMTI notifications to Shenandoah GC pauses In-Reply-To: <89cd412f-198f-28fd-71f9-5282aeec3286@redhat.com> References: <551869c4-ae45-77c8-f60e-cef427e6dfb2@redhat.com> <89cd412f-198f-28fd-71f9-5282aeec3286@redhat.com> Message-ID: Am 04.09.2017 um 15:17 schrieb Aleksey Shipilev: > On 09/04/2017 03:15 PM, Roman Kennke wrote: >> http://cr.openjdk.java.net/~rkennke/jvmti/webrev.00/ > Okay! But I still do not get why can't we use VM_GC_Operation superclass for this. > > -Aleksey > > The superclass does stuff that we don't need/want. It's basically meant to by used by fully-STW collectors. Both CMS and G1 don't seem to use it either. Roman From roman at kennke.org Mon Sep 4 13:49:05 2017 From: roman at kennke.org (roman at kennke.org) Date: Mon, 04 Sep 2017 13:49:05 +0000 Subject: hg: shenandoah/jdk10/hotspot: Add JVMTI notifications to Shenandoah GC pauses. Message-ID: <201709041349.v84Dn59c003513@aojmv0008.oracle.com> Changeset: 88976a2207e0 Author: rkennke Date: 2017-09-04 15:12 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/88976a2207e0 Add JVMTI notifications to Shenandoah GC pauses. ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.cpp From shade at redhat.com Mon Sep 4 15:28:16 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Sep 2017 17:28:16 +0200 Subject: RFR: Refactor ShenandoahFreeSet Message-ID: <7e4ceb12-ff58-13df-9718-d564b14e4bc4@redhat.com> http://cr.openjdk.java.net/~shade/shenandoah/refactor-freeset/webrev.01/ Several improvements: a) Untangle from ShenandoahHeapRegionSet, in anticipation for merging with cset and other facilities for centralized region handling; b) Rewrite humongous allocation path with a simpler code; c) Simplify unsafe_peek_free; d) Various style improvements; Testing: hotspot_gc_shenandoah Thanks, -Aleksey From rkennke at redhat.com Mon Sep 4 19:17:35 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 Sep 2017 21:17:35 +0200 Subject: RFR: Refactor ShenandoahFreeSet In-Reply-To: <7e4ceb12-ff58-13df-9718-d564b14e4bc4@redhat.com> References: <7e4ceb12-ff58-13df-9718-d564b14e4bc4@redhat.com> Message-ID: <7edfab0b-2070-30f9-bd38-4cdf169834e9@redhat.com> Am 04.09.2017 um 17:28 schrieb Aleksey Shipilev: > http://cr.openjdk.java.net/~shade/shenandoah/refactor-freeset/webrev.01/ > > Several improvements: > a) Untangle from ShenandoahHeapRegionSet, in anticipation for merging with cset and other > facilities for centralized region handling; > b) Rewrite humongous allocation path with a simpler code; > c) Simplify unsafe_peek_free; > d) Various style improvements; > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > Looks good! Roman From ashipile at redhat.com Mon Sep 4 20:57:21 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 04 Sep 2017 20:57:21 +0000 Subject: hg: shenandoah/jdk10/hotspot: Refactor ShenandoahFreeSet Message-ID: <201709042057.v84KvLhT005101@aojmv0008.oracle.com> Changeset: d64a5a4a4366 Author: shade Date: 2017-09-04 22:35 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/d64a5a4a4366 Refactor ShenandoahFreeSet ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp From rkennke at redhat.com Tue Sep 5 10:26:25 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 5 Sep 2017 12:26:25 +0200 Subject: RFR: Make sure we have at least one memory pool per memory manager (JMX) Message-ID: Hi, this adds a memory pool to the major memory manager in Shenandoah's JMX interface. I suspect that this was actually meant to be that way, but we made a mistake and assigned the 2nd pool to the minor mgr. It *is* possible that we assigned two pools to the minor mgr on purpose, because the services interface is so wretched, and certain clients assume a fixed amount of memory managers and maybe pools. It doesn't really fit what Shenandoah does though. This patch fixes a failure in the TCK. I wrote a testcase that verifies kindof the same thing as the failing TCK test (i.e. that each memory mgr has at least one memory pool with non-empty names, etc). Whenever some other implicit requirement of clients shows up (e.g. need exactly N pools or managers) we must add testcases to verify this. Tests: hotspot_gc_shenandoah, manually running jstat http://cr.openjdk.java.net/~rkennke/jmxmempools/webrev.01/ Ok? From shade at redhat.com Tue Sep 5 10:32:11 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 Sep 2017 12:32:11 +0200 Subject: RFR: Make sure we have at least one memory pool per memory manager (JMX) In-Reply-To: References: Message-ID: On 09/05/2017 12:26 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/jmxmempools/webrev.01/ You can probably inline and remove fail() in the test. Otherwise, looks good. -Aleksey From roman at kennke.org Tue Sep 5 10:41:24 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 05 Sep 2017 10:41:24 +0000 Subject: hg: shenandoah/jdk8u: 5 new changesets Message-ID: <201709051041.v85AfOtc008559@aojmv0008.oracle.com> Changeset: 461c9270383a Author: andrew Date: 2016-07-11 05:02 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/rev/461c9270383a 8151841: Build needs additional flags to compile with GCC 6 [plus parts of 8149647 & 8032045] Summary: C++ standard needs to be explicitly set and some optimisations turned off to build on GCC 6 Reviewed-by: erikj, dholmes, kbarrett ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot-spec.gmk.in ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: 8803133b679b Author: andrew Date: 2017-09-05 03:10 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/rev/8803133b679b Added tag aarch64-jdk8u144-b02 for changeset 461c9270383a ! .hgtags Changeset: 768646fd5745 Author: andrew Date: 2017-09-05 03:44 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/rev/768646fd5745 Merge aarch64-jdk8u144-b02 ! .hgtags Changeset: 6cd26459fb2f Author: andrew Date: 2017-09-05 03:46 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/rev/6cd26459fb2f Added tag aarch64-shenandoah-jdk8u144-b02 for changeset 768646fd5745 ! .hgtags Changeset: eb41c6b57b33 Author: rkennke Date: 2017-09-05 12:29 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/rev/eb41c6b57b33 Merge ! .hgtags From roman at kennke.org Tue Sep 5 10:41:22 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 05 Sep 2017 10:41:22 +0000 Subject: hg: shenandoah/jdk8u/nashorn: 4 new changesets Message-ID: <201709051041.v85AfMYZ008409@aojmv0008.oracle.com> Changeset: b74e5d373608 Author: andrew Date: 2017-09-05 03:10 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/nashorn/rev/b74e5d373608 Added tag aarch64-jdk8u144-b02 for changeset 13c40d5bd8cc ! .hgtags Changeset: f41bd292f498 Author: andrew Date: 2017-09-05 03:44 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/nashorn/rev/f41bd292f498 Merge aarch64-jdk8u144-b02 ! .hgtags Changeset: 84c7ffac6e87 Author: andrew Date: 2017-09-05 03:46 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/nashorn/rev/84c7ffac6e87 Added tag aarch64-shenandoah-jdk8u144-b02 for changeset f41bd292f498 ! .hgtags Changeset: b4705d0bdef1 Author: rkennke Date: 2017-09-05 12:30 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/nashorn/rev/b4705d0bdef1 Merge ! .hgtags From roman at kennke.org Tue Sep 5 10:41:23 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 05 Sep 2017 10:41:23 +0000 Subject: hg: shenandoah/jdk8u/jaxws: 4 new changesets Message-ID: <201709051041.v85AfNFO008488@aojmv0008.oracle.com> Changeset: 56babd47ee19 Author: andrew Date: 2017-09-05 03:10 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/jaxws/rev/56babd47ee19 Added tag aarch64-jdk8u144-b02 for changeset 1eb06202a5c9 ! .hgtags Changeset: f1d17bae71a9 Author: andrew Date: 2017-09-05 03:44 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/jaxws/rev/f1d17bae71a9 Merge aarch64-jdk8u144-b02 ! .hgtags Changeset: 20f47c7395a6 Author: andrew Date: 2017-09-05 03:46 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/jaxws/rev/20f47c7395a6 Added tag aarch64-shenandoah-jdk8u144-b02 for changeset f1d17bae71a9 ! .hgtags Changeset: 859e24106283 Author: rkennke Date: 2017-09-05 12:30 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/jaxws/rev/859e24106283 Merge ! .hgtags From roman at kennke.org Tue Sep 5 10:41:25 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 05 Sep 2017 10:41:25 +0000 Subject: hg: shenandoah/jdk8u/corba: 4 new changesets Message-ID: <201709051041.v85AfQ4D008671@aojmv0008.oracle.com> Changeset: 2f6bf6972714 Author: andrew Date: 2017-09-05 03:10 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/corba/rev/2f6bf6972714 Added tag aarch64-jdk8u144-b02 for changeset 4b222c433612 ! .hgtags Changeset: ad9497112b0a Author: andrew Date: 2017-09-05 03:44 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/corba/rev/ad9497112b0a Merge aarch64-jdk8u144-b02 ! .hgtags Changeset: 76a6ff94929a Author: andrew Date: 2017-09-05 03:46 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/corba/rev/76a6ff94929a Added tag aarch64-shenandoah-jdk8u144-b02 for changeset ad9497112b0a ! .hgtags Changeset: 7f2f4583b2ad Author: rkennke Date: 2017-09-05 12:29 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/corba/rev/7f2f4583b2ad Merge ! .hgtags From roman at kennke.org Tue Sep 5 10:41:25 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 05 Sep 2017 10:41:25 +0000 Subject: hg: shenandoah/jdk8u/jaxp: 4 new changesets Message-ID: <201709051041.v85AfPJd008618@aojmv0008.oracle.com> Changeset: b56f98b75e2a Author: andrew Date: 2017-09-05 03:10 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/jaxp/rev/b56f98b75e2a Added tag aarch64-jdk8u144-b02 for changeset 2793510feb8c ! .hgtags Changeset: 488afc89de7b Author: andrew Date: 2017-09-05 03:44 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/jaxp/rev/488afc89de7b Merge aarch64-jdk8u144-b02 ! .hgtags Changeset: 0e28e142b39e Author: andrew Date: 2017-09-05 03:46 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/jaxp/rev/0e28e142b39e Added tag aarch64-shenandoah-jdk8u144-b02 for changeset 488afc89de7b ! .hgtags Changeset: 288901c9e89c Author: rkennke Date: 2017-09-05 12:29 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/jaxp/rev/288901c9e89c Merge ! .hgtags From roman at kennke.org Tue Sep 5 10:41:27 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 05 Sep 2017 10:41:27 +0000 Subject: hg: shenandoah/jdk8u/hotspot: 4 new changesets Message-ID: <201709051041.v85AfRNp008709@aojmv0008.oracle.com> Changeset: 21011afdacc2 Author: andrew Date: 2017-09-05 03:10 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/21011afdacc2 Added tag aarch64-jdk8u144-b02 for changeset 7672149aea2c ! .hgtags Changeset: ec1439043fc0 Author: andrew Date: 2017-09-05 03:44 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/ec1439043fc0 Merge aarch64-jdk8u144-b02 ! .hgtags Changeset: 1bec072d4387 Author: andrew Date: 2017-09-05 03:46 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/1bec072d4387 Added tag aarch64-shenandoah-jdk8u144-b02 for changeset ec1439043fc0 ! .hgtags Changeset: 0a117f12949c Author: rkennke Date: 2017-09-05 12:29 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/0a117f12949c Merge ! .hgtags From roman at kennke.org Tue Sep 5 10:41:29 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 05 Sep 2017 10:41:29 +0000 Subject: hg: shenandoah/jdk8u/langtools: 4 new changesets Message-ID: <201709051041.v85AfTwa008744@aojmv0008.oracle.com> Changeset: 9a5a859f6fda Author: andrew Date: 2017-09-05 03:10 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/langtools/rev/9a5a859f6fda Added tag aarch64-jdk8u144-b02 for changeset eb8e9a1d6c9f ! .hgtags Changeset: 7d0753285c49 Author: andrew Date: 2017-09-05 03:44 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/langtools/rev/7d0753285c49 Merge aarch64-jdk8u144-b02 ! .hgtags Changeset: e0e8b07dc201 Author: andrew Date: 2017-09-05 03:46 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/langtools/rev/e0e8b07dc201 Added tag aarch64-shenandoah-jdk8u144-b02 for changeset 7d0753285c49 ! .hgtags Changeset: c64dfa8b59ae Author: rkennke Date: 2017-09-05 12:30 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/langtools/rev/c64dfa8b59ae Merge ! .hgtags From roman at kennke.org Tue Sep 5 10:41:29 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 05 Sep 2017 10:41:29 +0000 Subject: hg: shenandoah/jdk8u/jdk: 4 new changesets Message-ID: <201709051041.v85AfTlE008750@aojmv0008.oracle.com> Changeset: 49cb4b2b45a3 Author: andrew Date: 2017-09-05 03:10 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/jdk/rev/49cb4b2b45a3 Added tag aarch64-jdk8u144-b02 for changeset 9322c39fd0df ! .hgtags Changeset: b415ef41ac89 Author: andrew Date: 2017-09-05 03:44 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/jdk/rev/b415ef41ac89 Merge aarch64-jdk8u144-b02 ! .hgtags Changeset: 24a174dce25b Author: andrew Date: 2017-09-05 03:46 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/jdk/rev/24a174dce25b Added tag aarch64-shenandoah-jdk8u144-b02 for changeset b415ef41ac89 ! .hgtags Changeset: 65443a2970d1 Author: rkennke Date: 2017-09-05 12:30 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/jdk/rev/65443a2970d1 Merge ! .hgtags From rkennke at redhat.com Tue Sep 5 10:40:20 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 5 Sep 2017 12:40:20 +0200 Subject: RFR: Make sure we have at least one memory pool per memory manager (JMX) In-Reply-To: References: Message-ID: <7d23c765-2299-34c1-63bc-fb15bba5e02d@redhat.com> Am 05.09.2017 um 12:32 schrieb Aleksey Shipilev: > On 09/05/2017 12:26 PM, Roman Kennke wrote: >> http://cr.openjdk.java.net/~rkennke/jmxmempools/webrev.01/ > > You can probably inline and remove fail() in the test. Otherwise, looks good. Ok. Pushed with exactly your suggested change. Roman From roman at kennke.org Tue Sep 5 10:43:36 2017 From: roman at kennke.org (roman at kennke.org) Date: Tue, 05 Sep 2017 10:43:36 +0000 Subject: hg: shenandoah/jdk10/hotspot: Make sure we have at least one memory pool per memory manager (JMX). Message-ID: <201709051043.v85Aham2009702@aojmv0008.oracle.com> Changeset: 85b080915172 Author: rkennke Date: 2017-09-05 12:39 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/85b080915172 Make sure we have at least one memory pool per memory manager (JMX). ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp + test/gc/shenandoah/TestMemoryPools.java From ashipile at redhat.com Tue Sep 5 14:20:12 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 05 Sep 2017 14:20:12 +0000 Subject: hg: shenandoah/jdk9/hotspot: 28 new changesets Message-ID: <201709051420.v85EKCC2002359@aojmv0008.oracle.com> Changeset: fc1ae1b5297e Author: shade Date: 2017-09-05 11:15 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/fc1ae1b5297e [backport] BrooksPointer tracing overwhelms -Xlog:gc=trace ! src/share/vm/gc/shenandoah/brooksPointer.hpp ! src/share/vm/gc/shenandoah/brooksPointer.inline.hpp Changeset: 252b51dab274 Author: shade Date: 2017-09-05 11:16 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/252b51dab274 [backport] Reclaimed humongous regions should count towards immediate garbage ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp Changeset: 8f3043a5c302 Author: shade Date: 2017-09-05 12:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/8f3043a5c302 [backport] String dedup support in Shenandoah ! src/share/vm/gc/g1/g1StringDedup.hpp ! src/share/vm/gc/g1/g1StringDedupQueue.cpp ! src/share/vm/gc/g1/g1StringDedupQueue.hpp ! src/share/vm/gc/g1/g1StringDedupTable.cpp ! src/share/vm/gc/g1/g1StringDedupThread.cpp ! src/share/vm/gc/g1/g1StringDedupThread.hpp ! src/share/vm/gc/shenandoah/shenandoahCollectionSet.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp + src/share/vm/gc/shenandoah/shenandoahStringDedup.cpp + src/share/vm/gc/shenandoah/shenandoahStringDedup.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/safepoint.cpp + test/gc/shenandoah/TestShenandoahStrDedup.java Changeset: b20f362bff4d Author: shade Date: 2017-09-05 12:26 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/b20f362bff4d [backport] Allocation latency tracing ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/numberSeq.hpp Changeset: 6df0869dcda4 Author: shade Date: 2017-09-05 12:42 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/6df0869dcda4 [backport] Refactor region flags into finite state machine ! src/share/vm/gc/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp Changeset: 05cb616b2765 Author: shade Date: 2017-09-05 12:43 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/05cb616b2765 [backport] Add regular regions to free set after partial GC ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp Changeset: 4cd1d7a1f007 Author: shade Date: 2017-09-05 12:44 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/4cd1d7a1f007 [backport] Cleanup "dirty" mentions ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp Changeset: e61586979ab3 Author: shade Date: 2017-09-05 12:44 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/e61586979ab3 [backport] Verifier should walk cset and humongous regions ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp Changeset: 764e59107ba2 Author: shade Date: 2017-09-05 12:45 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/764e59107ba2 [backport] Allow allocations in pinned regions ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp Changeset: 6f901114179a Author: shade Date: 2017-09-05 12:57 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/6f901114179a [backport] Track interior location when verifying matrix + More elegant fix for tracking interior ptrs in matrix verification ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp Changeset: 3865ef3292d7 Author: shade Date: 2017-09-05 13:32 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/3865ef3292d7 [backport] Refactor ShenandoahHeapLock ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp + src/share/vm/gc/shenandoah/shenandoahHeapLock.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp Changeset: 038b2a9d0710 Author: shade Date: 2017-09-05 13:32 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/038b2a9d0710 [backport] Templatize and improve inlining of arraycopy and clone barriers. ! src/share/vm/gc/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc/shenandoah/shenandoahBarrierSet.hpp Changeset: 76556fbabec6 Author: shade Date: 2017-09-05 13:33 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/76556fbabec6 [backport] Refactor ShConcThread dispatch ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp Changeset: f7d10b120268 Author: shade Date: 2017-09-05 14:15 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/f7d10b120268 [backport] Mark heuristics diagnostic/experimental ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! test/gc/shenandoah/EvilSyncBug.java ! test/gc/shenandoah/LotsOfCycles.java ! test/gc/shenandoah/MXNotificationsFullGC.java ! test/gc/shenandoah/ShenandoahJNICritical.java ! test/gc/shenandoah/TestPeriodicGC.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/TestShenandoahStrDedup.java ! test/gc/shenandoah/acceptance/AllocIntArrays.java ! test/gc/shenandoah/acceptance/AllocObjectArrays.java ! test/gc/shenandoah/acceptance/AllocObjects.java ! test/gc/shenandoah/acceptance/HeapUncommit.java ! test/gc/shenandoah/acceptance/RetainObjects.java ! test/gc/shenandoah/acceptance/StringInternCleanup.java ! test/gc/shenandoah/compiler/C1VectorizedMismatch.java ! test/gc/shenandoah/compiler/TestReferenceCAS.java + test/gc/shenandoah/options/TestHeuristicsUnlock.java ! test/gc/shenandoah/options/TestShenandoahArgumentRanges.java ! test/gc/shenandoah/options/TestSingleThreadedShenandoah.java ! test/gc/stress/TestGCOldWithShenandoah.java ! test/gc/stress/gcbasher/TestGCBasherWithShenandoah.java Changeset: d8632138b647 Author: shade Date: 2017-09-05 14:23 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/d8632138b647 "continuous" heuristics ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! test/gc/shenandoah/LotsOfCycles.java ! test/gc/shenandoah/TestPeriodicGC.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/TestShenandoahStrDedup.java ! test/gc/shenandoah/acceptance/AllocIntArrays.java ! test/gc/shenandoah/acceptance/AllocObjectArrays.java ! test/gc/shenandoah/acceptance/AllocObjects.java ! test/gc/shenandoah/acceptance/HeapUncommit.java ! test/gc/shenandoah/acceptance/RetainObjects.java ! test/gc/shenandoah/acceptance/StringInternCleanup.java ! test/gc/shenandoah/options/TestHeuristicsUnlock.java ! test/gc/stress/TestGCOldWithShenandoah.java ! test/gc/stress/gcbasher/TestGCBasherWithShenandoah.java Changeset: 87b615282a72 Author: shade Date: 2017-09-05 14:23 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/87b615282a72 [backport] Verify humongous regions liveness ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp Changeset: ad921e5dce5f Author: shade Date: 2017-09-05 14:29 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/ad921e5dce5f [backport] Refactor ShenandoahHeapRegionSet ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp Changeset: a929f8d5cf93 Author: shade Date: 2017-09-05 14:32 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/a929f8d5cf93 [backport] On-demand commit as heap resizing strategy ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.hpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp ! test/gc/shenandoah/TestHeapAlloc.java ! test/gc/shenandoah/options/AlwaysPreTouch.java Changeset: 78c855a5ea02 Author: shade Date: 2017-09-05 15:12 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/78c855a5ea02 [backport] Assorted monitoring support fixes ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/gc/shenandoah/shenandoahMonitoringSupport.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! test/TEST.groups ! test/gc/metaspace/TestMetaspacePerfCounters.java Changeset: f423f101f2b8 Author: shade Date: 2017-09-05 15:16 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/f423f101f2b8 [backport] Pinning humongous regions should be allowed ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! test/TEST.ROOT ! test/TEST.groups + test/gc/stress/gclocker/TestGCLockerWithShenandoah.java Changeset: 27ef3cfd39cf Author: shade Date: 2017-09-05 15:48 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/27ef3cfd39cf [backport] Unlock more GC-specific tests for Shenandoah ! test/TEST.groups ! test/gc/TestHumongousReferenceObject.java ! test/gc/TestSmallHeap.java ! test/gc/TestSystemGC.java ! test/gc/arguments/TestAlignmentToUseLargePages.java ! test/gc/arguments/TestDisableDefaultGC.java ! test/gc/arguments/TestUseCompressedOopsErgo.java ! test/gc/class_unloading/TestClassUnloadingDisabled.java ! test/gc/ergonomics/TestDynamicNumberOfGCThreads.java ! test/gc/ergonomics/TestInitialGCThreadLogging.java ! test/gc/logging/TestGCId.java + test/gc/startup_warnings/TestShenandoah.java + test/gc/stress/systemgc/TestSystemGCWithShenandoah.java ! test/runtime/CompressedOops/UseCompressedOops.java Changeset: 36b88fc163d3 Author: shade Date: 2017-09-05 15:34 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/36b88fc163d3 [backport] Update counters on slow-path more rarely ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp Changeset: 3cd5926e4398 Author: shade Date: 2017-09-05 15:43 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/3cd5926e4398 [backport] Consistent print_on and tty handling ! src/share/vm/gc/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionSet.hpp Changeset: 235764d36de4 Author: shade Date: 2017-09-05 15:43 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/235764d36de4 [backport] Region (byte|word) shifts as the replacement for divisions ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectionSet.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/shenandoahSupport.cpp Changeset: d519cf6f974d Author: shade Date: 2017-09-05 15:44 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/d519cf6f974d [backport] Factor out storeval barrier from read barriers. ! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp ! src/cpu/aarch64/vm/templateTable_aarch64.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/cpu/x86/vm/templateTable_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/gc/shared/barrierSet.hpp ! src/share/vm/gc/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/objArrayOop.inline.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/unsafe.cpp Changeset: bd941069eaf5 Author: shade Date: 2017-09-05 15:44 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/bd941069eaf5 [backport] Add JVMTI notifications to Shenandoah GC pauses. ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.cpp Changeset: 364d1673a38a Author: shade Date: 2017-09-05 15:45 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/364d1673a38a [backport] Refactor ShenandoahFreeSet ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp Changeset: 802e7ba7c1b7 Author: shade Date: 2017-09-05 15:46 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/802e7ba7c1b7 [backport] Make sure we have at least one memory pool per memory manager (JMX). ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp + test/gc/shenandoah/TestMemoryPools.java From pbeaman at onshape.com Tue Sep 5 14:40:39 2017 From: pbeaman at onshape.com (Peter Beaman) Date: Tue, 5 Sep 2017 10:40:39 -0400 Subject: Crash in openjdk8 while using ShenandoahGC In-Reply-To: <4947234f-522f-9531-0dc2-5282afb0cbad@redhat.com> References: <4947234f-522f-9531-0dc2-5282afb0cbad@redhat.com> Message-ID: Thanks for quick responses by Roman and Aleksey. The log files are shared at hs_err file: https://drive.google.com/open?id=0B5jQhhBr4V-LZ0V5NTBtNWl6cDg gc log: https://drive.google.com/open?id=0B5jQhhBr4V-LWi1vWURFWHd2Vm8 You will see in the gc.log file that the application experienced very frequent multi-second "Pause Full" pauses. I suspect our application is simply overwhelming the ability of the garbage collector to complete its evacuations. The objects being created and then discarded are highly interconnected in object graphs (very occasionally millions of objects, hundreds of megabytes of retained storage depending on the complexity of the 3D model being managed) which may be affecting the speed of marking. A typical operation of our application would be to make a clone of a graph, do some processing, and then discard the clone. In G1 we find these operations very occasionally coincide to cause excessive promotion which ultimately results in a 30+ second Full GC. We've tried to simulate this application behavior with a synthetic test. The test shows Shenandoah behaves much better than G1. (I will share the code and our results.) However in our first production trial we ran into problems with frequent long pauses and then the crash, so clearly the test doesn't emulate production load as well as we would like. Unfortunately it is difficult for us to experiment in production so our ability to test alternative builds and settings is limited. Thanks very much. Peter Beaman Onshape On Mon, Sep 4, 2017 at 5:22 AM, Roman Kennke wrote: > Hi Peter, > > Thank you for testing Shenandoah and reporting this bug. > > Yes, the hs_err and gc log files would be very useful. Please upload it > somewhere and post a link, if possible. > > Yes, for now, this is the preferred channel for filing Shenandoah bugs ;-) > > Best regards, > Roman > > > Our Java application running on an AWS r3.xlarge instance under Ubuntu > > 14.04 crashed with the following after about 12 hours of fairly CPU- and > > GC-intense processing: > > > > # Internal Error (safepoint.cpp:314), pid=3384, tid=0x00007f7448f77700 > > # guarantee(PageArmed == 0) failed: invariant > > # > > # JRE version: OpenJDK Runtime Environment (8.0_141) (build > > 1.8.0_141-internal-15) > > # Java VM: OpenJDK 64-Bit Server VM (25.141-b15 mixed mode linux-amd64 > > compressed oops) > > > > The complete hs_err and gc.log files are available if useful. > Unfortunately > > the machine was not equipped with enough storage to hold a crashdump > file. > > I have not yet reproduced this, so do not yet know how easy or hard that > > may be. > > > > The JVM was built from source at tag jdk8u141-b15, > > > > JVM flags from gc.log: > > > > OpenJDK 64-Bit Server VM (25.141-b15) for linux-amd64 JRE > > (1.8.0_141-internal-15), built on Aug 30 2017 20:07:13 by "pbeaman" with > > gcc 4.8.4 > > Memory: 4k page, physical 31399920k(29785452k free), swap 0k(0k free) > > CommandLine flags: -XX:InitialHeapSize=22506635264 > > -XX:MaxHeapSize=22506635264 -XX:MaxMetaspaceSize=201326592 > > -XX:NumberOfGCLogFiles=10 -XX:-OmitStackTraceInFastThrow > > -XX:OnOutOfMemoryError=touch /opt/bti/OUT_OF_MEMORY > > -XX:+PrintAdaptiveSizePolicy -XX:+PrintGC > > -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCDateStamps > > -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution > > -XX:+UseCompressedClassPointers -XX:+UseCompressedOops > > -XX:-UseGCLogFileRotation -XX:+UseShenandoahGC > -XX:+UseStringDeduplication > > > > We are testing Shenandoah as a possible cure for long Full GC stop times > in > > G1. > > > > Please let me know if there's a preferred channel for filing Shenandoah > > bugs. > > From shade at redhat.com Tue Sep 5 15:25:53 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 Sep 2017 17:25:53 +0200 Subject: Crash in openjdk8 while using ShenandoahGC In-Reply-To: References: <4947234f-522f-9531-0dc2-5282afb0cbad@redhat.com> Message-ID: Hi Peter, On 09/05/2017 04:40 PM, Peter Beaman wrote: > hs_err file: > https://drive.google.com/open?id=0B5jQhhBr4V-LZ0V5NTBtNWl6cDg The suspicious part is this: VM_Operation (0x00007f73746ecc10): RevokeBias, mode: safepoint, requested by thread 0x00007f732e69d800 Which means we were trying to reach the safepoint for biased lock revocation, and failing there. Now, Shenandoah thinks this is what happens: Shenandoah Heap 21979136K total, 21979136K committed, 21976057K used 8192K regions, 2683 active, 2683 total Status: evacuating cancelled <----- oops In our code, when evacuation is cancelled, there are some tricky things happen with application threads, and that might explain why we see the safepoint stall ultimately crashing the VM. The corroborating factor seems to be that we entered the biased locking revocation at the same time, and this blows up. We'd need to do more extensive stress tests with biased locking enabled, this is on us. > gc log: > https://drive.google.com/open?id=0B5jQhhBr4V-LWi1vWURFWHd2Vm8 ...also I see there are lots of safepoints in between the GC-induced ones: 2017-09-01T03:29:02.071+0000: 3691.233: Total time for which application threads were stopped: 0.0257092 seconds, Stopping threads took: 0.0233301 seconds 2017-09-01T03:29:03.329+0000: 3692.491: Total time for which application threads were stopped: 0.0409040 seconds, Stopping threads took: 0.0384744 seconds Given these two observations, I am sure -XX:-UseBiasedLocking would improve latency and stability for your app. Can you try it? I would recommend you to run with -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=10 to get the more detailed dissection of safepoints experienced, which would include VM operations names. > You will see in the gc.log file that the application experienced very > frequent multi-second "Pause Full" pauses. I suspect our application is > simply overwhelming the ability of the garbage collector to complete its > evacuations. Could be. The default "adaptive" heuristics would try to reserve some free space to absorb the allocation spike. See our Wiki for details how to request more free space. Or, just give it more heap. Shenandoah works better with more heap, in contrast to other collectors :) Thanks, -Aleksey From shade at redhat.com Tue Sep 5 17:44:42 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 Sep 2017 19:44:42 +0200 Subject: RFR: Disable biased locking by default Message-ID: Hi, I think it makes sense to disable biased locking by default: $ hg diff diff -r d64a5a4a4366 src/share/vm/runtime/arguments.cpp --- a/src/share/vm/runtime/arguments.cpp Mon Sep 04 22:35:03 2017 +0200 +++ b/src/share/vm/runtime/arguments.cpp Tue Sep 05 19:43:21 2017 +0200 @@ -2075,6 +2075,14 @@ } FLAG_SET_DEFAULT(ShenandoahUncommitDelay, max_uintx); } + + // Current Hotspot machinery for biased locking may introduce lots of latency hiccups + // that negate the benefits of low-latency GC. The throughput improvements granted by + // biased locking on modern hardware are not covering the latency problems induced by + // it. Therefore, unless user really wants it, disable biased locking. + if (FLAG_IS_DEFAULT(UseBiasedLocking)) { + FLAG_SET_DEFAULT(UseBiasedLocking, false); + } } void Arguments::set_gc_specific_flags() { Testing: hotspot_gc_shenandoah Thanks, -Aleksey From rkennke at redhat.com Tue Sep 5 18:08:15 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 5 Sep 2017 20:08:15 +0200 Subject: RFR: Disable biased locking by default In-Reply-To: References: Message-ID: <59c4f65b-4cdb-10c9-c74a-33417e0e7504@redhat.com> Am 05.09.2017 um 19:44 schrieb Aleksey Shipilev: > Hi, > > I think it makes sense to disable biased locking by default: > > $ hg diff > diff -r d64a5a4a4366 src/share/vm/runtime/arguments.cpp > --- a/src/share/vm/runtime/arguments.cpp Mon Sep 04 22:35:03 2017 +0200 > +++ b/src/share/vm/runtime/arguments.cpp Tue Sep 05 19:43:21 2017 +0200 > @@ -2075,6 +2075,14 @@ > } > FLAG_SET_DEFAULT(ShenandoahUncommitDelay, max_uintx); > } > + > + // Current Hotspot machinery for biased locking may introduce lots of latency hiccups > + // that negate the benefits of low-latency GC. The throughput improvements granted by > + // biased locking on modern hardware are not covering the latency problems induced by > + // it. Therefore, unless user really wants it, disable biased locking. > + if (FLAG_IS_DEFAULT(UseBiasedLocking)) { > + FLAG_SET_DEFAULT(UseBiasedLocking, false); > + } > } > > void Arguments::set_gc_specific_flags() { > > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > > Ok with me. We need to document this in our wiki. Roman From shade at redhat.com Tue Sep 5 19:04:46 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 Sep 2017 21:04:46 +0200 Subject: RFR: Avoid Full STW GC on System.gc() Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/concthread-explicitgc/webrev.01/ Does what is says: triggers concurrent cycle on System.gc() now. Tests DisableExplicitGC and ExplicitGCInvokesConcurrent options too. Testing: hotspot_gc_shenandoah Thanks, -Aleksey From rkennke at redhat.com Tue Sep 5 19:47:09 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 5 Sep 2017 21:47:09 +0200 Subject: RFR: Avoid Full STW GC on System.gc() In-Reply-To: References: Message-ID: <43551f5f-d9fc-2121-2792-b7586a6e2f4c@redhat.com> Am 05.09.2017 um 21:04 schrieb Aleksey Shipilev: > http://cr.openjdk.java.net/~shade/shenandoah/concthread-explicitgc/webrev.01/ > > Does what is says: triggers concurrent cycle on System.gc() now. Tests DisableExplicitGC and > ExplicitGCInvokesConcurrent options too. > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > Ok. Except the comment might be a bit confusing: + + // In current Shenandoah, default System.gc() means full stop-the-world GC, which might + // surprise users. Replace it with full concurrent GC, unless user really wants otherwise. When I read this after the patch has been pushed, 'current Shenandoah' has a different meaning than now :-) Otherwise good. From ashipile at redhat.com Tue Sep 5 20:31:42 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 05 Sep 2017 20:31:42 +0000 Subject: hg: shenandoah/jdk10/hotspot: 2 new changesets Message-ID: <201709052031.v85KVgv6029677@aojmv0008.oracle.com> Changeset: c54f6903880d Author: shade Date: 2017-09-05 20:10 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/c54f6903880d Disable biased locking by default ! src/share/vm/runtime/arguments.cpp Changeset: 096345a40169 Author: shade Date: 2017-09-05 22:26 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/096345a40169 Avoid Full STW GC on System.gc() ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/runtime/arguments.cpp + test/gc/shenandoah/options/TestExplicitGC.java ! test/runtime/MemberName/MemberNameLeak.java From ashipile at redhat.com Tue Sep 5 21:16:03 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 05 Sep 2017 21:16:03 +0000 Subject: hg: shenandoah/jdk9/hotspot: 3 new changesets Message-ID: <201709052116.v85LG3Oq020175@aojmv0008.oracle.com> Changeset: 5378d0f81a82 Author: shade Date: 2017-09-05 22:32 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/5378d0f81a82 [backport] Disable biased locking by default ! src/share/vm/runtime/arguments.cpp Changeset: c16a1b9f65f9 Author: shade Date: 2017-09-05 22:33 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/c16a1b9f65f9 [backport] Avoid Full STW GC on System.gc() ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 4681192b98b3 Author: shade Date: 2017-09-05 22:38 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/4681192b98b3 [backport] Avoid Full STW GC on System.gc() + test/gc/shenandoah/options/TestExplicitGC.java From shade at redhat.com Wed Sep 6 10:20:02 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Sep 2017 12:20:02 +0200 Subject: Busy-loop on Reference.get and concurrent cycle Message-ID: <8dc7a945-ed9d-ac92-b7a8-c6c80098b79e@redhat.com> Hi, I think we have a problem with code that busy-waits on Reference.get, like: WeakReference ref; while (ref.get() != null) { // burn! } The trouble is that Shenandoah only normally does concurrent cycles. When concurrent cycle is done, we enable SATB during the concurrent mark to capture the destructive writes that disconnect parts of reachable heap. Everything is good so far. Now enters Reference.get(). When reference processing is enabled, concurrent mark does not follow through weak references, but instead records them for further processing later. This is done to avoid making referents strongly reachable prematurely, otherwise weak references would degrade to strong references. Now enters a peculiar bug. Suppose at the start of marking the referent was weakly reachable. While concurrent mark is happening, the mutator gets that referent and stores it somewhere in a strongly reachable object, thus making it strongly reachable. But, as far as concurrent mark and reference processing is concerned, that object is still *weakly* reachable, and thus is subject to reclamation, which gives you a dangling pointer. Regular SATB does not capture this, because it records *old* values before the store, not the new ones. G1 had discovered it, and fixed with adding the *result* of Reference.get() to a SATB [1], thus guaranteeing (with some overkill) that the *new* pointer is discovered via SATB. Shenandoah had followed suit. The dangling pointer danger is averted: the polled referent is always alive, in case we store it somewhere. Now it doubles back to Shenandoah. Since the *only* normal cycle we do is the concurrent cycle, that means SATB is always enabled when we process references. Which means if mutator calls Reference.get before the concurrent mark is finished, the referent would be deemed alive. In the code above, when application is running in a busy loop, it is virtually guaranteed. Note that it is irrelevant for current code that mutator only calls get() for the null-check: the SATB code fires on referent read. Thus, we never reclaim this reference, and the whole thing livelocks. (I have jtreg test like that). The only way to get out of this now is making a Full STW GC that will do the mark without SATB enabled. I am at loss how to fix this properly in Shenandoah. Ideas? Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-7009266 From rkennke at redhat.com Wed Sep 6 11:44:15 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 Sep 2017 13:44:15 +0200 Subject: RFR: Factor out keep-alive barrier Message-ID: Turns out that for conc-partial we also need different handling for objects that we need to keep alive for some reason. This mostly affects Reference.get() calls, but also some stuff in the runtime. This patch creates an abstraction for this type of barrier, and lets the implementations call the usual SATB pre-barrier. (Conc-partial will do something else there). Normally I'd consider this something to be upstreamed. However, Erik and I are currently on a different, more complex and more powerful solution, which would obsolete this soon. But I need something now for conc-partial. Tests: hotspot_gc_shenandoah http://cr.openjdk.java.net/~rkennke/keepalivebarrier/webrev.00/ Ok? From shade at redhat.com Wed Sep 6 13:41:15 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Sep 2017 15:41:15 +0200 Subject: RFR: Factor out keep-alive barrier In-Reply-To: References: Message-ID: <28277459-0ebc-3184-e5c9-55a4b4c57a9c@redhat.com> On 09/06/2017 01:44 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/keepalivebarrier/webrev.00/ *) This does not look correct with compressed references, used to be "oop obj = *p", because the argument is oop*, not HeapWord*: 448 void Klass::klass_update_barrier_set_pre(oop* p, oop v) { 449 oop obj = oopDesc::load_heap_oop(p); *) It is a bit worrying to remove the INCLUDE_ALL_GC blocks from the hotpaths in e.g. jni.cpp *) ShenandoahSATBBarrier should be handled in ShenandoahBarrierSet::keep_alive_barrier? -Aleksey From rkennke at redhat.com Wed Sep 6 13:58:00 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 06 Sep 2017 15:58:00 +0200 Subject: RFR: Factor out keep-alive barrier In-Reply-To: <28277459-0ebc-3184-e5c9-55a4b4c57a9c@redhat.com> References: <28277459-0ebc-3184-e5c9-55a4b4c57a9c@redhat.com> Message-ID: <65E854C4-9812-4674-9058-20C769B0FB4F@redhat.com> Am 6. September 2017 15:41:15 MESZ schrieb Aleksey Shipilev : >On 09/06/2017 01:44 PM, Roman Kennke wrote: >> http://cr.openjdk.java.net/~rkennke/keepalivebarrier/webrev.00/ > >*) This does not look correct with compressed references, used to be >"oop obj = *p", because the >argument is oop*, not HeapWord*: > > 448 void Klass::klass_update_barrier_set_pre(oop* p, oop v) { > 449 oop obj = oopDesc::load_heap_oop(p); It's exactly the same, but more readable :-) The field in Klass is never compressed. > >*) It is a bit worrying to remove the INCLUDE_ALL_GC blocks from the >hotpaths in e.g. jni.cpp > OK, I will put it back in. It will all change with the GC interface anyway... >*) ShenandoahSATBBarrier should be handled in >ShenandoahBarrierSet::keep_alive_barrier? > How about guarding it with ShenandoahKeepAliveBarrier? It will not be an SATB barrier anymore with conc partial, this is purely an impl detail right now... Roman -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From shade at redhat.com Wed Sep 6 14:20:27 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Sep 2017 16:20:27 +0200 Subject: RFR: Let ExplicitGCInvokesConcurrent be off by default Message-ID: Christine argues the default behavior for System.gc() should be left as Full STW GC. This patch does it, while leaving the possibility to turn it the concurrent cycle back on. $ hg diff diff -r 096345a40169 src/share/vm/runtime/arguments.cpp --- a/src/share/vm/runtime/arguments.cpp Tue Sep 05 22:26:00 2017 +0200 +++ b/src/share/vm/runtime/arguments.cpp Wed Sep 06 16:17:43 2017 +0200 @@ -2083,12 +2083,6 @@ if (FLAG_IS_DEFAULT(UseBiasedLocking)) { FLAG_SET_DEFAULT(UseBiasedLocking, false); } - - // Default System.gc() means full stop-the-world GC, which might surprise users. - // Replace it with full concurrent GC, unless user really wants otherwise. - if (FLAG_IS_DEFAULT(ExplicitGCInvokesConcurrent)) { - FLAG_SET_DEFAULT(ExplicitGCInvokesConcurrent, true); - } } void Arguments::set_gc_specific_flags() { diff -r 096345a40169 test/gc/shenandoah/options/TestExplicitGC.java --- a/test/gc/shenandoah/options/TestExplicitGC.java Tue Sep 05 22:26:00 2017 +0200 +++ b/test/gc/shenandoah/options/TestExplicitGC.java Wed Sep 06 16:17:43 2017 +0200 @@ -57,8 +57,8 @@ TestExplicitGC.class.getName(), "test"); OutputAnalyzer output = new OutputAnalyzer(pb.start()); - output.shouldNotContain("Pause Full"); - output.shouldContain("Pause Init Mark"); + output.shouldContain("Pause Full"); + output.shouldNotContain("Pause Init Mark"); } { Thanks, -Aleksey From rkennke at redhat.com Wed Sep 6 14:32:17 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 06 Sep 2017 16:32:17 +0200 Subject: RFR: Let ExplicitGCInvokesConcurrent be off by default In-Reply-To: References: Message-ID: Ok Am 6. September 2017 16:20:27 MESZ schrieb Aleksey Shipilev : >Christine argues the default behavior for System.gc() should be left as >Full STW GC. This patch does >it, while leaving the possibility to turn it the concurrent cycle back >on. > >$ hg diff >diff -r 096345a40169 src/share/vm/runtime/arguments.cpp >--- a/src/share/vm/runtime/arguments.cpp Tue Sep 05 22:26:00 2017 +0200 >+++ b/src/share/vm/runtime/arguments.cpp Wed Sep 06 16:17:43 2017 +0200 >@@ -2083,12 +2083,6 @@ > if (FLAG_IS_DEFAULT(UseBiasedLocking)) { > FLAG_SET_DEFAULT(UseBiasedLocking, false); > } >- >- // Default System.gc() means full stop-the-world GC, which might >surprise users. >- // Replace it with full concurrent GC, unless user really wants >otherwise. >- if (FLAG_IS_DEFAULT(ExplicitGCInvokesConcurrent)) { >- FLAG_SET_DEFAULT(ExplicitGCInvokesConcurrent, true); >- } > } > > void Arguments::set_gc_specific_flags() { >diff -r 096345a40169 test/gc/shenandoah/options/TestExplicitGC.java >--- a/test/gc/shenandoah/options/TestExplicitGC.java Tue Sep 05 >22:26:00 2017 +0200 >+++ b/test/gc/shenandoah/options/TestExplicitGC.java Wed Sep 06 >16:17:43 2017 +0200 >@@ -57,8 +57,8 @@ > TestExplicitGC.class.getName(), > "test"); > OutputAnalyzer output = new OutputAnalyzer(pb.start()); >- output.shouldNotContain("Pause Full"); >- output.shouldContain("Pause Init Mark"); >+ output.shouldContain("Pause Full"); >+ output.shouldNotContain("Pause Init Mark"); > } > > { > > >Thanks, >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From ashipile at redhat.com Wed Sep 6 14:36:23 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 06 Sep 2017 14:36:23 +0000 Subject: hg: shenandoah/jdk10/hotspot: Let ExplicitGCInvokesConcurrent be off by default Message-ID: <201709061436.v86EaNrq016225@aojmv0008.oracle.com> Changeset: 01e5a5bfee89 Author: shade Date: 2017-09-06 16:33 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/01e5a5bfee89 Let ExplicitGCInvokesConcurrent be off by default ! src/share/vm/runtime/arguments.cpp ! test/gc/shenandoah/options/TestExplicitGC.java From shade at redhat.com Wed Sep 6 14:35:39 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Sep 2017 16:35:39 +0200 Subject: RFR: Factor out keep-alive barrier In-Reply-To: <65E854C4-9812-4674-9058-20C769B0FB4F@redhat.com> References: <28277459-0ebc-3184-e5c9-55a4b4c57a9c@redhat.com> <65E854C4-9812-4674-9058-20C769B0FB4F@redhat.com> Message-ID: On 09/06/2017 03:58 PM, Roman Kennke wrote: > OK, I will put it back in. It will all change with the GC interface anyway... > >> *) ShenandoahSATBBarrier should be handled in >> ShenandoahBarrierSet::keep_alive_barrier? Seems fine with me. ShenandoahSATBBarrier can be just renamed for this, right? -Aleksey From rkennke at redhat.com Wed Sep 6 14:38:10 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 06 Sep 2017 16:38:10 +0200 Subject: RFR: Factor out keep-alive barrier In-Reply-To: References: <28277459-0ebc-3184-e5c9-55a4b4c57a9c@redhat.com> <65E854C4-9812-4674-9058-20C769B0FB4F@redhat.com> Message-ID: <001E5295-636D-448B-89BE-1BA93368C183@redhat.com> Am 6. September 2017 16:35:39 MESZ schrieb Aleksey Shipilev : >On 09/06/2017 03:58 PM, Roman Kennke wrote: >> OK, I will put it back in. It will all change with the GC interface >anyway... >> >>> *) ShenandoahSATBBarrier should be handled in >>> ShenandoahBarrierSet::keep_alive_barrier? > >Seems fine with me. ShenandoahSATBBarrier can be just renamed for this, >right? No no :-) We still do have actual SATB barriers on oop stores. This here is about keeping objects alive for various reasons not related to SATB, e.g. on Reference.get() Roman -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From rkennke at redhat.com Wed Sep 6 15:19:29 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 Sep 2017 17:19:29 +0200 Subject: RFR: Factor out keep-alive barrier In-Reply-To: References: <28277459-0ebc-3184-e5c9-55a4b4c57a9c@redhat.com> <65E854C4-9812-4674-9058-20C769B0FB4F@redhat.com> Message-ID: <12444dbd-b756-2adf-2aa7-6fe5036d9b45@redhat.com> Am 06.09.2017 um 16:35 schrieb Aleksey Shipilev: > On 09/06/2017 03:58 PM, Roman Kennke wrote: >> OK, I will put it back in. It will all change with the GC interface anyway... >> >>> *) ShenandoahSATBBarrier should be handled in >>> ShenandoahBarrierSet::keep_alive_barrier? > > Seems fine with me. ShenandoahSATBBarrier can be just renamed for this, right? > > -Aleksey > How about this: http://cr.openjdk.java.net/~rkennke/keepalivebarrier/webrev.01/ ? Roman From shade at redhat.com Wed Sep 6 15:20:17 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Sep 2017 17:20:17 +0200 Subject: RFR: System.gc() with ExplicitGCInvokesConcurrent should block Message-ID: <82bcc638-f62b-86b2-eee1-7970377d5ee4@redhat.com> Hi, Current ExplicitGCInvokesConcurrent violates the System.gc() contract in this part: "***When control returns from the method call,*** the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.". To fix it, we need to wait for the end of cycle before returning from System.gc() call: http://cr.openjdk.java.net/~shade/shenandoah/concthread-eic-block/webrev.01/ Testing: hotspot_gc_shenandoah Thanks, -Aleksey From shade at redhat.com Wed Sep 6 15:28:45 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Sep 2017 17:28:45 +0200 Subject: RFR: Factor out keep-alive barrier In-Reply-To: <12444dbd-b756-2adf-2aa7-6fe5036d9b45@redhat.com> References: <28277459-0ebc-3184-e5c9-55a4b4c57a9c@redhat.com> <65E854C4-9812-4674-9058-20C769B0FB4F@redhat.com> <12444dbd-b756-2adf-2aa7-6fe5036d9b45@redhat.com> Message-ID: On 09/06/2017 05:19 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/keepalivebarrier/webrev.01/ Copy-paste error in description: 285 diagnostic(bool, ShenandoahKeepAliveBarrier, true, \ 286 "Turn on/off SATB barriers in Shenandoah") \ Otherwise okay. Thanks, -Aleksey From zgu at redhat.com Wed Sep 6 15:56:18 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 6 Sep 2017 11:56:18 -0400 Subject: RFR: System.gc() with ExplicitGCInvokesConcurrent should block In-Reply-To: <82bcc638-f62b-86b2-eee1-7970377d5ee4@redhat.com> References: <82bcc638-f62b-86b2-eee1-7970377d5ee4@redhat.com> Message-ID: <3b059a1d-a7b5-7dc2-eb19-e98b68fe58df@redhat.com> On 09/06/2017 11:20 AM, Aleksey Shipilev wrote: > Hi, > > Current ExplicitGCInvokesConcurrent violates the System.gc() contract in this part: "***When control > returns from the method call,*** the Java Virtual Machine has made a best effort to reclaim space > from all discarded objects.". To fix it, we need to wait for the end of cycle before returning from > System.gc() call: > http://cr.openjdk.java.net/~shade/shenandoah/concthread-eic-block/webrev.01/ Does it make sense to move flag setting inside mutex lock? it provides release-unlock semantics. Thanks, -Zhengyu > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > From shade at redhat.com Wed Sep 6 15:58:58 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Sep 2017 17:58:58 +0200 Subject: RFR: System.gc() with ExplicitGCInvokesConcurrent should block In-Reply-To: <3b059a1d-a7b5-7dc2-eb19-e98b68fe58df@redhat.com> References: <82bcc638-f62b-86b2-eee1-7970377d5ee4@redhat.com> <3b059a1d-a7b5-7dc2-eb19-e98b68fe58df@redhat.com> Message-ID: <7cb32940-4962-a482-77ae-bc9c6fab35f6@redhat.com> On 09/06/2017 05:56 PM, Zhengyu Gu wrote: > > > On 09/06/2017 11:20 AM, Aleksey Shipilev wrote: >> Hi, >> >> Current ExplicitGCInvokesConcurrent violates the System.gc() contract in this part: "***When control >> returns from the method call,*** the Java Virtual Machine has made a best effort to reclaim space >> from all discarded objects.". To fix it, we need to wait for the end of cycle before returning from >> System.gc() call: >> http://cr.openjdk.java.net/~shade/shenandoah/concthread-eic-block/webrev.01/ > > Does it make sense to move flag setting inside mutex lock? it provides release-unlock semantics. Nope, because the is_conc_gc_requested() is lock-free. -Aleksey From zgu at redhat.com Wed Sep 6 16:03:31 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 6 Sep 2017 12:03:31 -0400 Subject: RFR: System.gc() with ExplicitGCInvokesConcurrent should block In-Reply-To: <7cb32940-4962-a482-77ae-bc9c6fab35f6@redhat.com> References: <82bcc638-f62b-86b2-eee1-7970377d5ee4@redhat.com> <3b059a1d-a7b5-7dc2-eb19-e98b68fe58df@redhat.com> <7cb32940-4962-a482-77ae-bc9c6fab35f6@redhat.com> Message-ID: <58a2a7ff-9dcb-f754-1340-ae294b659d02@redhat.com> On 09/06/2017 11:58 AM, Aleksey Shipilev wrote: > On 09/06/2017 05:56 PM, Zhengyu Gu wrote: >> >> >> On 09/06/2017 11:20 AM, Aleksey Shipilev wrote: >>> Hi, >>> >>> Current ExplicitGCInvokesConcurrent violates the System.gc() contract in this part: "***When control >>> returns from the method call,*** the Java Virtual Machine has made a best effort to reclaim space >>> from all discarded objects.". To fix it, we need to wait for the end of cycle before returning from >>> System.gc() call: >>> http://cr.openjdk.java.net/~shade/shenandoah/concthread-eic-block/webrev.01/ >> >> Does it make sense to move flag setting inside mutex lock? it provides release-unlock semantics. > > Nope, because the is_conc_gc_requested() is lock-free. Yes, but an acquire in is_conc_gc_requested should be sufficient, no? -Zhengyu > > -Aleksey > From shade at redhat.com Wed Sep 6 16:06:05 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Sep 2017 18:06:05 +0200 Subject: RFR: System.gc() with ExplicitGCInvokesConcurrent should block In-Reply-To: <58a2a7ff-9dcb-f754-1340-ae294b659d02@redhat.com> References: <82bcc638-f62b-86b2-eee1-7970377d5ee4@redhat.com> <3b059a1d-a7b5-7dc2-eb19-e98b68fe58df@redhat.com> <7cb32940-4962-a482-77ae-bc9c6fab35f6@redhat.com> <58a2a7ff-9dcb-f754-1340-ae294b659d02@redhat.com> Message-ID: <759318a5-4bb4-4160-87c2-1d4e6c20f743@redhat.com> On 09/06/2017 06:03 PM, Zhengyu Gu wrote: > On 09/06/2017 11:58 AM, Aleksey Shipilev wrote: >> On 09/06/2017 05:56 PM, Zhengyu Gu wrote: >>> On 09/06/2017 11:20 AM, Aleksey Shipilev wrote: >>>> Current ExplicitGCInvokesConcurrent violates the System.gc() contract in this part: "***When >>>> control >>>> returns from the method call,*** the Java Virtual Machine has made a best effort to reclaim space >>>> from all discarded objects.". To fix it, we need to wait for the end of cycle before returning from >>>> System.gc() call: >>>> http://cr.openjdk.java.net/~shade/shenandoah/concthread-eic-block/webrev.01/ >>> >>> Does it make sense to move flag setting inside mutex lock? it provides release-unlock semantics. >> >> Nope, because the is_conc_gc_requested() is lock-free. > > Yes, but an acquire in is_conc_gc_requested should be sufficient, no? Memory model wise, you need to match acquires and releases. So if you release under the lock, you better be user to acquire under it too. Which makes is_conc_gc_requested locked. It is cleaner to separate OrderAccess for acq-rel semantics and mutex for mutual exclusion here. -Aleksey From zgu at redhat.com Wed Sep 6 16:08:15 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 6 Sep 2017 12:08:15 -0400 Subject: RFR: System.gc() with ExplicitGCInvokesConcurrent should block In-Reply-To: <759318a5-4bb4-4160-87c2-1d4e6c20f743@redhat.com> References: <82bcc638-f62b-86b2-eee1-7970377d5ee4@redhat.com> <3b059a1d-a7b5-7dc2-eb19-e98b68fe58df@redhat.com> <7cb32940-4962-a482-77ae-bc9c6fab35f6@redhat.com> <58a2a7ff-9dcb-f754-1340-ae294b659d02@redhat.com> <759318a5-4bb4-4160-87c2-1d4e6c20f743@redhat.com> Message-ID: <6bc79157-89b4-29f9-3b7e-2a8ee643f3f2@redhat.com> On 09/06/2017 12:06 PM, Aleksey Shipilev wrote: > On 09/06/2017 06:03 PM, Zhengyu Gu wrote: >> On 09/06/2017 11:58 AM, Aleksey Shipilev wrote: >>> On 09/06/2017 05:56 PM, Zhengyu Gu wrote: >>>> On 09/06/2017 11:20 AM, Aleksey Shipilev wrote: >>>>> Current ExplicitGCInvokesConcurrent violates the System.gc() contract in this part: "***When >>>>> control >>>>> returns from the method call,*** the Java Virtual Machine has made a best effort to reclaim space >>>>> from all discarded objects.". To fix it, we need to wait for the end of cycle before returning from >>>>> System.gc() call: >>>>> http://cr.openjdk.java.net/~shade/shenandoah/concthread-eic-block/webrev.01/ >>>> >>>> Does it make sense to move flag setting inside mutex lock? it provides release-unlock semantics. >>> >>> Nope, because the is_conc_gc_requested() is lock-free. >> >> Yes, but an acquire in is_conc_gc_requested should be sufficient, no? > > Memory model wise, you need to match acquires and releases. So if you release under the lock, you > better be user to acquire under it too. Which makes is_conc_gc_requested locked. It is cleaner to > separate OrderAccess for acq-rel semantics and mutex for mutual exclusion here. Then, okay. -Zhengyu > > -Aleksey > From ashipile at redhat.com Wed Sep 6 16:11:45 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 06 Sep 2017 16:11:45 +0000 Subject: hg: shenandoah/jdk10/hotspot: System.gc() with ExplicitGCInvokesConcurrent should block Message-ID: <201709061611.v86GBjc7025308@aojmv0008.oracle.com> Changeset: 02e85b3c09d3 Author: shade Date: 2017-09-06 17:59 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/02e85b3c09d3 System.gc() with ExplicitGCInvokesConcurrent should block ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! test/gc/shenandoah/options/TestExplicitGC.java From roman at kennke.org Wed Sep 6 17:03:14 2017 From: roman at kennke.org (roman at kennke.org) Date: Wed, 06 Sep 2017 17:03:14 +0000 Subject: hg: shenandoah/jdk10/hotspot: Factor out keep-alive barrier from usual pre-barrier implementations. Message-ID: <201709061703.v86H3Erq019811@aojmv0008.oracle.com> Changeset: 724618f443fa Author: rkennke Date: 2017-09-06 18:59 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/724618f443fa Factor out keep-alive barrier from usual pre-barrier implementations. ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/templateInterpreterGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/stringTable.cpp ! src/share/vm/gc/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc/g1/g1SATBCardTableModRefBS.hpp ! src/share/vm/gc/shared/barrierSet.hpp ! src/share/vm/gc/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/resolvedMethodTable.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/jniHandles.cpp From rkennke at redhat.com Wed Sep 6 17:01:22 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 Sep 2017 19:01:22 +0200 Subject: RFR: Factor out keep-alive barrier In-Reply-To: References: <28277459-0ebc-3184-e5c9-55a4b4c57a9c@redhat.com> <65E854C4-9812-4674-9058-20C769B0FB4F@redhat.com> <12444dbd-b756-2adf-2aa7-6fe5036d9b45@redhat.com> Message-ID: Am 06.09.2017 um 17:28 schrieb Aleksey Shipilev: > On 09/06/2017 05:19 PM, Roman Kennke wrote: >> http://cr.openjdk.java.net/~rkennke/keepalivebarrier/webrev.01/ > > Copy-paste error in description: > > 285 diagnostic(bool, ShenandoahKeepAliveBarrier, true, \ > 286 "Turn on/off SATB barriers in Shenandoah") \ > > Otherwise okay. Pushed with this change and null-check re-instated in jniHandles.cpp Roman From shade at redhat.com Wed Sep 6 17:39:34 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Sep 2017 19:39:34 +0200 Subject: RFR: ExplicitGCInvokesConcurrent should be disabled for "passive" heuristics Message-ID: <887f5684-887a-e19d-faa4-fa97468c135a@redhat.com> "passive" heuristic is special: it never does concurrent cycles. It should not start doing them when ExplicitGCInvokesConcurrent is enabled and System.gc() is called. Fix: http://cr.openjdk.java.net/~shade/shenandoah/eic-passive/webrev.01/ Testing: hotspot_gc_shenandoah Thanks, -Aleksey From rkennke at redhat.com Wed Sep 6 17:43:07 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 Sep 2017 19:43:07 +0200 Subject: RFR: ExplicitGCInvokesConcurrent should be disabled for "passive" heuristics In-Reply-To: <887f5684-887a-e19d-faa4-fa97468c135a@redhat.com> References: <887f5684-887a-e19d-faa4-fa97468c135a@redhat.com> Message-ID: <62e3b482-1c79-9e36-9623-c05e54fbd988@redhat.com> Am 06.09.2017 um 19:39 schrieb Aleksey Shipilev: > "passive" heuristic is special: it never does concurrent cycles. It should not start doing them when > ExplicitGCInvokesConcurrent is enabled and System.gc() is called. > > Fix: > http://cr.openjdk.java.net/~shade/shenandoah/eic-passive/webrev.01/ > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > Yes From ashipile at redhat.com Wed Sep 6 17:47:15 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 06 Sep 2017 17:47:15 +0000 Subject: hg: shenandoah/jdk10/hotspot: ExplicitGCInvokesConcurrent should be disabled for "passive" heuristics Message-ID: <201709061747.v86HlFWs010832@aojmv0008.oracle.com> Changeset: 3402f9420b66 Author: shade Date: 2017-09-06 19:44 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/3402f9420b66 ExplicitGCInvokesConcurrent should be disabled for "passive" heuristics ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp + test/gc/shenandoah/options/TestExplicitGCNoConcurrent.java From ashipile at redhat.com Wed Sep 6 18:51:49 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 06 Sep 2017 18:51:49 +0000 Subject: hg: shenandoah/jdk9/hotspot: 3 new changesets Message-ID: <201709061851.v86Ipnn5012164@aojmv0008.oracle.com> Changeset: 1f322a1174a6 Author: shade Date: 2017-09-06 20:19 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/1f322a1174a6 [backport] Let ExplicitGCInvokesConcurrent be off by default ! src/share/vm/runtime/arguments.cpp ! test/gc/shenandoah/options/TestExplicitGC.java Changeset: c6971bf93e72 Author: shade Date: 2017-09-06 20:19 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/c6971bf93e72 [backport] System.gc() with ExplicitGCInvokesConcurrent should block ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! test/gc/shenandoah/options/TestExplicitGC.java Changeset: 0d9f6c7c4678 Author: shade Date: 2017-09-06 20:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/0d9f6c7c4678 [backport] ExplicitGCInvokesConcurrent should be disabled for "passive" heuristics ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp + test/gc/shenandoah/options/TestExplicitGCNoConcurrent.java From shade at redhat.com Thu Sep 7 08:15:05 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Sep 2017 10:15:05 +0200 Subject: shenandoah/jdk10 and JDK 10 repository consolidation In-Reply-To: References: Message-ID: Hi Joe, On 09/07/2017 07:21 AM, joe darcy wrote: > I see the Shenandoah project has a JDK 10 forest at > > http://hg.openjdk.java.net/shenandoah/jdk10/ > > and I wanted to discuss with the team how to handle repo consolidation with respect to your project. We are well aware about consolidation! Our plan is the following: a) Stabilize shenandoah/jdk10 ----- we are here ----- b) Pull recent changes from jdk10/hs (or jdk10/jdk10) -- it should be stable now; c) Stabilize shenandoah/jdk10 again d) Export history from shenandoah/jdk10 e) Ask ops@ to purge shenandoah/jdk10 f) Clone consolidated jdk10/jdk10 to shenandoah/jdk10 g) Import history to shenandoah/jdk10 Do you have a script that could convert changesets against "split" repository to changesets for "consolidated" one? Worst-case scenario: we squash all the changesets into one, and apply it as patch. > Within the next few weeks, if you want to keep syncing down changes from JDK 10 master or hs, you'll > need to use a consolidated forest instead of the current split one. Only one more promotion is > planned for the split forest. > > In the near future, we hope to have a script to help automate forward and backward porting of > patches across the consolidation boundary. That would be very useful. -Aleksey From shade at redhat.com Thu Sep 7 09:57:37 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Sep 2017 11:57:37 +0200 Subject: RFC: jdk10/hs (jdk10+22) merge Message-ID: <47e6c0dc-a4c5-8e8c-199d-332dab201a3b@redhat.com> jdk10/hs is now closed for consolidation. According to our plan, we need to pick up the outstanding changes from there for our own stabilization, before we could do the monorepo move. Merge stats: 538 files changed, 9972 insertions(+), 8947 deletions(-) Most of that is Graal update. Atomic refactoring to templates required some changes in Shenandoah code, adding type casts here and there. Removal of oop->is_oop in favor of oopDesc::is_oop required touchups. There is at least one place with a new SATB hook, rewritten to bs()->keep_alive_barrier(...) now. Testing: hotspot_gc_shenandoah Thanks, -Aleksey From rkennke at redhat.com Thu Sep 7 10:12:14 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 Sep 2017 12:12:14 +0200 Subject: RFC: jdk10/hs (jdk10+22) merge In-Reply-To: <47e6c0dc-a4c5-8e8c-199d-332dab201a3b@redhat.com> References: <47e6c0dc-a4c5-8e8c-199d-332dab201a3b@redhat.com> Message-ID: Am 07.09.2017 um 11:57 schrieb Aleksey Shipilev: > jdk10/hs is now closed for consolidation. According to our plan, we need to pick up the outstanding > changes from there for our own stabilization, before we could do the monorepo move. > > Merge stats: > 538 files changed, 9972 insertions(+), 8947 deletions(-) > > Most of that is Graal update. Atomic refactoring to templates required some changes in Shenandoah > code, adding type casts here and there. Removal of oop->is_oop in favor of oopDesc::is_oop required > touchups. There is at least one place with a new SATB hook, rewritten to > bs()->keep_alive_barrier(...) now. > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > Yes, please go! From ashipile at redhat.com Thu Sep 7 10:16:42 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 07 Sep 2017 10:16:42 +0000 Subject: hg: shenandoah/jdk10/jaxp: 6 new changesets Message-ID: <201709071016.v87AGgDU003105@aojmv0008.oracle.com> Changeset: e42763d51cde Author: asaha Date: 2017-08-18 04:37 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jaxp/rev/e42763d51cde Added tag jdk-10+20 for changeset f7d596aa57ae ! .hgtags Changeset: 91112d12e347 Author: iignatyev Date: 2017-08-20 20:36 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jaxp/rev/91112d12e347 8186095: upgrade to jtreg 4.2 b08 Reviewed-by: rriggs, mchung, dholmes, iklam ! test/TEST.ROOT Changeset: dcd49f380d75 Author: fyuan Date: 2017-08-21 15:52 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jaxp/rev/dcd49f380d75 8186028: Regression in BCEL caused by 8181154: Fix lint warnings in JAXP repo: deprecation Reviewed-by: dfuchs, joehw, dbuck ! test/javax/xml/jaxp/unittest/parsers/Bug8003147Test.java Changeset: 588139874696 Author: asaha Date: 2017-08-25 04:59 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jaxp/rev/588139874696 Added tag jdk-10+21 for changeset dcd49f380d75 ! .hgtags Changeset: 47872600e78b Author: joehw Date: 2017-08-25 10:17 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jaxp/rev/47872600e78b 8186675: Javadoc of SAXSource contains implementation detail Reviewed-by: lancea ! src/java.xml/share/classes/javax/xml/transform/sax/SAXSource.java Changeset: 7b77f4c26025 Author: asaha Date: 2017-09-01 14:13 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jaxp/rev/7b77f4c26025 Added tag jdk-10+22 for changeset 47872600e78b ! .hgtags From ashipile at redhat.com Thu Sep 7 10:16:42 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 07 Sep 2017 10:16:42 +0000 Subject: hg: shenandoah/jdk10: 27 new changesets Message-ID: <201709071016.v87AGgr7003124@aojmv0008.oracle.com> Changeset: 5cc4a947c158 Author: asaha Date: 2017-08-18 04:36 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/5cc4a947c158 Added tag jdk-10+20 for changeset 682e2a6df836 ! .hgtags Changeset: 63cc2efbe579 Author: jwilhelm Date: 2017-08-18 18:39 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/63cc2efbe579 Merge ! common/autoconf/generated-configure.sh - common/autoconf/lib-elf.m4 Changeset: 48ae1d50d393 Author: bobv Date: 2017-08-21 12:08 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/48ae1d50d393 8186115: libelf still referenced after 8172670 Reviewed-by: kvn, twisti, erikj, dholmes ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/help.m4 ! common/doc/building.html ! common/doc/building.md ! make/devkit/Tools.gmk Changeset: e1a01c4d08b2 Author: glaubitz Date: 2017-08-21 15:17 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/e1a01c4d08b2 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc Reviewed-by: erikj ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: af8f99ad6c15 Author: glaubitz Date: 2017-08-21 15:19 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/af8f99ad6c15 8186313: Additional platform definitions to support Zero builds Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 Changeset: 56d1e05e0def Author: gtriantafill Date: 2017-08-16 14:49 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/56d1e05e0def 8149790: NegativeArraySizeException with hprof Reviewed-by: lfoltan, ctornqvi, hseigel, dcubed ! test/lib/jdk/test/lib/hprof/model/HackJavaValue.java ! test/lib/jdk/test/lib/hprof/model/JavaClass.java ! test/lib/jdk/test/lib/hprof/model/JavaHeapObject.java ! test/lib/jdk/test/lib/hprof/model/JavaLazyReadObject.java ! test/lib/jdk/test/lib/hprof/model/JavaObject.java ! test/lib/jdk/test/lib/hprof/model/JavaObjectArray.java ! test/lib/jdk/test/lib/hprof/model/JavaObjectRef.java ! test/lib/jdk/test/lib/hprof/model/JavaThing.java ! test/lib/jdk/test/lib/hprof/model/JavaValue.java ! test/lib/jdk/test/lib/hprof/model/JavaValueArray.java ! test/lib/jdk/test/lib/hprof/model/ReachableObjects.java ! test/lib/jdk/test/lib/hprof/model/Snapshot.java ! test/lib/jdk/test/lib/hprof/parser/FileReadBuffer.java ! test/lib/jdk/test/lib/hprof/parser/MappedReadBuffer.java ! test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java Changeset: 45e0cf8cf984 Author: iignatyev Date: 2017-08-20 20:36 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/45e0cf8cf984 8186095: upgrade to jtreg 4.2 b08 Reviewed-by: rriggs, mchung, dholmes, iklam ! common/conf/jib-profiles.js Changeset: 786d4184f07c Author: dchuyko Date: 2017-08-21 14:57 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/786d4184f07c 8186438: 'configure' fails to find installed libfreetype on Ubuntu AArch64 Reviewed-by: erikj ! common/autoconf/generated-configure.sh ! common/autoconf/lib-freetype.m4 Changeset: 0881b0b83535 Author: jwilhelm Date: 2017-08-22 16:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/0881b0b83535 Merge ! common/autoconf/generated-configure.sh Changeset: 0c85aa3795ce Author: phedlin Date: 2017-08-28 13:29 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/0c85aa3795ce 8183119: Resolve 'libkstat' dependency between open and closed part of JDK Reviewed-by: erikj, kvn ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: f10b706d5c33 Author: jwilhelm Date: 2017-08-22 16:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/f10b706d5c33 Merge ! common/autoconf/generated-configure.sh Changeset: 90cdfe56f154 Author: erikj Date: 2017-08-23 08:55 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/90cdfe56f154 8186470: JDK10 hotspot integration has broken all MacOS dummy builds Reviewed-by: ctornqvi, tbell ! make/common/NativeCompilation.gmk Changeset: 79d83606d48c Author: asaha Date: 2017-08-25 04:59 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/79d83606d48c Added tag jdk-10+21 for changeset 90cdfe56f154 ! .hgtags Changeset: f49503af5d5b Author: jwilhelm Date: 2017-08-28 21:46 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/f49503af5d5b Merge ! common/autoconf/generated-configure.sh Changeset: 743f6f484fce Author: kvn Date: 2017-08-29 10:24 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/743f6f484fce 8186462: [Graal] build Graal regardless AOT build Reviewed-by: twisti, thartmann, erikj ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot.m4 Changeset: 3933a3e729f6 Author: jwilhelm Date: 2017-08-28 21:46 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/3933a3e729f6 Merge ! common/autoconf/generated-configure.sh Changeset: 1147dee33745 Author: jwilhelm Date: 2017-08-29 17:17 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/1147dee33745 Merge ! common/autoconf/generated-configure.sh Changeset: 32dc808e9918 Author: bobv Date: 2017-08-29 15:52 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/32dc808e9918 8186248: Allow more flexibility in selecting Heap % of available RAM Reviewed-by: dholmes, drwhite ! make/RunTests.gmk Changeset: fc358dc56d82 Author: bobv Date: 2017-08-31 16:29 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/fc358dc56d82 Merge Changeset: 4c9ee37f0c66 Author: goetz Date: 2017-08-31 17:18 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/4c9ee37f0c66 8186978: Introduce configure argument enable-cds Reviewed-by: dholmes, erikj, ihse ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot.m4 ! common/autoconf/jdk-options.m4 Changeset: 752f5fb6ca0c Author: gziemski Date: 2017-08-31 20:25 -0500 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/752f5fb6ca0c 8173715: Remove FlatProfiler Summary: Obsoleted Xprof flag, removed FlatProfiler code Reviewed-by: dholmes, erikj ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot.m4 Changeset: e747df9efa1e Author: jwilhelm Date: 2017-08-29 17:17 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/e747df9efa1e Merge ! common/autoconf/generated-configure.sh Changeset: 30a5133acb6b Author: glaubitz Date: 2017-08-31 15:47 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/30a5133acb6b 8186786: Name collisions with autoconf definitions on alpha and sh Reviewed-by: ihse, dholmes ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 Changeset: 8625e8491887 Author: ctornqvi Date: 2017-08-31 10:46 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/8625e8491887 8186218: Make JIB exclude webrev from all sub-repo levels when creating source bundles Reviewed-by: erikj, ihse ! common/conf/jib-profiles.js Changeset: 73cb5527d0f7 Author: asaha Date: 2017-09-01 14:13 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/73cb5527d0f7 Added tag jdk-10+22 for changeset 8625e8491887 ! .hgtags Changeset: a8d531abffc8 Author: jwilhelm Date: 2017-09-03 14:19 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/a8d531abffc8 Merge ! common/autoconf/generated-configure.sh Changeset: f93bd12a1dfd Author: shade Date: 2017-09-07 10:38 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/f93bd12a1dfd Merge From ashipile at redhat.com Thu Sep 7 10:16:44 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 07 Sep 2017 10:16:44 +0000 Subject: hg: shenandoah/jdk10/corba: 4 new changesets Message-ID: <201709071016.v87AGiEv003245@aojmv0008.oracle.com> Changeset: 68b5f8eeac33 Author: asaha Date: 2017-08-18 04:37 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/corba/rev/68b5f8eeac33 Added tag jdk-10+20 for changeset 7a54ec280513 ! .hgtags Changeset: 1f4456d51b07 Author: asaha Date: 2017-08-25 04:59 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/corba/rev/1f4456d51b07 Added tag jdk-10+21 for changeset 68b5f8eeac33 ! .hgtags Changeset: 094e4c4e0f9f Author: asaha Date: 2017-09-01 14:13 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/corba/rev/094e4c4e0f9f Added tag jdk-10+22 for changeset 1f4456d51b07 ! .hgtags Changeset: 479805760256 Author: jjg Date: 2017-09-01 11:48 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/corba/rev/479805760256 8186924: Fix accessibility and other HTML issues in java.corba module Reviewed-by: mchung ! src/java.corba/share/classes/org/omg/CORBA/ORB.java ! src/java.corba/share/classes/org/omg/CORBA/TCKind.java ! src/java.corba/share/classes/org/omg/CORBA/doc-files/compliance.html ! src/java.corba/share/classes/org/omg/CORBA/doc-files/generatedfiles.html ! src/java.corba/share/classes/org/omg/PortableInterceptor/Interceptors.idl From ashipile at redhat.com Thu Sep 7 10:16:46 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 07 Sep 2017 10:16:46 +0000 Subject: hg: shenandoah/jdk10/jaxws: 4 new changesets Message-ID: <201709071016.v87AGk20003257@aojmv0008.oracle.com> Changeset: 30ed8fb6a1d1 Author: asaha Date: 2017-08-18 04:37 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jaxws/rev/30ed8fb6a1d1 Added tag jdk-10+20 for changeset 1658a5e7d171 ! .hgtags Changeset: c162c9e4c9c0 Author: asaha Date: 2017-08-25 04:59 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jaxws/rev/c162c9e4c9c0 Added tag jdk-10+21 for changeset 30ed8fb6a1d1 ! .hgtags Changeset: 786c1a5c82d9 Author: asaha Date: 2017-09-01 14:13 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jaxws/rev/786c1a5c82d9 Added tag jdk-10+22 for changeset c162c9e4c9c0 ! .hgtags Changeset: 3aaaaf69b6c3 Author: jjg Date: 2017-09-01 14:06 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jaxws/rev/3aaaaf69b6c3 8186947: Fix accessibility and other issues in the java.xml.ws module Reviewed-by: lancea, mchung, darcy ! src/java.xml.bind/share/classes/javax/xml/bind/JAXBPermission.java ! src/java.xml.bind/share/classes/javax/xml/bind/Marshaller.java ! src/java.xml.bind/share/classes/javax/xml/bind/Unmarshaller.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlNsForm.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/XmlType.java ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/adapters/package-info.java - src/java.xml.bind/share/classes/javax/xml/bind/annotation/adapters/package.html ! src/java.xml.bind/share/classes/javax/xml/bind/annotation/package.html ! src/java.xml.bind/share/classes/javax/xml/bind/attachment/AttachmentUnmarshaller.java ! src/java.xml.bind/share/classes/javax/xml/bind/helpers/package-info.java - src/java.xml.bind/share/classes/javax/xml/bind/helpers/package.html ! src/java.xml.bind/share/classes/javax/xml/bind/util/package-info.java - src/java.xml.bind/share/classes/javax/xml/bind/util/package.html ! src/java.xml.ws/share/classes/javax/xml/ws/wsaddressing/W3CEndpointReferenceBuilder.java From ashipile at redhat.com Thu Sep 7 10:16:47 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 07 Sep 2017 10:16:47 +0000 Subject: hg: shenandoah/jdk10/nashorn: 10 new changesets Message-ID: <201709071016.v87AGlru003313@aojmv0008.oracle.com> Changeset: 991330e43c22 Author: asaha Date: 2017-08-18 04:37 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/nashorn/rev/991330e43c22 Added tag jdk-10+20 for changeset 9133969febb5 ! .hgtags Changeset: 6b8802e1dab8 Author: iignatyev Date: 2017-08-20 20:36 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/nashorn/rev/6b8802e1dab8 8186095: upgrade to jtreg 4.2 b08 Reviewed-by: rriggs, mchung, dholmes, iklam ! test/TEST.ROOT Changeset: 03d3d3c6bc5a Author: pmuthuswamy Date: 2017-08-21 11:33 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/nashorn/rev/03d3d3c6bc5a 8175362: StringIndexOutOfBoundsException from /.*((a[^a]+){2})c$/.exec('ababc') Reviewed-by: sundar, hannesw Contributed-by: priya.muthuswamy at oracle.com ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Analyser.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/regexp/joni/Regex.java + test/script/basic/JDK-8175362.js + test/script/basic/JDK-8175362.js.EXPECTED Changeset: b1b810f62830 Author: asaha Date: 2017-08-25 04:59 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/nashorn/rev/b1b810f62830 Added tag jdk-10+21 for changeset 03d3d3c6bc5a ! .hgtags Changeset: b8976a6ed2bc Author: hannesw Date: 2017-08-30 18:47 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/nashorn/rev/b8976a6ed2bc 8184723: jdk.nashorn.internal.runtime.linker.JSObjectLinker.callToApply erroneously asserts given arguments Reviewed-by: sundar, hannesw Contributed-by: priya.lakshmi.muthuswamy at oracle.com ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/JSObjectLinker.java + test/src/jdk/nashorn/internal/runtime/linker/test/JDK_8184723_Test.java Changeset: ce5973feed58 Author: sdama Date: 2017-09-01 06:01 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/nashorn/rev/ce5973feed58 8177691: Labeled break in catch and finally works wrongly, when invoked through nashorn Summary: Added support to check if the block contains goto statements before flagging it as terminal Reviewed-by: hannesw, jlaskey Contributed-by: srinivas.dama at oracle.com ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/Block.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8177691.js + test/script/basic/JDK-8177691.js.EXPECTED Changeset: 545d7d2a70a8 Author: sdama Date: 2017-09-01 07:07 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/nashorn/rev/545d7d2a70a8 8073640: Nashorn scripting: here document with only whitespace gives error Summary: Added support for handling trailing blank lines in here-doc string parsing Reviewed-by: hannesw, jlaskey Contributed-by: srinivas.dama at oracle.com ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/parser/Lexer.java + test/script/basic/JDK-8073640.js + test/script/basic/JDK-8073640.js.EXPECTED Changeset: bd933afd9e2e Author: sdama Date: 2017-09-01 07:55 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/nashorn/rev/bd933afd9e2e 8184720: Nashorn engine in strict mode throws a java.lang.ClassCastException when calling apply() and passing the arguments object Summary: Fixed needsCallee method to return true properly in strict mode Reviewed-by: hannesw, sundar Contributed-by: srinivas.dama at oracle.com ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/ir/FunctionNode.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/ScriptFunctionData.java + test/script/basic/JDK-8184720.js Changeset: bea304c9ee43 Author: asaha Date: 2017-09-01 14:13 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/nashorn/rev/bea304c9ee43 Added tag jdk-10+22 for changeset bd933afd9e2e ! .hgtags Changeset: f5bdafee7f93 Author: hannesw Date: 2017-09-02 14:26 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/nashorn/rev/f5bdafee7f93 8169233: LengthNotWritableFilter extraElements.remove(index) has no effect Reviewed-by: sundar, jlaskey Contributed-by: priya.lakshmi.muthuswamy at oracle.com ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/arrays/LengthNotWritableFilter.java ! test/script/basic/JDK-8035312.js.EXPECTED + test/script/basic/JDK-8169233.js + test/script/basic/JDK-8169233.js.EXPECTED From ashipile at redhat.com Thu Sep 7 10:16:49 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 07 Sep 2017 10:16:49 +0000 Subject: hg: shenandoah/jdk10/langtools: 17 new changesets Message-ID: <201709071016.v87AGogU003346@aojmv0008.oracle.com> Changeset: d78323fc3fd5 Author: rfield Date: 2017-08-16 18:42 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/d78323fc3fd5 8182270: JShell API: Tools need snippet information without evaluating snippet 8166334: jshell tool: shortcut: expression/statement to method Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties ! src/jdk.jshell/share/classes/jdk/jshell/Eval.java ! src/jdk.jshell/share/classes/jdk/jshell/JShell.java ! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! src/jdk.jshell/share/classes/jdk/jshell/resources/l10n.properties + test/jdk/jshell/AnalyzeSnippetTest.java - test/jdk/jshell/MergedTabShiftTabCommandTest.java - test/jdk/jshell/MergedTabShiftTabExpressionTest.java + test/jdk/jshell/ToolShiftTabTest.java + test/jdk/jshell/ToolTabCommandTest.java + test/jdk/jshell/ToolTabSnippetTest.java Changeset: 76066b4d5a9b Author: asaha Date: 2017-08-18 04:37 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/76066b4d5a9b Added tag jdk-10+20 for changeset d78323fc3fd5 ! .hgtags Changeset: c286cfbac9ff Author: iignatyev Date: 2017-08-20 20:36 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/c286cfbac9ff 8186095: upgrade to jtreg 4.2 b08 Reviewed-by: rriggs, mchung, dholmes, iklam ! test/TEST.ROOT Changeset: 97a0023f80b1 Author: anazarov Date: 2017-08-18 15:58 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/97a0023f80b1 8186020: jdk/javadoc/tool/exceptionHandling/TestExceptionHandling.java fails Reviewed-by: jjg, ksrini ! test/jdk/javadoc/tool/exceptionHandling/TestExceptionHandling.java Changeset: 0389651da2f9 Author: mullan Date: 2017-08-21 14:04 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/0389651da2f9 8159544: Remove deprecated classes in com.sun.security.auth.** Reviewed-by: jlahoda, vinnie, weijun ! make/data/symbols/include.list Changeset: af9949dfa189 Author: mullan Date: 2017-08-21 14:09 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/af9949dfa189 Merge Changeset: 3bac44d95028 Author: rfield Date: 2017-08-21 08:29 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/3bac44d95028 8186475: JShell API: remove trailing HTML paragraph tag Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java Changeset: 1751f253e424 Author: vromero Date: 2017-08-21 16:37 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/1751f253e424 8160396: test for fix for JDK-8159439 can't be included till CODETOOLS-7901710 is fixed Reviewed-by: jjg ! test/ProblemList.txt Changeset: 0a169aac4d5c Author: jlahoda Date: 2017-08-22 13:10 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/0a169aac4d5c 8182297: jshell tool: pasting multiple lines of code truncated Summary: Read input needs to be kept across ConsoleReader.readLine invocations unless consumed. Reviewed-by: rfield, rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java + test/jdk/jshell/PasteAndMeasurementsUITest.java ! test/jdk/jshell/UITesting.java Changeset: 35f9b3d5e231 Author: rfield Date: 2017-08-22 23:26 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/35f9b3d5e231 8186636: JShell tests: jtreg_4.2-b08 breaks ComputeFQNsTest.testAddImport() Reviewed-by: jlahoda ! test/jdk/jshell/ComputeFQNsTest.java Changeset: 5e5a17a1d918 Author: jjg Date: 2017-08-23 10:53 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/5e5a17a1d918 8186460: Fix stylesheet to better display multi-row headers in "striped" tables. Reviewed-by: bpatel ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Changeset: fd3ce6210d0c Author: rfield Date: 2017-08-23 14:06 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/fd3ce6210d0c 8185108: JShell: NullPointerException when throwing exception with null message under local ExecutionControl Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/jshell/Eval.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/ExecutionControlForwarder.java ! src/jdk.jshell/share/classes/jdk/jshell/execution/StreamingExecutionControl.java + test/jdk/jshell/ExceptionMessageTest.java Changeset: 1e2a4e07bc70 Author: bpatel Date: 2017-08-24 12:32 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/1e2a4e07bc70 8182263: Search box and reset button needs to be a11y fixed. Reviewed-by: jjg, ksrini ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlAttr.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTag.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java Changeset: 4d1728416123 Author: asaha Date: 2017-08-25 04:59 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/4d1728416123 Added tag jdk-10+21 for changeset fd3ce6210d0c ! .hgtags Changeset: 151a41bda28e Author: asaha Date: 2017-08-25 05:02 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/151a41bda28e Merge Changeset: 9fa96500eb15 Author: jlahoda Date: 2017-08-25 13:48 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/9fa96500eb15 8185426: Jshell crashing on autocompletion Summary: Properly canceling completion on if needed. Reviewed-by: rfield ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java + src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContextTestSupport.java ! test/jdk/jshell/ToolTabSnippetTest.java Changeset: 214ffa12262b Author: asaha Date: 2017-09-01 14:13 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/214ffa12262b Added tag jdk-10+22 for changeset 9fa96500eb15 ! .hgtags From ashipile at redhat.com Thu Sep 7 10:17:09 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 07 Sep 2017 10:17:09 +0000 Subject: hg: shenandoah/jdk10/jdk: 66 new changesets Message-ID: <201709071017.v87AHCn6003678@aojmv0008.oracle.com> Changeset: 7c72edeae31b Author: sherman Date: 2017-08-16 13:15 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/7c72edeae31b 8186227: jdk/nio/zipfs/ZeroDate.java fails on Windows with "IllegalArgumentException: Illegal character in opaque part at index 13" Reviewed-by: rriggs ! test/jdk/nio/zipfs/ZeroDate.java Changeset: 6256e94781f5 Author: rriggs Date: 2017-08-16 16:46 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/6256e94781f5 8185346: Relax RMI Registry Serial Filter to allow arrays of any type Summary: Registry filter should allow arrays of any type Reviewed-by: dfuchs, smarks, coffeys ! src/java.base/share/classes/java/io/ObjectInputFilter.java + src/java.base/share/classes/jdk/internal/misc/JavaObjectInputFilterAccess.java ! src/java.base/share/classes/jdk/internal/misc/SharedSecrets.java ! src/java.base/share/conf/security/java.security ! src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java ! test/java/rmi/registry/serialFilter/RegistryFilterTest.java Changeset: 46d6f1587c45 Author: dfuchs Date: 2017-08-17 16:48 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/46d6f1587c45 8177935: java/net/httpclient/http2/FixedThreadPoolTest.java fails frequently Summary: fixes a race condition in AsyncWriteQueue Reviewed-by: chegar ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/AsyncSSLDelegate.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/PlainHttpConnection.java ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/internal/common/AsyncWriteQueue.java ! test/java/net/httpclient/http2/FixedThreadPoolTest.java Changeset: 402802492f6a Author: jwilhelm Date: 2017-08-17 19:35 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/402802492f6a Merge Changeset: 51f1ea2a3d3f Author: asaha Date: 2017-08-18 04:36 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/51f1ea2a3d3f Added tag jdk-10+20 for changeset 6256e94781f5 ! .hgtags Changeset: 12a8913e9a04 Author: jwilhelm Date: 2017-08-18 18:39 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/12a8913e9a04 Merge Changeset: 0e47241756ce Author: hseigel Date: 2017-08-18 15:07 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/0e47241756ce 8168677: Typo in API docs for com.sun.tools.attach Summary: Change "VirtalMachine" to "VirtualMachine" Reviewed-by: dholmes ! src/jdk.attach/share/classes/com/sun/tools/attach/AttachNotSupportedException.java ! src/jdk.attach/share/classes/com/sun/tools/attach/AttachPermission.java Changeset: 4469f4504558 Author: iignatyev Date: 2017-08-20 20:36 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/4469f4504558 8186095: upgrade to jtreg 4.2 b08 Reviewed-by: rriggs, mchung, dholmes, iklam ! test/TEST.ROOT Changeset: c0d1ba0e9039 Author: mullan Date: 2017-08-21 14:05 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/c0d1ba0e9039 8159544: Remove deprecated classes in com.sun.security.auth.** Reviewed-by: jlahoda, vinnie, weijun ! make/mapfiles/libjaas/mapfile-vers ! src/java.base/share/classes/javax/security/auth/Policy.java ! src/java.base/share/classes/sun/security/util/AuthResources.java ! src/java.base/share/classes/sun/security/util/AuthResources_de.java ! src/java.base/share/classes/sun/security/util/AuthResources_es.java ! src/java.base/share/classes/sun/security/util/AuthResources_fr.java ! src/java.base/share/classes/sun/security/util/AuthResources_it.java ! src/java.base/share/classes/sun/security/util/AuthResources_ja.java ! src/java.base/share/classes/sun/security/util/AuthResources_ko.java ! src/java.base/share/classes/sun/security/util/AuthResources_pt_BR.java ! src/java.base/share/classes/sun/security/util/AuthResources_sv.java ! src/java.base/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/java.base/share/classes/sun/security/util/AuthResources_zh_TW.java - src/jdk.security.auth/share/classes/com/sun/security/auth/PolicyFile.java - src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisPrincipal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/X500Principal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/module/SolarisLoginModule.java - src/jdk.security.auth/share/classes/com/sun/security/auth/module/SolarisSystem.java - src/jdk.security.auth/solaris/native/libjaas/Solaris.c ! test/javax/security/auth/PrivateCredentialPermission/Subset.java ! test/javax/security/auth/PrivateCredentialPermission/Subset.policy ! test/sun/security/provider/PolicyFile/Comparator.java Changeset: cbc248de6505 Author: shshahma Date: 2017-08-18 04:34 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/cbc248de6505 8169961: Memory leak after debugging session Summary: TargetVM gets an EventController which is a daemon thread, but don't see the thread having a way of stopping so added code to exit as soon as TargetVM thread stops listening. Reviewed-by: clanger, dcubed, sspitsyn ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TargetVM.java Changeset: 3f515b6a5c99 Author: kevinw Date: 2017-08-21 14:14 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/3f515b6a5c99 Merge - src/jdk.security.auth/share/classes/com/sun/security/auth/PolicyFile.java - src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisPrincipal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/X500Principal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/module/SolarisLoginModule.java - src/jdk.security.auth/share/classes/com/sun/security/auth/module/SolarisSystem.java - src/jdk.security.auth/solaris/native/libjaas/Solaris.c Changeset: 18ad35f03feb Author: redestad Date: 2017-08-22 07:52 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/18ad35f03feb 8186334: JarFile throws ArrayIndexOutOfBoundsException when the manifest contains certain characters Reviewed-by: psandoz, bchristi ! src/java.base/share/classes/java/util/jar/JarFile.java + test/java/util/jar/JarFile/JarBacktickManifest.java Changeset: 3511038b4184 Author: redestad Date: 2017-08-22 07:52 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/3511038b4184 8185362: Replace use of AtomicReferenceFieldUpdater from BufferedInputStream with Unsafe Reviewed-by: shade, martin, sherman ! src/java.base/share/classes/java/io/BufferedInputStream.java Changeset: 9897b39e5965 Author: nishjain Date: 2017-08-22 12:04 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/9897b39e5965 6609718: [Fmt-Ch] uninformative exception in ChoiceFormat.applyPattern(String) Reviewed-by: naoto Contributed-by: nishit.jain at oracle.com ! src/java.base/share/classes/java/text/ChoiceFormat.java Changeset: 16daa56570b8 Author: jwilhelm Date: 2017-08-22 16:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/16daa56570b8 Merge Changeset: 1f8498df012c Author: sspitsyn Date: 2017-08-28 00:49 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/1f8498df012c 8186776: use ReleaseStringUTFChars instead of jvmtiDeallocate to release strings Summary: Replace jvmtiDeallocate with ReleaseStringUTFChars Reviewed-by: sspitsyn, clanger Contributed-by: groeges at uk.ibm.com ! src/jdk.jdwp.agent/share/native/libjdwp/ModuleReferenceImpl.c Changeset: e78706585c43 Author: sspitsyn Date: 2017-08-28 07:53 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/e78706585c43 Merge - src/jdk.security.auth/share/classes/com/sun/security/auth/PolicyFile.java - src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisPrincipal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/X500Principal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/module/SolarisLoginModule.java - src/jdk.security.auth/share/classes/com/sun/security/auth/module/SolarisSystem.java - src/jdk.security.auth/solaris/native/libjaas/Solaris.c Changeset: f049b1fd90c3 Author: jlahoda Date: 2017-08-22 13:08 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/f049b1fd90c3 8182297: jshell tool: pasting multiple lines of code truncated Summary: Read input needs to be kept across ConsoleReader.readLine invocations unless consumed. Reviewed-by: rfield ! src/jdk.internal.le/share/classes/jdk/internal/jline/console/ConsoleReader.java Changeset: 2f3d9ed99e66 Author: rriggs Date: 2017-08-22 09:41 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/2f3d9ed99e66 8173817: StackOverflowError in "process reaper" thread Summary: Switch to inner class to avoid lambda stack overhead in ProcessReaper Reviewed-by: dholmes, martin ! src/java.base/share/classes/java/lang/ProcessHandleImpl.java Changeset: fe799975105c Author: jwilhelm Date: 2017-08-22 16:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/fe799975105c Merge Changeset: eef928e08804 Author: ssahoo Date: 2017-08-23 09:13 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/eef928e08804 8183310: java/security/modules/ModularTest.java should clean up better Summary: This require cleaning up Test files. Reviewed-by: weijun ! test/java/security/Provider/SecurityProviderModularTest.java + test/java/security/Provider/TestClient.java + test/java/security/Provider/TestProvider.java - test/java/security/Provider/TestSecurityProvider.java - test/java/security/Provider/TestSecurityProviderClient.java - test/java/security/modules/ModularTest.java ! test/javax/security/auth/login/modules/JaasClient.java ! test/javax/security/auth/login/modules/JaasClientWithDefaultHandler.java ! test/javax/security/auth/login/modules/JaasModularClientTest.java ! test/javax/security/auth/login/modules/JaasModularDefaultHandlerTest.java - test/javax/security/auth/login/modules/TEST.properties ! test/javax/security/auth/login/modules/TestLoginModule.java Changeset: d32fe43af590 Author: lancea Date: 2017-08-23 12:24 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/d32fe43af590 8184120: javax.transaction.xa.Xid fields reference obsolete method names Reviewed-by: psandoz ! src/java.sql/share/classes/javax/transaction/xa/Xid.java Changeset: 46e9f2b0a472 Author: jjg Date: 2017-08-23 10:58 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/46e9f2b0a472 8186466: Fix accessibility and other minor issues in java.base Reviewed-by: mchung, naoto, martin ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/doc-files/ValueBased.html - src/java.base/share/classes/java/lang/doc-files/capchi.gif - src/java.base/share/classes/java/lang/doc-files/capiota.gif - src/java.base/share/classes/java/lang/doc-files/capsigma.gif - src/java.base/share/classes/java/lang/doc-files/captheta.gif - src/java.base/share/classes/java/lang/doc-files/capupsil.gif - src/java.base/share/classes/java/lang/doc-files/chi.gif - src/java.base/share/classes/java/lang/doc-files/iota.gif - src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc21.gif - src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc38.gif - src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc40.gif - src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc41.gif - src/java.base/share/classes/java/lang/doc-files/sigma1.gif - src/java.base/share/classes/java/lang/doc-files/theta.gif ! src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html - src/java.base/share/classes/java/lang/doc-files/upsilon.gif ! src/java.base/share/classes/java/time/format/DateTimeFormatter.java ! src/java.base/share/classes/java/util/Deque.java ! src/java.base/share/classes/java/util/Queue.java ! src/java.base/share/classes/java/util/ResourceBundle.java ! src/java.base/share/classes/java/util/concurrent/BlockingDeque.java ! src/java.base/share/classes/java/util/concurrent/BlockingQueue.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java ! src/java.base/share/classes/java/util/doc-files/coll-designfaq.html ! src/java.base/share/classes/java/util/doc-files/coll-index.html ! src/java.base/share/classes/java/util/doc-files/coll-overview.html ! src/java.base/share/classes/java/util/doc-files/coll-reference.html ! src/java.base/share/classes/java/util/regex/Pattern.java ! src/java.base/share/classes/java/util/spi/CalendarNameProvider.java Changeset: 49163d0109ec Author: sherman Date: 2017-08-23 21:27 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/49163d0109ec 8186142: ZipPath.{starts,ends}With(nonZipPath) throws an exception, but should return false Reviewed-by: martin ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java ! test/jdk/nio/zipfs/PathOps.java Changeset: 4e08a69241ea Author: redestad Date: 2017-08-24 15:03 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/4e08a69241ea 8186500: StringConcatFactory.makeConcatWithConstants throws AssertionError when recipe contains non-String constants Reviewed-by: shade, psandoz ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! test/java/lang/String/concat/StringConcatFactoryInvariants.java Changeset: df236bc94cde Author: vinnie Date: 2017-08-24 16:49 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/df236bc94cde 8173181: Empty string alias in KeyStore throws StringIndexOutOfBoundsException for getEntry() Reviewed-by: weijun ! src/java.base/share/classes/java/security/PKCS12Attribute.java + test/sun/security/pkcs12/EmptyAlias.java Changeset: c05f834c3e7b Author: iignatyev Date: 2017-08-24 15:40 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/c05f834c3e7b 8186613: remove ClassFileInstaller from jdk/test/lib/testlibrary Reviewed-by: mchung, igerasim ! test/jdk/internal/reflect/AnonymousNewInstance/ManyNewInstanceAnonTest.java - test/lib/testlibrary/ClassFileInstaller.java Changeset: a483aac4000b Author: jjg Date: 2017-08-24 16:52 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/a483aac4000b 8186684: Fix broken links in java.base API docs Reviewed-by: sherman, martin, mchung, bpb, lancea ! src/java.base/share/classes/java/lang/BootstrapMethodError.java ! src/java.base/share/classes/java/lang/ModuleLayer.java ! src/java.base/share/classes/java/lang/ProcessBuilder.java ! src/java.base/share/classes/java/lang/invoke/MethodHandle.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/VarHandle.java ! src/java.base/share/classes/java/lang/module/Configuration.java ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! src/java.base/share/classes/java/net/URLStreamHandler.java ! src/java.base/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java ! src/java.base/share/classes/java/nio/channels/spi/AbstractSelector.java ! src/java.base/share/classes/java/nio/file/FileSystems.java ! src/java.base/share/classes/java/nio/file/attribute/AclEntry.java ! src/java.base/share/classes/java/util/Calendar.java ! src/java.base/share/classes/java/util/Collection.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/java.base/share/classes/java/util/jar/package-info.java ! src/java.base/share/classes/java/util/stream/package-info.java ! src/java.base/share/classes/java/util/zip/Deflater.java ! src/java.base/share/classes/java/util/zip/Inflater.java Changeset: fa7582840977 Author: weijun Date: 2017-08-25 09:28 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/fa7582840977 8186576: KerberosTicket does not properly handle renewable tickets at the end of their lifetime Reviewed-by: xuelei ! src/java.security.jgss/share/classes/javax/security/auth/kerberos/KerberosTicket.java ! src/java.security.jgss/share/classes/sun/security/krb5/KrbTgsReq.java ! src/jdk.security.auth/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! test/sun/security/krb5/auto/KDC.java + test/sun/security/krb5/auto/NullRenewUntil.java Changeset: 820a3631d030 Author: asaha Date: 2017-08-25 04:59 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/820a3631d030 Added tag jdk-10+21 for changeset 4e08a69241ea ! .hgtags Changeset: 40dec428648e Author: asaha Date: 2017-08-25 05:02 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/40dec428648e Merge - test/lib/testlibrary/ClassFileInstaller.java Changeset: 7dec03b77b26 Author: bchristi Date: 2017-08-25 10:39 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/7dec03b77b26 8186217: Remove erroneous @hidden JavaDoc tag from java.util.Properties.replace(Object, Object, Object) Reviewed-by: bpb, naoto ! src/java.base/share/classes/java/util/Properties.java Changeset: 603393a94dd7 Author: bpb Date: 2017-08-25 10:43 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/603393a94dd7 8186707: Remove libnio FileChannelImpl native close0() function Summary: Remove Java_sun_nio_ch_FileChannelImpl_close0() on Unix and Windows and Java_sun_nio_ch_FileDispatcherImpl_closeByHandle on Windows only Reviewed-by: alanb ! make/mapfiles/libnio/mapfile-linux ! make/mapfiles/libnio/mapfile-macosx ! make/mapfiles/libnio/mapfile-solaris ! src/java.base/unix/native/libnio/ch/FileChannelImpl.c ! src/java.base/windows/classes/sun/nio/ch/FileDispatcherImpl.java ! src/java.base/windows/native/libnio/ch/FileChannelImpl.c ! src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c Changeset: 162c0a6e1fe3 Author: mchung Date: 2017-08-25 10:52 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/162c0a6e1fe3 8186145: tools/launcher/modules/validate/ValidateModulesTest.java fails when launched with -XX:+EnableJVMCI Summary: --validate-modules runs with a boot layer resolving all system modules rather than only java.base Reviewed-by: alanb ! src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java ! src/java.base/share/native/libjli/java.c Changeset: daed9a0332d3 Author: jwilhelm Date: 2017-08-28 21:46 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/daed9a0332d3 Merge - src/java.base/share/classes/java/lang/doc-files/capchi.gif - src/java.base/share/classes/java/lang/doc-files/capiota.gif - src/java.base/share/classes/java/lang/doc-files/capsigma.gif - src/java.base/share/classes/java/lang/doc-files/captheta.gif - src/java.base/share/classes/java/lang/doc-files/capupsil.gif - src/java.base/share/classes/java/lang/doc-files/chi.gif - src/java.base/share/classes/java/lang/doc-files/iota.gif - src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc21.gif - src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc38.gif - src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc40.gif - src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc41.gif - src/java.base/share/classes/java/lang/doc-files/sigma1.gif - src/java.base/share/classes/java/lang/doc-files/theta.gif - src/java.base/share/classes/java/lang/doc-files/upsilon.gif - test/java/security/Provider/TestSecurityProvider.java - test/java/security/Provider/TestSecurityProviderClient.java - test/java/security/modules/ModularTest.java - test/javax/security/auth/login/modules/TEST.properties - test/lib/testlibrary/ClassFileInstaller.java Changeset: 965d4dde0086 Author: naoto Date: 2017-08-28 10:16 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/965d4dde0086 8171049: Era.getDisplayName doesn't work with non-IsoChronology Reviewed-by: rriggs ! src/java.base/share/classes/java/time/chrono/HijrahEra.java ! src/java.base/share/classes/java/time/chrono/JapaneseEra.java ! src/java.base/share/classes/java/time/chrono/MinguoEra.java ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistEra.java + test/java/time/test/java/time/chrono/TestEraDisplayName.java Changeset: a03402163220 Author: rriggs Date: 2017-08-28 13:21 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/a03402163220 8186539: [testlibrary] TestSocketFactory should allow triggers before match/replace Reviewed-by: smarks ! test/java/rmi/testlibrary/TestSocketFactory.java Changeset: 9c9efd97932e Author: jwilhelm Date: 2017-08-28 21:46 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/9c9efd97932e Merge Changeset: ebdaa1e7ab33 Author: xuelei Date: 2017-08-29 00:01 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/ebdaa1e7ab33 8179654: New JDK 9 typos in SSLEngineResult Reviewed-by: ascarpino, wetmore ! src/java.base/share/classes/javax/net/ssl/SSLEngineResult.java Changeset: 73f03af58164 Author: nishjain Date: 2017-08-29 12:16 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/73f03af58164 8186713: Document default rounding mode in NumberFormat Reviewed-by: naoto, bpb Contributed-by: nishit.jain at oracle.com ! src/java.base/share/classes/java/text/NumberFormat.java ! src/java.base/share/classes/java/util/Formatter.java Changeset: ab44eeefaac9 Author: jwilhelm Date: 2017-08-29 17:17 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/ab44eeefaac9 Merge Changeset: b55a87e91529 Author: jwilhelm Date: 2017-08-29 22:15 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/b55a87e91529 Merge Changeset: 9ab6150be6c0 Author: dsamersoff Date: 2017-08-31 21:31 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/9ab6150be6c0 8061228: Allow JDWP socket connector to accept connections from certain ip addresses only Summary: Introduce new parameter for JDWP agent, that allows to restrict connection to certain ip addresses only Reviewed-by: dcubed, clanger, rehn, sspitsyn ! src/jdk.jdwp.agent/share/native/include/jdwpTransport.h ! src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c ! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c ! src/jdk.jdwp.agent/share/native/libjdwp/transport.c ! src/jdk.jdwp.agent/share/native/libjdwp/transport.h + test/com/sun/jdi/BasicJDWPConnectionTest.java Changeset: e6f271a20de8 Author: gziemski Date: 2017-08-31 20:25 -0500 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/e6f271a20de8 8173715: Remove FlatProfiler Summary: Obsoleted Xprof flag, removed FlatProfiler code Reviewed-by: mchung ! src/java.base/share/classes/sun/launcher/resources/launcher.properties ! src/linux/doc/man/java.1 ! src/solaris/doc/sun/man/man1/java.1 Changeset: 90d550ad1fba Author: gziemski Date: 2017-09-01 13:03 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/90d550ad1fba Merge Changeset: 800352238173 Author: xiaofeya Date: 2017-08-29 07:16 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/800352238173 8186818: Enable debug option for TcpTest.java Reviewed-by: rriggs ! test/java/net/ipv6tests/TcpTest.java Changeset: 5835fd994586 Author: uvangapally Date: 2017-08-29 20:23 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/5835fd994586 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException Summary: Edited policy files to grant permissions to all drives on windows Reviewed-by: hb, clanger Contributed-by: ujwal.vangapally at oracle.com ! test/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java ! test/javax/management/remote/mandatory/subjectDelegation/policy11 ! test/javax/management/remote/mandatory/subjectDelegation/policy12 ! test/javax/management/remote/mandatory/subjectDelegation/policy13 ! test/javax/management/remote/mandatory/subjectDelegation/policy14 ! test/javax/management/remote/mandatory/subjectDelegation/policy15 ! test/javax/management/remote/mandatory/subjectDelegation/policy16 ! test/javax/management/remote/mandatory/subjectDelegation/policy21 ! test/javax/management/remote/mandatory/subjectDelegation/policy22 ! test/javax/management/remote/mandatory/subjectDelegation/policy23 ! test/javax/management/remote/mandatory/subjectDelegation/policy24 ! test/javax/management/remote/mandatory/subjectDelegation/policy25 ! test/javax/management/remote/mandatory/subjectDelegation/policy31 ! test/javax/management/remote/mandatory/subjectDelegation/policy32 ! test/javax/management/remote/mandatory/subjectDelegation/policy33 ! test/javax/management/remote/mandatory/subjectDelegation/policy34 ! test/javax/management/remote/mandatory/subjectDelegation/policy35 Changeset: 84953f6385d7 Author: goetz Date: 2017-08-29 17:29 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/84953f6385d7 8186719: [testbug] add @requires vm.cds to CDS tests in jdk test suite Reviewed-by: dholmes, iklam ! test/TEST.ROOT ! test/com/sun/jdi/cds/CDSBreakpointTest.java ! test/com/sun/jdi/cds/CDSDeleteAllBkptsTest.java ! test/com/sun/jdi/cds/CDSFieldWatchpoints.java Changeset: ff2928f81829 Author: smarks Date: 2017-08-29 12:16 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/ff2928f81829 8186851: fix misspellings of "dependent" and "independent" in the JDK repo Reviewed-by: bpb, psadhukhan ! src/java.base/share/classes/java/text/Collator.java ! src/java.base/share/classes/java/text/NumberFormat.java ! src/java.base/share/classes/sun/nio/ch/Net.java ! src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m ! src/java.desktop/share/classes/java/awt/EventQueue.java ! src/java.desktop/share/classes/javax/sound/midi/MidiDevice.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicToolTipUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalInternalFrameTitlePane.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTitlePane.java ! src/java.desktop/share/classes/javax/swing/text/GlyphView.java ! src/java.desktop/share/classes/javax/swing/text/TableView.java ! src/jdk.internal.le/share/classes/jdk/internal/jline/console/ConsoleReader.java ! src/jdk.sctp/share/classes/com/sun/nio/sctp/package-info.java ! test/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/togglebutton/LayoutControlPanel.java Changeset: c8796a577885 Author: jwilhelm Date: 2017-08-29 17:17 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/c8796a577885 Merge Changeset: ec5f5233791e Author: redestad Date: 2017-08-30 18:45 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/ec5f5233791e 8186930: Constant fold URI constants Reviewed-by: alanb, chegar ! src/java.base/share/classes/java/net/URI.java ! src/java.base/share/classes/sun/net/www/ParseUtil.java Changeset: 787703ab9a62 Author: sherman Date: 2017-08-30 10:09 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/787703ab9a62 8186801: Add regression test to test mapping based charsets (generated at build time) Reviewed-by: alanb + make/data/charsetmapping/Big5_HKSCS.c2b + make/data/charsetmapping/Big5_HKSCS.map + make/data/charsetmapping/Big5_HKSCS.nr + make/data/charsetmapping/Big5_Solaris.map + make/data/charsetmapping/EUC_JP.map + make/data/charsetmapping/EUC_JP_LINUX.map + make/data/charsetmapping/EUC_JP_Open.map + make/data/charsetmapping/EUC_TW.map + make/data/charsetmapping/EUC_TW.nr + make/data/charsetmapping/GB18030.map + make/data/charsetmapping/IBM1140.nr + make/data/charsetmapping/IBM1141.nr + make/data/charsetmapping/IBM1142.nr + make/data/charsetmapping/IBM1143.nr + make/data/charsetmapping/IBM1144.nr + make/data/charsetmapping/IBM1145.nr + make/data/charsetmapping/IBM1146.nr + make/data/charsetmapping/IBM1147.nr + make/data/charsetmapping/IBM1148.nr + make/data/charsetmapping/IBM1149.nr + make/data/charsetmapping/MS950_HKSCS_XP.map ! make/data/charsetmapping/charsets - make/data/charsetmapping/euc_tw.map ! make/src/classes/build/tools/charsetmapping/EUC_TW.java ! src/jdk.charsets/share/classes/sun/nio/cs/ext/MS932_0213.java ! src/jdk.charsets/share/classes/sun/nio/cs/ext/SJIS_0213.java ! test/sun/nio/cs/EuroConverter.java + test/sun/nio/cs/TestCharsetMapping.java + test/sun/nio/cs/TestEBCDICLineFeed.java Changeset: 06168eefa456 Author: redestad Date: 2017-08-30 20:12 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/06168eefa456 8186517: sun.nio.cs.StandardCharsets$Aliases and Classes can be lazily loaded Reviewed-by: sherman, martin, plevart ! make/src/classes/build/tools/charsetmapping/DBCS.java ! make/src/classes/build/tools/charsetmapping/SBCS.java ! make/src/classes/build/tools/charsetmapping/SPI.java ! make/src/classes/build/tools/charsetmapping/SRC.java ! src/java.base/share/classes/java/lang/StringCoding.java ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/java/nio/charset/StandardCharsets.java ! src/java.base/share/classes/sun/nio/cs/CESU_8.java ! src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java ! src/java.base/share/classes/sun/nio/cs/StandardCharsets.java.template ! src/java.base/share/classes/sun/nio/cs/US_ASCII.java ! src/java.base/share/classes/sun/nio/cs/UTF_16.java ! src/java.base/share/classes/sun/nio/cs/UTF_16BE.java ! src/java.base/share/classes/sun/nio/cs/UTF_16LE.java ! src/java.base/share/classes/sun/nio/cs/UTF_16LE_BOM.java ! src/java.base/share/classes/sun/nio/cs/UTF_32.java ! src/java.base/share/classes/sun/nio/cs/UTF_32BE.java ! src/java.base/share/classes/sun/nio/cs/UTF_32BE_BOM.java ! src/java.base/share/classes/sun/nio/cs/UTF_32LE.java ! src/java.base/share/classes/sun/nio/cs/UTF_32LE_BOM.java ! src/java.base/share/classes/sun/nio/cs/UTF_8.java Changeset: 4ab6d768430f Author: naoto Date: 2017-08-30 11:37 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/4ab6d768430f 8179246:  /  are literally visible in javadoc Reviewed-by: jjg ! src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java Changeset: 83b8469d9ea3 Author: jjg Date: 2017-08-30 12:45 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/83b8469d9ea3 8186932: Fix accessibility issues in the java.management module Reviewed-by: mchung ! src/java.management/share/classes/java/lang/management/LockInfo.java ! src/java.management/share/classes/java/lang/management/ManagementFactory.java ! src/java.management/share/classes/java/lang/management/ManagementPermission.java ! src/java.management/share/classes/java/lang/management/MemoryNotificationInfo.java ! src/java.management/share/classes/java/lang/management/MemoryUsage.java ! src/java.management/share/classes/java/lang/management/MonitorInfo.java ! src/java.management/share/classes/java/lang/management/RuntimeMXBean.java ! src/java.management/share/classes/java/lang/management/ThreadInfo.java ! src/java.management/share/classes/javax/management/Descriptor.java ! src/java.management/share/classes/javax/management/DescriptorKey.java ! src/java.management/share/classes/javax/management/MXBean.java ! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanAttributeInfo.java ! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanConstructorInfo.java ! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanInfo.java ! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanNotificationInfo.java ! src/java.management/share/classes/javax/management/modelmbean/ModelMBeanOperationInfo.java ! src/java.management/share/classes/javax/management/remote/JMXConnectionNotification.java Changeset: 5a28f7ef36da Author: jjg Date: 2017-08-30 12:46 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/5a28f7ef36da 8186934: Fix accessibility issues in the java.naming module Reviewed-by: mchung ! src/java.naming/share/classes/javax/naming/CompositeName.java Changeset: 125e348a3cbf Author: naoto Date: 2017-08-31 08:35 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/125e348a3cbf 8180469: Wrong short form text for supplemental Japanese era Reviewed-by: rriggs ! src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! test/java/util/Calendar/SupplementalJapaneseEraTest.java Changeset: 10498d6923ae Author: wetmore Date: 2017-08-31 12:48 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/10498d6923ae 8186093: A comment in the java.security configuration file incorrectly says that strong but "limited" is the default value Reviewed-by: mullan ! src/java.base/share/conf/security/java.security ! src/java.base/share/conf/security/policy/README.txt Changeset: 83720375178f Author: rriggs Date: 2017-08-31 17:08 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/83720375178f 8087189: RMI server-side multiplex protocol support should be removed Reviewed-by: alanb ! src/java.rmi/share/classes/sun/rmi/server/ActivatableRef.java - src/java.rmi/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java - src/java.rmi/share/classes/sun/rmi/transport/tcp/MultiplexConnectionInfo.java - src/java.rmi/share/classes/sun/rmi/transport/tcp/MultiplexInputStream.java - src/java.rmi/share/classes/sun/rmi/transport/tcp/MultiplexOutputStream.java ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java ! src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPTransport.java Changeset: ddc25f646c2e Author: igerasim Date: 2017-08-31 22:21 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/ddc25f646c2e 8187023: Cannot read pkcs11 config file in UTF-16 environment Reviewed-by: ascarpino ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java + test/sun/security/pkcs11/Config/ReadConfInUTF16Env.java + test/sun/security/pkcs11/Config/ReadConfInUTF16Env.sh Changeset: dde51e70f319 Author: asaha Date: 2017-09-01 14:14 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/dde51e70f319 Added tag jdk-10+22 for changeset 83720375178f ! .hgtags Changeset: 20bb4051f723 Author: asaha Date: 2017-09-01 14:15 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/20bb4051f723 Merge Changeset: 4846f1bc6d2b Author: sherman Date: 2017-09-01 08:15 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/4846f1bc6d2b 8186751: Add ISO-8859-16 Charset support Reviewed-by: alanb + make/data/charsetmapping/ISO_8859_16.map ! make/data/charsetmapping/charsets ! src/java.base/share/classes/sun/nio/cs/Unicode.java ! src/jdk.charsets/share/classes/sun/nio/cs/ext/GB18030.java.template ! test/java/nio/charset/Charset/CharsetContainmentTest.java ! test/java/nio/charset/Charset/RegisteredCharsets.java ! test/sun/nio/cs/TestCharsetMapping.java Changeset: 5fcfc9e09966 Author: dfuchs Date: 2017-09-01 18:18 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/5fcfc9e09966 8187044: HttpClient ConnectionPool may spawn several concurrent CacheCleaner and prevent early GC of HttpClient. Summary: Fixes CacheCleaner creation logic in ConnectionPool. Reviewed-by: chegar ! src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/ConnectionPool.java ! test/java/net/httpclient/whitebox/Driver.java + test/java/net/httpclient/whitebox/jdk.incubator.httpclient/jdk/incubator/http/ConnectionPoolTest.java Changeset: f59720adabf8 Author: jjg Date: 2017-09-01 11:54 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/f59720adabf8 8187021: Remove 2 redundant

tags in java.base API docs Reviewed-by: darcy ! src/java.base/share/classes/java/io/FileOutputStream.java ! src/java.base/share/classes/module-info.java Changeset: 92657a0613dd Author: jwilhelm Date: 2017-09-03 14:19 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/92657a0613dd Merge From ashipile at redhat.com Thu Sep 7 10:17:11 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 07 Sep 2017 10:17:11 +0000 Subject: hg: shenandoah/jdk10/hotspot: 104 new changesets Message-ID: <201709071017.v87AHEu8003684@aojmv0008.oracle.com> Changeset: 9a75c2f7bf06 Author: goetz Date: 2017-08-16 16:00 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/9a75c2f7bf06 8186293: [aix] Fix thread creation with huge stack sizes Reviewed-by: stuefe, dholmes ! src/os/aix/vm/os_aix.cpp Changeset: 05b6a88d5323 Author: asaha Date: 2017-08-18 04:37 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/05b6a88d5323 Added tag jdk-10+20 for changeset e93ed1a09240 ! .hgtags Changeset: c8607c55bfda Author: jwilhelm Date: 2017-08-18 18:39 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/c8607c55bfda Merge - make/lib/Lib-jdk.aot.gmk - src/cpu/aarch64/vm/debug_aarch64.cpp - src/cpu/aarch64/vm/metaspaceShared_aarch64.cpp - src/cpu/arm/vm/debug_arm.cpp - src/cpu/arm/vm/metaspaceShared_arm.cpp - src/cpu/ppc/vm/debug_ppc.cpp - src/cpu/ppc/vm/metaspaceShared_ppc.cpp - src/cpu/s390/vm/debug_s390.cpp - src/cpu/s390/vm/metaspaceShared_s390.cpp - src/cpu/sparc/vm/debug_sparc.cpp - src/cpu/sparc/vm/metaspaceShared_sparc.cpp - src/cpu/x86/vm/debug_x86.cpp - src/cpu/x86/vm/metaspaceShared_x86_32.cpp - src/cpu/x86/vm/metaspaceShared_x86_64.cpp - src/cpu/zero/vm/debug_zero.cpp - src/cpu/zero/vm/metaspaceShared_zero.cpp - src/jdk.aot/share/classes/jdk.tools.jaotc.jnilibelf/src/jdk/tools/jaotc/jnilibelf/ELFContainer.java - src/jdk.aot/share/classes/jdk.tools.jaotc.jnilibelf/src/jdk/tools/jaotc/jnilibelf/ELFSymbol.java - src/jdk.aot/share/classes/jdk.tools.jaotc.jnilibelf/src/jdk/tools/jaotc/jnilibelf/JNIELFContainer.java - src/jdk.aot/share/classes/jdk.tools.jaotc.jnilibelf/src/jdk/tools/jaotc/jnilibelf/JNIELFRelocation.java - src/jdk.aot/share/classes/jdk.tools.jaotc.jnilibelf/src/jdk/tools/jaotc/jnilibelf/JNIELFTargetInfo.java - src/jdk.aot/share/classes/jdk.tools.jaotc.jnilibelf/src/jdk/tools/jaotc/jnilibelf/JNILibELFAPI.java - src/jdk.aot/share/classes/jdk.tools.jaotc.jnilibelf/src/jdk/tools/jaotc/jnilibelf/Pointer.java - src/jdk.aot/share/classes/jdk.tools.jaotc.jnilibelf/src/jdk/tools/jaotc/jnilibelf/UnsafeAccess.java - src/jdk.aot/share/classes/jdk.tools.jaotc.jnilibelf/src/jdk/tools/jaotc/jnilibelf/linux/Elf_Cmd.java - src/jdk.aot/share/classes/jdk.tools.jaotc.jnilibelf/src/jdk/tools/jaotc/jnilibelf/sunos/Elf_Cmd.java - src/jdk.aot/unix/native/libjelfshim/jdk_tools_jaotc_jnilibelf_JNILibELFAPI.c - src/jdk.aot/unix/native/libjelfshim/shim_functions.c - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/LoaderConstraintEntry.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/PlaceholderEntry.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/PlaceholderTable.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/ProtectionDomainCacheEntry.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/ProtectionDomainEntry.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/TwoOopHashtable.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.collections/src/org/graalvm/compiler/api/collections/CollectionsProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.collections/src/org/graalvm/compiler/api/collections/DefaultCollectionsProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test/AllocationInstrumentationTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test/IsMethodInlineDirectiveTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test/LockInstrumentationTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test/RootNameDirectiveTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test/TinyInstrumentor.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm/src/org/graalvm/compiler/asm/NumUtil.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.common/src/org/graalvm/compiler/common/PermanentBailoutException.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.common/src/org/graalvm/compiler/common/RetryableBailoutException.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64AddressLowering.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64SuitesProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64SuitesProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/CollectionsFactory.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/LinkedIdentityHashMap.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/LocationIdentity.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/ArrayMap.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/ArraySet.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.sparc/src/org/graalvm/compiler/core/sparc/SPARCSuitesProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ConditionalEliminationLoadFieldConstantFoldTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GuardEliminationCornerCasesTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/debug/MethodMetricsTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/debug/MethodMetricsTest1.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/debug/MethodMetricsTest2.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/debug/MethodMetricsTest3.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/debug/MethodMetricsTest4.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/debug/MethodMetricsTest5.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/debug/MethodMetricsTest6.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/debug/MethodMetricsTestInterception01.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/debug/MethodMetricsTestInterception02.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/debug/VerifyMethodMetricsTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/inlining/RecursiveInliningTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalDebugInitializationParticipant.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug.test/src/org/graalvm/compiler/debug/test/DebugHistogramTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug.test/src/org/graalvm/compiler/debug/test/DebugTimerTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/Debug.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugConfigCustomizer.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugConfigScope.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugCounter.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugEnvironment.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugHistogram.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugInitializationParticipant.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugMethodMetrics.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugTimer.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugValueFactory.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DelegatingDebugConfig.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/Fingerprint.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/GraalDebugConfig.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/TopLevelDebugConfig.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/AccumulatedDebugValue.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/CloseableCounterImpl.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/CounterImpl.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/DebugHistogramAsciiPrinter.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/DebugHistogramImpl.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/DebugHistogramRPrinter.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/DebugScope.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/DebugValue.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/DebugValueMap.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/DebugValuesPrinter.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/KeyRegistry.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/MemUseTrackerImpl.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/TimerImpl.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/method/MethodMetricsImpl.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/method/MethodMetricsInlineeScopeInfo.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/method/MethodMetricsPrinter.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/internal/method/MethodMetricsRootScopeInfo.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/DefaultNodeCollectionsProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/NodeCollectionsProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/NodeNodeMap.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotLIRKindTool.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArchHotSpotNodeCostProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64DeoptimizationStub.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotEnterUnpackFramesStackFrameOp.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotLIRKindTool.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotLeaveUnpackFramesStackFrameOp.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotNodeCostProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotSuitesProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64UncommonTrapStub.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCDeoptimizationStub.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotEnterUnpackFramesStackFrameOp.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotLIRKindTool.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotLeaveUnpackFramesStackFrameOp.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotNodeCostProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCUncommonTrapStub.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompileTheWorld.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompileTheWorldOptions.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompressEncoding.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/FingerprintUtil.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/PrintStreamOption.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/CompressionNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DeoptimizationFetchUnrollInfoCallNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/DirectCompareAndSwapNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/EnterUnpackFramesStackFrameNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/HotSpotNodeCostProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/LeaveCurrentStackFrameNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/LeaveDeoptimizedStackFrameNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/LeaveUnpackFramesStackFrameNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/PushInterpreterFrameNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/SaveAllRegistersNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/SnippetAnchorNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/SnippetLocationProxyNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/UncommonTrapCallNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/type/HotSpotLIRKindTool.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/type/NarrowOopStamp.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/DeoptimizationStub.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/UncommonTrapStub.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/DefaultSuitesProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/alloc/trace/lsra/TraceIntervalWalker.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/ssi/FastSSIBuilder.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/ssi/SSIBuilder.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/ssi/SSIBuilderBase.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/ssi/SSIConstructionPhase.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/ssi/SSIUtil.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/ssi/SSIVerifier.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/micro/benchmarks/ArrayDuplicationBenchmark.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/micro/benchmarks/GuardedIntrinsicBenchmark.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/micro/benchmarks/MathFunctionBenchmark.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/micro/benchmarks/SimpleSyncBenchmark.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/micro/benchmarks/package-info.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/debug/instrumentation/InstrumentationBeginNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/debug/instrumentation/InstrumentationEndNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/debug/instrumentation/InstrumentationInliningCallback.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/debug/instrumentation/InstrumentationNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/debug/instrumentation/IsMethodInlinedNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/debug/instrumentation/MonitorProxyNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/debug/instrumentation/RootNameNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/UnsafeLoadNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/UnsafeStoreNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/CompareAndSwapNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/LoweredCompareAndSwapNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/DefaultNodeCostProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/NodeCostProvider.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/PiPushable.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options.test/src/org/graalvm/compiler/options/test/NestedBooleanOptionValueTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options.test/src/org/graalvm/compiler/options/test/TestOptionValue.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/DerivedOptionValue.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/EnumOptionValue.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/NestedBooleanOptionValue.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/OptionValue.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/StableOptionValue.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/UniquePathUtilities.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/DominatorConditionalEliminationPhase.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/OptimizeGuardAnchorsPhase.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/PushThroughPiPhase.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/ValueAnchorCleanupPhase.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/instrumentation/ExtractInstrumentationPhase.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/instrumentation/HighTierReconcileInstrumentationPhase.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/instrumentation/InlineInstrumentationPhase.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/instrumentation/MidTierReconcileInstrumentationPhase.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.printer/src/org/graalvm/compiler/printer/GraalDebugConfigCustomizer.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/IntegerMulExactFoldTest.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/InlineGraalDirectivesPlugin.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/WordOperationPlugin.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/DirectObjectStoreNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/Salver.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/SalverDebugConfigCustomizer.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/SalverOptions.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/data/DataDict.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/data/DataList.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/dumper/AbstractGraalDumper.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/dumper/AbstractMethodScopeDumper.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/dumper/AbstractSerializerDumper.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/dumper/Dumper.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/dumper/GraphDumper.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/handler/AbstractDumpHandler.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/handler/AbstractGraalDumpHandler.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/handler/DumpHandler.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/handler/GraphDumpHandler.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/package-info.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/serialize/AbstractSerializer.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/serialize/JSONSerializer.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/serialize/Serializer.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/util/ECIDUtil.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/util/MethodContext.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/writer/ChannelDumpWriter.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.salver/src/org/graalvm/compiler/salver/writer/DumpWriter.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/AtomicUnsigned.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/AtomicWord.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/ComparableWord.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/Pointer.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/PointerBase.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/PointerUtils.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/Signed.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/Unsigned.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/UnsignedUtils.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/WordBase.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/nodes/WordCastNode.java - src/os/aix/vm/interfaceSupport_aix.hpp - src/os/bsd/vm/interfaceSupport_bsd.hpp - src/os/bsd/vm/stubRoutines_bsd.cpp - src/os/linux/vm/interfaceSupport_linux.hpp - src/os/linux/vm/stubRoutines_linux.cpp - src/os/solaris/vm/interfaceSupport_solaris.hpp - src/os/solaris/vm/stubRoutines_solaris.cpp - src/os/windows/vm/interfaceSupport_windows.hpp - src/os/windows/vm/stubRoutines_windows.cpp - src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp - src/os_cpu/solaris_x86/vm/solaris_x86_32.il - src/os_cpu/solaris_x86/vm/solaris_x86_32.s - src/share/vm/gc/g1/workerDataArray.cpp - src/share/vm/gc/g1/workerDataArray.hpp - src/share/vm/gc/g1/workerDataArray.inline.hpp - src/share/vm/logging/logStream.inline.hpp - src/share/vm/memory/freeBlockDictionary.cpp - src/share/vm/memory/freeBlockDictionary.hpp - src/share/vm/utilities/array.hpp - test/compiler/aot/jdk.tools.jaotc.jnilibelf.test/src/jdk/tools/jaotc/jnilibelf/test/JNILibELFTest.java - test/compiler/cpuflags/predicate/AESSupportPredicate.java - test/compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java - test/compiler/rtm/cli/TestRTMAbortRatioOptionOnUnsupportedConfig.java - test/compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnUnsupportedConfig.java - test/compiler/testlibrary/rtm/predicate/SupportedCPU.java - test/compiler/testlibrary/rtm/predicate/SupportedOS.java - test/compiler/testlibrary/rtm/predicate/SupportedVM.java - test/gc/stress/TestGCOld.java - test/native/gc/g1/test_workerDataArray.cpp - test/runtime/SharedArchiveFile/CDSTestUtils.java - test/runtime/SharedArchiveFile/LargeSharedSpace.java - test/runtime/SharedArchiveFile/LimitSharedSizes.java - test/runtime/modules/JVMGetModuleByPkgName.java Changeset: 8c39c9157c17 Author: iignatyev Date: 2017-08-18 14:54 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/8c39c9157c17 8183337: hotspot/compiler/aot tests fail due to missed tools Reviewed-by: kvn ! test/ProblemList.txt ! test/compiler/aot/AotCompiler.java + test/compiler/aot/TEST.properties ! test/compiler/aot/cli/jaotc/JaotcTestHelper.java Changeset: ac5a73f93b55 Author: goetz Date: 2017-08-20 22:20 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/ac5a73f93b55 8185112: [TESTBUG] Serviceability tests cannot parse float if non US locale. Reviewed-by: simonis, goetz, dholmes Contributed-by: Arno Zeller ! test/serviceability/tmtools/jstat/utils/JstatResults.java Changeset: 4d2fded7bd7d Author: sjohanss Date: 2017-08-21 10:45 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/4d2fded7bd7d 8177544: Restructure G1 Full GC code Reviewed-by: tschatzl, ehelin ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp + src/share/vm/gc/g1/g1FullGCScope.cpp + src/share/vm/gc/g1/g1FullGCScope.hpp ! src/share/vm/gc/g1/g1MarkSweep.cpp ! src/share/vm/gc/g1/g1MarkSweep.hpp + src/share/vm/gc/g1/g1SerialFullCollector.cpp + src/share/vm/gc/g1/g1SerialFullCollector.hpp ! src/share/vm/gc/shared/collectorPolicy.hpp Changeset: 680ee8757c16 Author: kevinw Date: 2017-08-17 15:17 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/680ee8757c16 8180366: [TESTBUG] gc/g1/humongousObjects/TestHumongousClassLoader should not be run with class unloading disabled Reviewed-by: dfazunen Contributed-by: muthusamy.chinnathambi at oracle.com ! test/gc/g1/humongousObjects/TestHumongousClassLoader.java Changeset: 1ea1e66c4cf5 Author: kevinw Date: 2017-08-21 12:19 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/1ea1e66c4cf5 Merge Changeset: de57f3540d9a Author: iignatyev Date: 2017-08-21 07:08 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/de57f3540d9a 8186390: test for JDK-4755500 Reviewed-by: thartmann + test/compiler/floatingpoint/TestRound.java Changeset: 8fb69aff82a3 Author: bobv Date: 2017-08-21 12:07 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/8fb69aff82a3 8186115: libelf still referenced after 8172670 Reviewed-by: kvn, twisti, erikj, dholmes ! src/jdk.internal.vm.compiler/.mx.graal/suite.py Changeset: 8959e2938bff Author: bobv Date: 2017-08-21 18:14 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/8959e2938bff Merge Changeset: 3d6349716cc0 Author: iignatyev Date: 2017-08-21 17:08 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/3d6349716cc0 8186537: remove unnecessary @requires from hotspot/compiler/aot tests Reviewed-by: kvn ! test/compiler/aot/DeoptimizationTest.java ! test/compiler/aot/RecompilationTest.java ! test/compiler/aot/SharedUsageTest.java ! test/compiler/aot/calls/fromAot/AotInvokeDynamic2AotTest.java ! test/compiler/aot/calls/fromAot/AotInvokeDynamic2CompiledTest.java ! test/compiler/aot/calls/fromAot/AotInvokeDynamic2InterpretedTest.java ! test/compiler/aot/calls/fromAot/AotInvokeDynamic2NativeTest.java ! test/compiler/aot/calls/fromAot/AotInvokeInterface2AotTest.java ! test/compiler/aot/calls/fromAot/AotInvokeInterface2CompiledTest.java ! test/compiler/aot/calls/fromAot/AotInvokeInterface2InterpretedTest.java ! test/compiler/aot/calls/fromAot/AotInvokeInterface2NativeTest.java ! test/compiler/aot/calls/fromAot/AotInvokeSpecial2AotTest.java ! test/compiler/aot/calls/fromAot/AotInvokeSpecial2CompiledTest.java ! test/compiler/aot/calls/fromAot/AotInvokeSpecial2InterpretedTest.java ! test/compiler/aot/calls/fromAot/AotInvokeSpecial2NativeTest.java ! test/compiler/aot/calls/fromAot/AotInvokeStatic2AotTest.java ! test/compiler/aot/calls/fromAot/AotInvokeStatic2CompiledTest.java ! test/compiler/aot/calls/fromAot/AotInvokeStatic2InterpretedTest.java ! test/compiler/aot/calls/fromAot/AotInvokeStatic2NativeTest.java ! test/compiler/aot/calls/fromAot/AotInvokeVirtual2AotTest.java ! test/compiler/aot/calls/fromAot/AotInvokeVirtual2CompiledTest.java ! test/compiler/aot/calls/fromAot/AotInvokeVirtual2InterpretedTest.java ! test/compiler/aot/calls/fromAot/AotInvokeVirtual2NativeTest.java ! test/compiler/aot/calls/fromCompiled/CompiledInvokeDynamic2AotTest.java ! test/compiler/aot/calls/fromCompiled/CompiledInvokeInterface2AotTest.java ! test/compiler/aot/calls/fromCompiled/CompiledInvokeSpecial2AotTest.java ! test/compiler/aot/calls/fromCompiled/CompiledInvokeStatic2AotTest.java ! test/compiler/aot/calls/fromCompiled/CompiledInvokeVirtual2AotTest.java ! test/compiler/aot/calls/fromInterpreted/InterpretedInvokeDynamic2AotTest.java ! test/compiler/aot/calls/fromInterpreted/InterpretedInvokeInterface2AotTest.java ! test/compiler/aot/calls/fromInterpreted/InterpretedInvokeSpecial2AotTest.java ! test/compiler/aot/calls/fromInterpreted/InterpretedInvokeStatic2AotTest.java ! test/compiler/aot/calls/fromInterpreted/InterpretedInvokeVirtual2AotTest.java ! test/compiler/aot/calls/fromNative/NativeInvokeSpecial2AotTest.java ! test/compiler/aot/calls/fromNative/NativeInvokeStatic2AotTest.java ! test/compiler/aot/calls/fromNative/NativeInvokeVirtual2AotTest.java ! test/compiler/aot/cli/DisabledAOTWithLibraryTest.java ! test/compiler/aot/cli/IncorrectAOTLibraryTest.java ! test/compiler/aot/cli/MultipleAOTLibraryTest.java ! test/compiler/aot/cli/NonExistingAOTLibraryTest.java ! test/compiler/aot/cli/SingleAOTLibraryTest.java ! test/compiler/aot/cli/SingleAOTOptionTest.java ! test/compiler/aot/cli/jaotc/ClasspathOptionUnknownClassTest.java ! test/compiler/aot/cli/jaotc/CompileClassTest.java ! test/compiler/aot/cli/jaotc/CompileDirectoryTest.java ! test/compiler/aot/cli/jaotc/CompileJarTest.java ! test/compiler/aot/cli/jaotc/CompileModuleTest.java ! test/compiler/aot/cli/jaotc/ListOptionNotExistingTest.java ! test/compiler/aot/cli/jaotc/ListOptionTest.java ! test/compiler/aot/cli/jaotc/ListOptionWrongFileTest.java ! test/compiler/aot/jdk.tools.jaotc.test/src/jdk/tools/jaotc/test/NativeOrderOutputStreamTest.java ! test/compiler/aot/verification/ClassAndLibraryNotMatchTest.java ! test/compiler/aot/verification/vmflags/NotTrackedFlagTest.java ! test/compiler/aot/verification/vmflags/TrackedFlagTest.java Changeset: eed8aa5e12df Author: glaubitz Date: 2017-08-22 08:37 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/eed8aa5e12df 8186443: Missing stdint.h for zero builds Reviewed-by: kbarrett, dholmes ! src/share/vm/runtime/vmStructs.hpp ! test/native/runtime/test_vmStructs.cpp Changeset: 425e15743247 Author: dpochepk Date: 2017-08-22 17:24 +0300 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/425e15743247 8186297: AARCH64: Intrinsify Unsafe.compareAndSetByte and compareAndSetShort Reviewed-by: aph, adinn ! src/cpu/aarch64/vm/aarch64.ad Changeset: 33a6fce80d92 Author: iveresov Date: 2017-08-22 08:53 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/33a6fce80d92 8186235: [Graal] compiler/aot/RecompilationTest.java fails in case UseJVMCICompiler is enabled Summary: Make JVMCI respect -XX:-Inline Reviewed-by: kvn ! src/share/vm/jvmci/jvmciCompilerToVM.cpp ! test/compiler/aot/RecompilationTest.java Changeset: b813cb7bcfc9 Author: mseledtsov Date: 2017-08-21 19:45 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/b813cb7bcfc9 8186542: [TESTBUG] Add jvmti/LoadAgentDcmdTest.java to problem list until underlying issue is resolved Summary: Added the test to the problem list Reviewed-by: sspitsyn ! test/ProblemList.txt Changeset: b972de2a2fab Author: mseledtsov Date: 2017-08-22 09:55 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/b972de2a2fab Merge Changeset: a8d6bb592f77 Author: mseledtsov Date: 2017-08-22 18:11 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/a8d6bb592f77 Merge Changeset: d80894325719 Author: kvn Date: 2017-08-22 11:50 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/d80894325719 8186453: [AOT] refactor AOT tool code Reviewed-by: iveresov ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/CodeContainer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/Container.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/GotSymbol.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/HeaderContainer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/ReadOnlyDataContainer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/Relocation.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/Symbol.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/elf/Elf.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/elf/ElfByteBuffer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/elf/ElfContainer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/elf/ElfHeader.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/elf/ElfRelocEntry.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/elf/ElfRelocTable.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/elf/ElfSection.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/elf/ElfSymbol.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/elf/ElfSymtab.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/elf/ElfTargetInfo.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/elf/JELFRelocObject.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/JMachORelocObject.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/MachO.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/MachOByteBuffer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/MachOContainer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/MachODySymtab.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/MachOHeader.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/MachORelocEntry.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/MachORelocTable.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/MachOSection.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/MachOSegment.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/MachOSymbol.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/MachOSymtab.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/MachOTargetInfo.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/macho/MachOVersion.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/JPECoffRelocObject.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoff.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoffByteBuffer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoffContainer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoffHeader.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoffRelocEntry.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoffRelocTable.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoffSection.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoffSymbol.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoffSymtab.java ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoffTargetInfo.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/AOTBackend.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/AOTCompilationTask.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/AOTCompiledClass.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/AOTCompiler.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/AOTHotSpotResolvedJavaMethod.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/AOTStub.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/CallInfo.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/CallSiteRelocationInfo.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/CallSiteRelocationSymbol.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/CodeOffsets.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/CodeSectionProcessor.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Collector.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/CompilationSpec.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/CompiledMethodInfo.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataBuilder.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataPatchProcessor.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ELFMacroAssembler.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ForeignCallSiteRelocationInfo.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ForeignCallSiteRelocationSymbol.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/ForeignGotCallSiteRelocationSymbol.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/GraalFilters.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/InfopointProcessor.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/JavaCallSiteRelocationInfo.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/JavaCallSiteRelocationSymbol.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/JavaMethodInfo.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Linker.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/LoadedClass.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/LogPrinter.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Main.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MarkId.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MarkProcessor.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MetadataBuilder.java - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MiscUtils.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Options.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/StubDirectCallSiteRelocationSymbol.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/StubInformation.java + src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Timer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/amd64/AMD64ELFMacroAssembler.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/amd64/AMD64InstructionDecoder.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/ClassSearch.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/ClassSource.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/FileSupport.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/FileSystemFinder.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/SearchFor.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/SearchPath.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/SourceProvider.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/classname/ClassNameSource.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/classname/ClassNameSourceProvider.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/directory/DirectorySource.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/directory/DirectorySourceProvider.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/jar/JarFileSource.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/jar/JarSourceProvider.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/module/ModuleSource.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/collect/module/ModuleSourceProvider.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/utils/NativeOrderOutputStream.java - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/utils/Timer.java ! src/share/vm/aot/aotCodeHeap.cpp ! src/share/vm/aot/aotCodeHeap.hpp Changeset: e0c0f9a12318 Author: kvn Date: 2017-08-22 19:24 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/e0c0f9a12318 Merge - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MiscUtils.java - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/utils/Timer.java Changeset: a25c89a1b80a Author: iignatyev Date: 2017-08-20 20:36 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/a25c89a1b80a 8186095: upgrade to jtreg 4.2 b08 Reviewed-by: rriggs, mchung, dholmes, iklam ! test/TEST.ROOT ! test/runtime/Metaspace/FragmentMetaspaceSimple.java Changeset: aa16f40d1859 Author: jwilhelm Date: 2017-08-22 16:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/aa16f40d1859 Merge Changeset: b81e27d21310 Author: jwilhelm Date: 2017-08-22 20:31 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/b81e27d21310 Merge Changeset: a54a1bd7f1d3 Author: mdoerr Date: 2017-08-23 10:25 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/a54a1bd7f1d3 8186611: s390: Add missing compiler barriers and fix assembler Reviewed-by: goetz ! src/cpu/s390/vm/assembler_s390.inline.hpp ! src/cpu/s390/vm/compiledIC_s390.cpp ! src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp Changeset: 0a366ed5cf6e Author: njian Date: 2017-08-16 14:48 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/0a366ed5cf6e 8185786: AArch64: disable some address reshapings. Summary: LoadS/LoadUS's address reshapings are disabled on Arm Cortex-A family for performance. Reviewed-by: adinn, aph Contributed-by: zhongwei.yao at linaro.org ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/vm_version_aarch64.hpp Changeset: d4f8d54fdb26 Author: stuefe Date: 2017-08-15 08:46 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/d4f8d54fdb26 8186199: [windows] JNI_DestroyJavaVM not covered by SEH Reviewed-by: dholmes, mdoerr ! src/share/vm/prims/jni.cpp Changeset: c3125a60a0b8 Author: coleenp Date: 2017-08-23 12:39 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/c3125a60a0b8 Merge - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MiscUtils.java - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/utils/Timer.java Changeset: f5b8473c96bd Author: coleenp Date: 2017-08-23 13:46 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/f5b8473c96bd Merge Changeset: 4d61110c6046 Author: eosterlund Date: 2017-08-23 14:01 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/4d61110c6046 8186166: Generalize Atomic::cmpxchg with templates Reviewed-by: dholmes, coleenp Contributed-by: kim.barrett at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp ! src/os_cpu/bsd_x86/vm/atomic_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/atomic_bsd_zero.hpp ! src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp ! src/os_cpu/linux_arm/vm/atomic_linux_arm.hpp ! src/os_cpu/linux_ppc/vm/atomic_linux_ppc.hpp ! src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.hpp ! src/os_cpu/linux_zero/vm/atomic_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.il ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/atomic_windows_x86.hpp ! src/share/vm/aot/aotCodeHeap.cpp ! src/share/vm/aot/aotCodeHeap.hpp ! src/share/vm/gc/parallel/psParallelCompact.hpp ! src/share/vm/gc/shared/workgroup.cpp + src/share/vm/metaprogramming/isRegisteredEnum.hpp + src/share/vm/metaprogramming/primitiveConversions.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/utilities/bitMap.cpp ! src/share/vm/utilities/bitMap.hpp ! src/share/vm/utilities/bitMap.inline.hpp + test/native/metaprogramming/test_isRegisteredEnum.cpp + test/native/metaprogramming/test_primitiveConversions.cpp Changeset: 63173f711788 Author: eosterlund Date: 2017-08-23 15:47 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/63173f711788 Merge Changeset: fc64caded832 Author: simonis Date: 2017-08-23 18:24 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/fc64caded832 8186667: InterpreterCodeSize overflows on AIX Reviewed-by: goetz ! src/cpu/ppc/vm/templateInterpreterGenerator_ppc.cpp Changeset: 84542f4b65bb Author: coleenp Date: 2017-08-23 12:00 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/84542f4b65bb 8186088: ConstantPoolCache::_resolved_references is not a JNIHandle Summary: Make an OopHandle type to replace jobject to encapsulate these oop pointers in metadata and module entry. Reviewed-by: sspitsyn, dholmes, jiangli, twisti ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/arm/vm/interp_masm_arm.cpp ! src/cpu/arm/vm/macroAssembler_arm.cpp ! src/cpu/arm/vm/macroAssembler_arm.hpp ! src/cpu/ppc/vm/interp_masm_ppc_64.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.cpp ! src/cpu/ppc/vm/macroAssembler_ppc.hpp ! src/cpu/s390/vm/interp_masm_s390.cpp ! src/cpu/s390/vm/macroAssembler_s390.cpp ! src/cpu/s390/vm/macroAssembler_s390.hpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/x86/vm/interp_masm_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/moduleEntry.cpp ! src/share/vm/classfile/moduleEntry.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.hpp + src/share/vm/oops/oopHandle.hpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 21bdc1a84c9f Author: coleenp Date: 2017-08-23 16:37 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/21bdc1a84c9f Merge Changeset: 6d53d0ae27e5 Author: iveresov Date: 2017-08-23 11:24 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/6d53d0ae27e5 8186681: Update Graal Reviewed-by: kvn ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64/src/org/graalvm/compiler/core/amd64/AMD64ArithmeticLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/calc/FloatConvert.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/calc/FloatConvertCategory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/ArithmeticOpTable.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/FloatStamp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/type/IntegerStamp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/UnsafeReadEliminationTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/UnsafeEATest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/CompilationPrinter.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/CompilationWrapper.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalCompilerOptions.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/doc-files/CompilationBailoutActionHelp.txt ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugContext.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugFilter.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/DebugOptions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/MethodFilter.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/doc-files/DumpHelp.txt + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/doc-files/MethodFilterHelp.txt + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/doc-files/MetricsFileHelp.txt ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/NodeClass.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CompilationWrapperTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/ObjectCloneTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompilerConfigurationFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/JVMCIVersionCheck.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/debug/BenchmarkCounters.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/debug/doc-files/BenchmarkDynamicCountersHelp.txt ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotSuitesProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotspotSnippetsOptions.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/doc-files/ProfileAllocationsContextHelp.txt ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/ComputeLoopFrequenciesClosure.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64ArrayEqualsOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ArrayEqualsOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.sparc/src/org/graalvm/compiler/lir/sparc/SPARCArrayEqualsOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/gen/ArithmeticLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/LoopPartialUnrollPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.phases/src/org/graalvm/compiler/loop/phases/LoopTransformations.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop.test/src/org/graalvm/compiler/loop/test/LoopPartialUnrollTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/DefaultLoopPolicies.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.loop/src/org/graalvm/compiler/loop/LoopFragmentInside.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/graal/TestJMH.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/graal/TestJMHWhitebox.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes.test/src/org/graalvm/compiler/nodes/test/IntegerStampTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/GraphDecoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/MulNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/cfg/ControlFlowGraph.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options.processor/src/org/graalvm/compiler/options/processor/OptionProcessor.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/EnumOptionKey.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/Option.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/OptionDescriptor.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/OptionValues.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/InliningUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/policy/AbstractInliningPolicy.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/graph/FixedNodeProbabilityCache.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.printer/src/org/graalvm/compiler/printer/BinaryGraphPrinter.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64GraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/ArraysSubstitutionsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/DeoptimizeOnExceptionTest.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/FloatArraysEqualsTest.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/UnsafeBooleanAccessTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/DefaultJavaLoweringProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/StandardGraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/ArrayEqualsNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/ExplodeLoopNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/arithmetic/IntegerMulHighNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/arithmetic/UnsignedMulHighNode.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.micro.benchmarks/src/micro/benchmarks/TestJMHBlackbox.java Changeset: 16052efaf8e2 Author: iveresov Date: 2017-08-23 18:28 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/16052efaf8e2 Merge Changeset: e2f3c8029dd8 Author: sangheki Date: 2017-08-23 13:14 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/e2f3c8029dd8 8186402: [TESTBUG] "Balance queues" output expected by test Summary: Changed to use 2 ParallelGCThreads to guarantee generating 'Balance queues' log Reviewed-by: tschatzl, aharlap ! test/gc/logging/TestPrintReferences.java Changeset: 15e4b56998ec Author: sangheki Date: 2017-08-23 20:20 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/15e4b56998ec Merge - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/graal/TestJMH.java Changeset: b9f8d262202d Author: glaubitz Date: 2017-08-23 17:45 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/b9f8d262202d 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped Reviewed-by: stuefe, dholmes ! src/os/linux/vm/os_linux.cpp Changeset: 12817e44b856 Author: coleenp Date: 2017-08-23 14:52 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/12817e44b856 8160399: is_oop_or_null involves undefined behavior 8164984: Improper use of is_oop in production code Summary: replace oop->is_oop*() with oopDesc::is_oop*(oop) so this pointer can be verified Reviewed-by: iklam, kvn, dholmes ! src/cpu/arm/vm/methodHandles_arm.cpp ! src/cpu/ppc/vm/methodHandles_ppc.cpp ! src/cpu/ppc/vm/stubGenerator_ppc.cpp ! src/cpu/s390/vm/methodHandles_s390.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/protectionDomainCache.cpp ! src/share/vm/code/debugInfo.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/gc/cms/cmsOopClosures.inline.hpp ! src/share/vm/gc/cms/compactibleFreeListSpace.cpp ! src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc/cms/parNewGeneration.cpp ! src/share/vm/gc/cms/promotionInfo.cpp ! src/share/vm/gc/g1/g1ConcurrentMark.cpp ! src/share/vm/gc/g1/g1ConcurrentMark.inline.hpp ! src/share/vm/gc/g1/g1OopClosures.inline.hpp ! src/share/vm/gc/g1/g1RemSet.inline.hpp ! src/share/vm/gc/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc/g1/heapRegion.cpp ! src/share/vm/gc/g1/heapRegion.inline.hpp ! src/share/vm/gc/g1/satbMarkQueue.cpp ! src/share/vm/gc/parallel/cardTableExtension.cpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/parallel/psScavenge.cpp ! src/share/vm/gc/serial/defNewGeneration.inline.hpp ! src/share/vm/gc/shared/blockOffsetTable.cpp ! src/share/vm/gc/shared/collectedHeap.cpp ! src/share/vm/gc/shared/referenceProcessor.cpp ! src/share/vm/gc/shared/space.cpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/jvmci/jvmciRuntime.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/privilegedStack.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/shark/sharkRuntime.cpp ! src/share/vm/utilities/exceptions.cpp Changeset: 821ef7c10085 Author: coleenp Date: 2017-08-24 01:13 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/821ef7c10085 Merge - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/graal/TestJMH.java ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/runtime/os.cpp Changeset: e015ea7eaf32 Author: dnsimon Date: 2017-08-14 14:15 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/e015ea7eaf32 8186163: [JVMCI] bad signatures should be detected by MetaAccessProvider.parseMethodDescriptor Reviewed-by: kvn, iveresov ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSignature.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaAccessProvider.java ! test/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestMetaAccessProvider.java Changeset: f59d7a871cb5 Author: dnsimon Date: 2017-08-24 08:38 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/f59d7a871cb5 Merge Changeset: 143019ae96f5 Author: dnsimon Date: 2017-08-23 23:38 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/143019ae96f5 8186459: [JVMCI] ClassNotFoundException thrown by CompilerToVM.lookupType() should be converted to a LinkageError Reviewed-by: kvn, iveresov ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java ! test/compiler/jvmci/common/patches/jdk.internal.vm.ci/jdk/vm/ci/hotspot/CompilerToVMHelper.java ! test/compiler/jvmci/compilerToVM/FindUniqueConcreteMethodTest.java ! test/compiler/jvmci/compilerToVM/GetClassInitializerTest.java ! test/compiler/jvmci/compilerToVM/GetConstantPoolTest.java ! test/compiler/jvmci/compilerToVM/GetImplementorTest.java ! test/compiler/jvmci/compilerToVM/GetVtableIndexForInterfaceTest.java ! test/compiler/jvmci/compilerToVM/HasFinalizableSubclassTest.java ! test/compiler/jvmci/compilerToVM/ResolveMethodTest.java Changeset: 9cf835fba355 Author: mdoerr Date: 2017-08-24 14:56 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/9cf835fba355 8186734: AIX build broken after 8186166: Generalize Atomic::cmpxchg with templates Reviewed-by: goetz ! src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp Changeset: c3e39d67f6d4 Author: ghaug Date: 2017-08-16 14:14 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/c3e39d67f6d4 8186286: [BSD] Primary thread's stack size is reported incorrectly Reviewed-by: shade, stuefe ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/share/vm/runtime/thread.cpp Changeset: 3a8e59bdaaac Author: dholmes Date: 2017-08-24 14:00 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/3a8e59bdaaac Merge Changeset: 7356f594f176 Author: zgu Date: 2017-08-24 15:00 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/7356f594f176 8186748: NMT: memTracker::record_virtual_memory_reserve_and_commit() does not tag the memory as committed Summary: Fixed bug that results NMT to report "Shared class space" as reserved, but not committed memory Reviewed-by: shade, coleenp ! src/share/vm/services/memTracker.hpp Changeset: 0f7a91bf2395 Author: sspitsyn Date: 2017-08-24 14:03 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/0f7a91bf2395 8185687: Fix minor bugs in jvmti specification Summary: Fix the doc Reviewed-by: ksrini, jjg, dcubed ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmti.xsl Changeset: ac7eb1f61945 Author: sspitsyn Date: 2017-08-24 21:06 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/ac7eb1f61945 Merge - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MiscUtils.java - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/utils/Timer.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/graal/TestJMH.java Changeset: b94f3a90edeb Author: sspitsyn Date: 2017-08-24 22:37 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/b94f3a90edeb Merge Changeset: 8888f2e43fb1 Author: kvn Date: 2017-08-24 13:11 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/8888f2e43fb1 8186721: AOT tests fail with: section alignment is not valid: 128 Summary: add missing negation in assert chech, add -ea -esa to AOT testing Reviewed-by: dlong ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/pecoff/PECoffSection.java ! test/compiler/aot/AotCompiler.java Changeset: dd079e888b11 Author: kvn Date: 2017-08-24 22:46 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/dd079e888b11 Merge Changeset: c684649ef702 Author: kvn Date: 2017-08-24 23:54 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/c684649ef702 Merge Changeset: 316854ef2fa2 Author: martin Date: 2017-08-24 10:26 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/316854ef2fa2 8174050: Compilation errors with clang-4.0 Reviewed-by: kvn ! src/share/vm/memory/virtualspace.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopPredicate.cpp Changeset: 36780bca7e82 Author: kvn Date: 2017-08-25 14:07 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/36780bca7e82 8186136: [Graal] some tests setting -Djvmci.Compiler=null fail with: jdk.vm.ci.common.JVMCIError: no JVMCI compiler selected Summary: removed -Djvmci.Compiler=null for tests which do JIT compilation Reviewed-by: twisti ! test/compiler/jvmci/JVM_GetJVMCIRuntimeTest.java ! test/compiler/jvmci/compilerToVM/HasCompiledCodeForOSRTest.java ! test/compiler/jvmci/compilerToVM/InvalidateInstalledCodeTest.java ! test/compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java ! test/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java ! test/compiler/jvmci/compilerToVM/ReprofileTest.java Changeset: 409753e9c98e Author: goetz Date: 2017-08-22 15:12 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/409753e9c98e 8186437: Lock held when compiler thread creation fails. Reviewed-by: stuefe, kvn ! src/share/vm/compiler/compileBroker.cpp Changeset: 35045bc7f7f6 Author: kvn Date: 2017-08-25 18:21 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/35045bc7f7f6 8186144: [Graal] some tests fail with: Improperly specified VM option UseJVMCICompiler: EnableJVMCI cannot be disabled Summary: disable Graal by switching off UseJVMCICompiler when JVMCI is disabled Reviewed-by: twisti ! test/compiler/jvmci/SecurityRestrictionsTest.java ! test/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java ! test/compiler/jvmci/compilerToVM/JVM_RegisterJVMCINatives.java ! test/compiler/jvmci/events/JvmciShutdownEventTest.java Changeset: ab8afbbf2ace Author: njian Date: 2017-08-01 14:58 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/ab8afbbf2ace 8184049: AArch64: Matching rule for ubfiz Reviewed-by: aph, adinn Contributed-by: daniel.stewart at linaro.org ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/aarch64_ad.m4 Changeset: 427f4c99b29e Author: jiangli Date: 2017-08-27 15:48 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/427f4c99b29e 8186706: ArchivedObjectCache obj_hash() is broken. Summary: Use oop's identity_hash. Also use larger table size. Reviewed-by: ccheung, iklam, coleenp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/metaspaceShared.hpp Changeset: 3c5a2af3e982 Author: glaubitz Date: 2017-08-27 20:09 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/3c5a2af3e982 8186723: Add SuperH as new architecture for linux Reviewed-by: dholmes, stuefe ! src/os/linux/vm/os_linux.cpp Changeset: ec4c21cf8ba1 Author: dholmes Date: 2017-08-28 01:09 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/ec4c21cf8ba1 Merge Changeset: 18bf814595b9 Author: rraghavan Date: 2017-08-28 02:55 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/18bf814595b9 8186666: Bug in the C2 matcher code Summary: Correctly used Op_WeakCompareAndSwapI as required Reviewed-by: shade, thartmann Contributed-by: Andrew Haley ! src/share/vm/opto/c2compiler.cpp Changeset: d78407f77172 Author: eosterlund Date: 2017-08-28 13:31 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/d78407f77172 8186476: Generalize Atomic::add with templates Reviewed-by: aph, dholmes Contributed-by: kim.barrett at oracle.com ! src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp ! src/os_cpu/bsd_x86/vm/atomic_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/atomic_bsd_zero.hpp ! src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.hpp ! src/os_cpu/linux_arm/vm/atomic_linux_arm.hpp ! src/os_cpu/linux_ppc/vm/atomic_linux_ppc.hpp ! src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.hpp ! src/os_cpu/linux_zero/vm/atomic_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.il ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/atomic_windows_x86.hpp ! src/share/vm/gc/g1/g1CardLiveData.cpp ! src/share/vm/gc/g1/g1ConcurrentMark.cpp ! src/share/vm/gc/g1/g1HotCardCache.cpp ! src/share/vm/gc/g1/g1HotCardCache.hpp ! src/share/vm/gc/g1/g1RemSet.cpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/runtime/atomic.hpp ! src/share/vm/services/mallocTracker.hpp Changeset: ecebbbda267a Author: redestad Date: 2017-08-28 00:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/ecebbbda267a 8179040: Avoid Ticks::now calls when EventClassLoad is not enabled Reviewed-by: ehelin, mgronlun, dholmes, iklam Contributed-by: claes.redestad at oracle.com, markus.gronlund at oracle.com ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/traceEvent.hpp ! src/share/vm/trace/traceEventClasses.xsl ! src/share/vm/trace/traceTypes.xsl Changeset: d8861a784135 Author: redestad Date: 2017-08-28 14:07 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/d8861a784135 Merge Changeset: c5c6aa319333 Author: coleenp Date: 2017-08-28 09:06 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/c5c6aa319333 8186042: Optimize OopMapCache lookup Summary: Use lock free access to oopMapCache Reviewed-by: dholmes, sspitsyn Contributed-by: frederic.parain at oracle.com, coleen.phillimore at oracle.com ! src/share/vm/gc/shared/vmGCOperations.cpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/interpreter/oopMapCache.hpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/vframe.cpp Changeset: 735530e058e8 Author: coleenp Date: 2017-08-28 15:11 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/735530e058e8 Merge Changeset: 2ed5748b6eec Author: never Date: 2017-08-28 15:21 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/2ed5748b6eec 8181858: [JVMCI] JVMCI should update the trap counters when invalidating for Reason_not_compiled_exception_handler Reviewed-by: kvn ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: f3413e6d6b8f Author: never Date: 2017-08-28 16:40 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/f3413e6d6b8f Merge Changeset: bdb2dbc43ff0 Author: jwilhelm Date: 2017-08-22 16:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/bdb2dbc43ff0 Merge Changeset: 7bda89c08134 Author: asaha Date: 2017-08-25 04:59 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/7bda89c08134 Added tag jdk-10+21 for changeset bdb2dbc43ff0 ! .hgtags Changeset: c406559cce12 Author: mchung Date: 2017-08-25 10:49 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/c406559cce12 8186145: tools/launcher/modules/validate/ValidateModulesTest.java fails when launched with -XX:+EnableJVMCI Summary: --validate-modules runs with a boot layer resolving all system modules rather than only java.base Reviewed-by: alanb + test/compiler/jvmci/TestValidateModules.java Changeset: 8ff4215ca5fa Author: jwilhelm Date: 2017-08-28 21:46 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/8ff4215ca5fa Merge Changeset: 0c2d710aa6df Author: iveresov Date: 2017-08-28 14:43 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/0c2d710aa6df 8186850: Update Graal Reviewed-by: kvn ! src/jdk.aot/share/classes/jdk.tools.jaotc.binformat/src/jdk/tools/jaotc/binformat/BinaryContainer.java ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/AOTBackend.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.api.replacements/src/org/graalvm/compiler/api/replacements/ClassSubstitution.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.test/src/org/graalvm/compiler/asm/test/AssemblerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.code/src/org/graalvm/compiler/code/CompilationResult.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GraalCompilerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/InfopointReasonTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/tutorial/InvokeGraal.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph.test/src/org/graalvm/compiler/graph/test/NodeBitMapTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/NodeBitMap.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64RawNativeCallNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64RawNativeCallNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotUnsafeSubstitutionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotBackend.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalCompiler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotHostForeignCallsProvider.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotUnsafeSubstitutions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/Stub.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/alloc/trace/lsra/TraceInterval.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/alloc/trace/lsra/TraceLinearScanLifetimeAnalysisPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/alloc/trace/lsra/TraceLinearScanPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/lir/GraalCompilerState.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/GraphEncoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.printer/src/org/graalvm/compiler/printer/CFGPrinterObserver.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.printer/src/org/graalvm/compiler/printer/CompilationPrinter.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.verifier/src/org/graalvm/compiler/replacements/verifier/ClassSubstitutionVerifier.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/PEGraphDecoder.java ! src/share/vm/aot/aotCodeHeap.cpp Changeset: 232488f21a13 Author: iveresov Date: 2017-08-28 22:45 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/232488f21a13 Merge - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64RawNativeCallNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64RawNativeCallNode.java Changeset: 38ff008318c3 Author: stuefe Date: 2017-08-18 09:05 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/38ff008318c3 8186349: [windows] Centralize dbghelp handling code Summary: Rework and fix dbghelp.dll handling; add diagnostic output to hs-err file. Reviewed-by: iklam, rrich, goetz ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp ! src/os/windows/vm/os_windows.cpp + src/os/windows/vm/windbghelp.cpp + src/os/windows/vm/windbghelp.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/utilities/decoder.cpp ! src/share/vm/utilities/decoder.hpp ! src/share/vm/utilities/vmError.cpp Changeset: a20f0fa4c426 Author: iklam Date: 2017-08-28 23:46 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/a20f0fa4c426 Merge Changeset: 3c3e9a1d65bd Author: dbuck Date: 2017-08-29 05:33 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/3c3e9a1d65bd 8185624: G1HeapVerifier's VerifyRootsClosure prints important information on info log level Summary: Fix logging of broken oop to error log level instead of info log level Reviewed-by: mgerdin, tschatzl Contributed-by: muthusamy.chinnathambi at oracle.com ! src/share/vm/gc/g1/g1HeapVerifier.cpp Changeset: 5cd4495a3efa Author: goetz Date: 2017-08-17 17:26 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/5cd4495a3efa 8186072: dll_build_name returns true even if file is missing. Summary: Split dll_build_name into two functions and consolidate to os.cpp file. Reviewed-by: stuefe, dholmes ! src/os/aix/vm/os_aix.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp Changeset: 35670a2b20d5 Author: dholmes Date: 2017-08-29 10:41 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/35670a2b20d5 Merge Changeset: 182f9c89e337 Author: glaubitz Date: 2017-08-29 18:34 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/182f9c89e337 8186855: Multiple platforms broken after 8186476: Generalize Atomic::add with templates Reviewed-by: stuefe, coleenp ! src/os_cpu/aix_ppc/vm/atomic_aix_ppc.hpp ! src/os_cpu/bsd_zero/vm/atomic_bsd_zero.hpp ! src/os_cpu/linux_ppc/vm/atomic_linux_ppc.hpp ! src/os_cpu/linux_s390/vm/atomic_linux_s390.hpp ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.hpp ! src/os_cpu/linux_zero/vm/atomic_linux_zero.hpp Changeset: 5e3603c1495f Author: jwilhelm Date: 2017-08-28 21:46 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/5e3603c1495f Merge - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MiscUtils.java - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/utils/Timer.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/graal/TestJMH.java Changeset: 294bd8d9088c Author: jwilhelm Date: 2017-08-29 17:17 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/294bd8d9088c Merge Changeset: 7a698e293256 Author: mgerdin Date: 2017-08-29 12:17 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/7a698e293256 8186897: semaphore_posix.hpp should not be included on OSX Reviewed-by: stefank, dholmes ! src/os/posix/vm/os_posix.cpp Changeset: 3a8e8737cb36 Author: njian Date: 2017-08-24 16:12 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/3a8e8737cb36 8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV Reviewed-by: adinn, aph Contributed-by: stuart.monteith at linaro.org ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/templateTable_aarch64.cpp Changeset: 8d5a52d81b78 Author: coleenp Date: 2017-08-30 07:18 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/8d5a52d81b78 8181170: resolved_references array leaks for RedefineClasses Summary: clear out resolved_reference from ClassLoaderData::_handles Reviewed-by: stefank, jiangli, sspitsyn ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/oopHandle.hpp Changeset: 5adfb4c2ed9c Author: coleenp Date: 2017-08-30 13:04 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/5adfb4c2ed9c Merge Changeset: f28a28fc1497 Author: zgu Date: 2017-08-30 15:48 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/f28a28fc1497 8186797: cardtable_rs in g1CollectedHeap::initialize() defined, but never used Reviewed-by: tschatzl, ehelin ! src/share/vm/gc/g1/g1CollectedHeap.cpp Changeset: 644db104e2f0 Author: coleenp Date: 2017-08-30 19:18 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/644db104e2f0 8164207: Checking missing load-acquire in relation to _pd_set in dictionary.cpp Summary: Use load_acquire for accessing DictionaryEntry::_pd_set since it's accessed outside the SystemDictionary_lock Reviewed-by: zgu, twisti, dholmes, adinn ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 8acd232fb52a Author: rehn Date: 2017-08-31 08:18 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/8acd232fb52a 8186837: Memory ordering nmethod, _state and _stack_traversal_mark Reviewed-by: dholmes, rkennke ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 3ee845ce8ea1 Author: bobv Date: 2017-08-29 15:53 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/3ee845ce8ea1 8186248: Allow more flexibility in selecting Heap % of available RAM Reviewed-by: dholmes, drwhite ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! test/Makefile ! test/runtime/CommandLine/FlagWithInvalidValue.java ! test/runtime/CommandLine/NonBooleanFlagWithInvalidBooleanPrefix.java ! test/runtime/CommandLine/VMDeprecatedOptions.java Changeset: 075c0f5b20fa Author: bobv Date: 2017-08-31 16:29 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/075c0f5b20fa Merge Changeset: b471b0c614d6 Author: stuefe Date: 2017-08-31 18:34 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/b471b0c614d6 8186982: [aix] Garbage output for CPU info in hs-err file Reviewed-by: goetz, simonis Contributed-by: arno.zeller at sap.com ! src/os/aix/vm/os_aix.cpp Changeset: 7df86c5f8b5d Author: ccheung Date: 2017-08-28 15:34 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/7df86c5f8b5d 8186842: Use Java class loaders for creating the CDS archive Reviewed-by: coleenp, jiangli, iklam, mseledtsov Contributed-by: calvin.cheung at oracle.com, ioi.lam at oracle.com ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/classLoaderExt.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/klassFactory.cpp ! src/share/vm/classfile/stringTable.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/logging/logTag.hpp ! src/share/vm/memory/metaspaceClosure.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/arguments_ext.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/exceptions.cpp ! test/runtime/SharedArchiveFile/BootAppendTests.java + test/runtime/SharedArchiveFile/NonBootLoaderClasses.java ! test/runtime/modules/PatchModule/PatchModuleCDS.java Changeset: a8ec32aa385e Author: ccheung Date: 2017-08-31 17:06 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/a8ec32aa385e Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3d1150c7899c Author: kevinw Date: 2017-09-01 01:03 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/3d1150c7899c 8186902: jcmd GC.run should not be blocked by DisableExplicitGC Reviewed-by: mgerdin, sspitsyn ! src/share/vm/services/diagnosticCommand.cpp Changeset: 61c0ae8bee4e Author: gziemski Date: 2017-08-31 20:26 -0500 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/61c0ae8bee4e 8173715: Remove FlatProfiler Summary: Obsoleted Xprof flag, removed FlatProfiler code Reviewed-by: dholmes, coleenp, vlivanov, pliden ! make/lib/JvmFeatures.gmk ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/os/aix/vm/os_aix.cpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/aix_ppc/vm/thread_aix_ppc.hpp ! src/os_cpu/linux_ppc/vm/thread_linux_ppc.hpp ! src/os_cpu/linux_s390/vm/thread_linux_s390.hpp ! src/share/vm/Xusage.txt ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/gc/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc/g1/g1GCPhaseTimes.hpp ! src/share/vm/gc/g1/g1MarkSweep.cpp ! src/share/vm/gc/g1/g1RootProcessor.cpp ! src/share/vm/gc/g1/g1RootProcessor.hpp ! src/share/vm/gc/parallel/pcTasks.cpp ! src/share/vm/gc/parallel/pcTasks.hpp ! src/share/vm/gc/parallel/psMarkSweep.cpp ! src/share/vm/gc/parallel/psParallelCompact.cpp ! src/share/vm/gc/parallel/psScavenge.cpp ! src/share/vm/gc/parallel/psTasks.cpp ! src/share/vm/gc/parallel/psTasks.hpp ! src/share/vm/gc/serial/genMarkSweep.cpp ! src/share/vm/gc/shared/genCollectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp - src/share/vm/runtime/fprofiler.cpp - src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/utilities/macros.hpp ! test/gc/g1/TestGCLogMessages.java ! test/runtime/CommandLine/TestNullTerminatedFlags.java - test/runtime/MinimalVM/Xprof.java Changeset: 046eab27258f Author: gziemski Date: 2017-09-01 13:03 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/046eab27258f Merge Changeset: 25b63c7d1fa3 Author: njian Date: 2017-08-31 10:28 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/25b63c7d1fa3 8187022: AArch64: UBFX instructions have wrong format string Reviewed-by: aph Contributed-by: daniel.stewart at linaro.org ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/aarch64_ad.m4 Changeset: 71337910df60 Author: jwilhelm Date: 2017-08-29 17:17 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/71337910df60 Merge Changeset: a7454342f29c Author: asaha Date: 2017-09-01 14:13 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/a7454342f29c Added tag jdk-10+22 for changeset 71337910df60 ! .hgtags Changeset: 86445dc6021b Author: jwilhelm Date: 2017-09-03 14:19 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/86445dc6021b Merge - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64RawNativeCallNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64RawNativeCallNode.java - src/share/vm/runtime/fprofiler.cpp - src/share/vm/runtime/fprofiler.hpp - test/runtime/MinimalVM/Xprof.java Changeset: 1a9c2e07a826 Author: jwilhelm Date: 2017-09-03 13:39 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/1a9c2e07a826 Merge Changeset: 90a2a29e9e0c Author: shade Date: 2017-09-07 12:01 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/90a2a29e9e0c Merge ! .hgtags ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/templateTable_aarch64.cpp ! src/cpu/x86/vm/interp_masm_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/MiscUtils.java - src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/utils/Timer.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64RawNativeCallNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64RawNativeCallNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.microbenchmarks/src/org/graalvm/compiler/microbenchmarks/graal/TestJMH.java ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/protectionDomainCache.cpp ! src/share/vm/classfile/stringTable.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/gc/g1/g1CardLiveData.cpp ! src/share/vm/gc/g1/g1CollectedHeap.cpp ! src/share/vm/gc/g1/g1CollectedHeap.hpp ! src/share/vm/gc/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc/g1/g1ConcurrentMark.cpp ! src/share/vm/gc/g1/g1ConcurrentMark.inline.hpp ! src/share/vm/gc/g1/g1HeapVerifier.cpp ! src/share/vm/gc/g1/g1RemSet.cpp ! src/share/vm/gc/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc/g1/satbMarkQueue.cpp ! src/share/vm/gc/serial/genMarkSweep.cpp ! src/share/vm/gc/shared/collectedHeap.cpp ! src/share/vm/gc/shared/referenceProcessor.cpp ! src/share/vm/gc/shared/space.cpp ! src/share/vm/gc/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc/shenandoah/shenandoahCodeRoots.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahPrinter.cpp ! src/share/vm/gc/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/oopMapCache.cpp ! src/share/vm/jvmci/jvmciCompilerToVM.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/deoptimization.cpp - src/share/vm/runtime/fprofiler.cpp - src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/vmError.cpp ! test/TEST.ROOT ! test/gc/logging/TestPrintReferences.java - test/runtime/MinimalVM/Xprof.java From joe.darcy at oracle.com Thu Sep 7 05:21:02 2017 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 6 Sep 2017 22:21:02 -0700 Subject: shenandoah/jdk10 and JDK 10 repository consolidation Message-ID: Hello Shenandoah folks, As you may have heard, we're working on consolidating the JDK 10 OpenJDK forest into a single repository [1]. The work is underway now [2] and the master forest for JDK 10 is currently locked [3]. I see the Shenandoah project has a JDK 10 forest at http://hg.openjdk.java.net/shenandoah/jdk10/ and I wanted to discuss with the team how to handle repo consolidation with respect to your project. Within the next few weeks, if you want to keep syncing down changes from JDK 10 master or hs, you'll need to use a consolidated forest instead of the current split one. Only one more promotion is planned for the split forest. In the near future, we hope to have a script to help automate forward and backward porting of patches across the consolidation boundary. Cheers, -Joe [1] http://openjdk.java.net/jeps/296 [2] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000455.html [3] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000467.html From shade at redhat.com Thu Sep 7 15:03:23 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Sep 2017 17:03:23 +0200 Subject: RFR [8u]: Make sure -verbose:gc, PrintGC, PrintGCDetails work consistently Message-ID: <4a60fcc6-e79a-65ed-9bd5-bfd479ccec1b@redhat.com> http://cr.openjdk.java.net/~shade/shenandoah/8u-logging/webrev.01/ This is 8u-specific patch, because we have this logging compatibility layer there. We need to make sure -verbose:gc, PrintGC, PrintGCDetails work consistently there. Adds a test. Fixes another one. Testing: hotspot_gc_shenandoah Thanks, -Aleksey From rkennke at redhat.com Thu Sep 7 17:13:00 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 Sep 2017 19:13:00 +0200 Subject: RFR [8u]: Make sure -verbose:gc, PrintGC, PrintGCDetails work consistently In-Reply-To: <4a60fcc6-e79a-65ed-9bd5-bfd479ccec1b@redhat.com> References: <4a60fcc6-e79a-65ed-9bd5-bfd479ccec1b@redhat.com> Message-ID: <56231d22-1adf-b277-cb01-8f7f2f1c6b9f@redhat.com> Am 07.09.2017 um 17:03 schrieb Aleksey Shipilev: > http://cr.openjdk.java.net/~shade/shenandoah/8u-logging/webrev.01/ > > This is 8u-specific patch, because we have this logging compatibility layer there. We need to make > sure -verbose:gc, PrintGC, PrintGCDetails work consistently there. Adds a test. Fixes another one. > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > Looks good From ashipile at redhat.com Thu Sep 7 17:25:17 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 07 Sep 2017 17:25:17 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Make sure -verbose:gc, PrintGC, PrintGCDetails work consistently Message-ID: <201709071725.v87HPHLk017019@aojmv0008.oracle.com> Changeset: e6b454424b51 Author: shade Date: 2017-09-07 19:22 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/e6b454424b51 Make sure -verbose:gc, PrintGC, PrintGCDetails work consistently ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahLogging.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp ! src/share/vm/runtime/arguments.cpp ! test/gc/shenandoah/TestPeriodicGC.java + test/gc/shenandoah/options/TestVerboseGC.java From rkennke at redhat.com Thu Sep 7 19:32:33 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 Sep 2017 21:32:33 +0200 Subject: RFR: Fix build Message-ID: <7264f1d8-477a-3e38-cc39-44b76a6f7e02@redhat.com> The following patch is needed to fix the build (tried slowdebug on aarch64 on RHEL 7.4): diff -r 90a2a29e9e0c src/share/vm/gc/g1/g1CollectedHeap.inline.hpp --- a/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp Thu Sep 07 12:01:54 2017 +0200 +++ b/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp Thu Sep 07 15:31:39 2017 -0400 @@ -303,7 +303,7 @@ return false; } - assert(oopDesc::is_oop(entry, true /* ignore mark word */), + assert(oopDesc::is_oop(oop(entry), true /* ignore mark word */), "Invalid oop in SATB buffer: " PTR_FORMAT, p2i(entry)); return ! isMarkedNext((oop) entry); diff -r 90a2a29e9e0c src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp --- a/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Thu Sep 07 12:01:54 2017 +0200 +++ b/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Thu Sep 07 15:31:39 2017 -0400 @@ -484,7 +484,7 @@ last = cur; cur += oop(cur)->size() + BrooksPointer::word_size(); } - assert(oopDesc::is_oop(last), + assert(oopDesc::is_oop(oop(last)), PTR_FORMAT" should be an object start", p2i(last)); return last; } Ok to push? From shade at redhat.com Thu Sep 7 19:37:08 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Sep 2017 21:37:08 +0200 Subject: RFR: Fix build In-Reply-To: <7264f1d8-477a-3e38-cc39-44b76a6f7e02@redhat.com> References: <7264f1d8-477a-3e38-cc39-44b76a6f7e02@redhat.com> Message-ID: <8dfc43f9-a338-1d48-b781-cc6942e9920f@redhat.com> On 09/07/2017 09:32 PM, Roman Kennke wrote: > The following patch is needed to fix the build (tried slowdebug on > aarch64 on RHEL 7.4): > > diff -r 90a2a29e9e0c src/share/vm/gc/g1/g1CollectedHeap.inline.hpp > --- a/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp Thu Sep 07 > 12:01:54 2017 +0200 > +++ b/src/share/vm/gc/g1/g1CollectedHeap.inline.hpp Thu Sep 07 > 15:31:39 2017 -0400 > @@ -303,7 +303,7 @@ > return false; > } > > - assert(oopDesc::is_oop(entry, true /* ignore mark word */), > + assert(oopDesc::is_oop(oop(entry), true /* ignore mark word */), > "Invalid oop in SATB buffer: " PTR_FORMAT, p2i(entry)); > > return ! isMarkedNext((oop) entry); > diff -r 90a2a29e9e0c src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp > --- a/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Thu Sep > 07 12:01:54 2017 +0200 > +++ b/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Thu Sep > 07 15:31:39 2017 -0400 > @@ -484,7 +484,7 @@ > last = cur; > cur += oop(cur)->size() + BrooksPointer::word_size(); > } > - assert(oopDesc::is_oop(last), > + assert(oopDesc::is_oop(oop(last)), > PTR_FORMAT" should be an object start", p2i(last)); > return last; > } > > > Ok to push? Ok. -Aleksey From roman at kennke.org Thu Sep 7 19:42:19 2017 From: roman at kennke.org (roman at kennke.org) Date: Thu, 07 Sep 2017 19:42:19 +0000 Subject: hg: shenandoah/jdk10/hotspot: Fix build. Message-ID: <201709071942.v87JgKWt010532@aojmv0008.oracle.com> Changeset: 94eeb38c1aa0 Author: rkennke Date: 2017-09-07 15:33 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/94eeb38c1aa0 Fix build. ! src/share/vm/gc/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp From joe.darcy at oracle.com Thu Sep 7 23:39:48 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 7 Sep 2017 16:39:48 -0700 Subject: shenandoah/jdk10 and JDK 10 repository consolidation In-Reply-To: References: Message-ID: <25349622-079b-83ea-c017-2d655164bba7@oracle.com> Hi Aleksey, On 9/7/2017 1:15 AM, Aleksey Shipilev wrote: > Hi Joe, > > On 09/07/2017 07:21 AM, joe darcy wrote: >> I see the Shenandoah project has a JDK 10 forest at >> >> http://hg.openjdk.java.net/shenandoah/jdk10/ >> >> and I wanted to discuss with the team how to handle repo consolidation with respect to your project. > We are well aware about consolidation! > > Our plan is the following: > a) Stabilize shenandoah/jdk10 > ----- we are here ----- > b) Pull recent changes from jdk10/hs (or jdk10/jdk10) -- it should be stable now; Note that we will have one final JDK 10 promotion before the integration, JDK 10 build 23. We plan to propagate those changes down to the integration forests too. > c) Stabilize shenandoah/jdk10 again > d) Export history from shenandoah/jdk10 > e) Ask ops@ to purge shenandoah/jdk10 > f) Clone consolidated jdk10/jdk10 to shenandoah/jdk10 > g) Import history to shenandoah/jdk10 > > Do you have a script that could convert changesets against "split" repository to changesets for > "consolidated" one? > Erik Joelsson has published such a script in the third generation consolidation prototype: http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000482.html http://hg.openjdk.java.net/jdk10/consol-proto/file/54b061350f8e/bin/unshuffle_patch.sh Please give it a try. Thanks, -Joe From rkennke at redhat.com Fri Sep 8 10:26:42 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 8 Sep 2017 12:26:42 +0200 Subject: RFR: Fix aarch64 Message-ID: <50811ec9-f3ff-06b2-87c9-612dc0bf2ba4@redhat.com> I tried to run some applications with Shenandoah on aarch64 and ran into an assert in the interpreter. Apparently we got some overlap of registers in the interpreter barriers. Changing rscratch2 to rscratch1 (the same registers that are used in the corresponding G1 barriers) then it all works. Tests: hotspot_gc_shenandoah (modulo 1 test that does timeout for other reasons) http://cr.openjdk.java.net/~rkennke/fixaarch64/webrev.00/ Ok? Roman From shade at redhat.com Fri Sep 8 11:22:06 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 Sep 2017 13:22:06 +0200 Subject: RFR: Fix aarch64 In-Reply-To: <50811ec9-f3ff-06b2-87c9-612dc0bf2ba4@redhat.com> References: <50811ec9-f3ff-06b2-87c9-612dc0bf2ba4@redhat.com> Message-ID: <9ea5eceb-ef84-3097-868b-3e9623dfb21e@redhat.com> On 09/08/2017 12:26 PM, Roman Kennke wrote: > I tried to run some applications with Shenandoah on aarch64 and ran into > an assert in the interpreter. Apparently we got some overlap of > registers in the interpreter barriers. Changing rscratch2 to rscratch1 > (the same registers that are used in the corresponding G1 barriers) then > it all works. > > Tests: hotspot_gc_shenandoah (modulo 1 test that does timeout for other > reasons) > > http://cr.openjdk.java.net/~rkennke/fixaarch64/webrev.00/ > > Ok? OK. -Aleksey From shade at redhat.com Fri Sep 8 14:06:07 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 Sep 2017 16:06:07 +0200 Subject: RFR: Selectable humongous threshold Message-ID: <38d3b358-002d-e57c-2442-37654e050cac@redhat.com> This implements the experimental option to choose the humongous threshold: http://cr.openjdk.java.net/~shade/shenandoah/humongous-threshold/webrev.01/ Testing: hotspot_gc_shenandoah, + new tests Thanks, -Aleksey From shade at redhat.com Fri Sep 8 14:09:26 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 Sep 2017 16:09:26 +0200 Subject: shenandoah/jdk10 and JDK 10 repository consolidation In-Reply-To: <25349622-079b-83ea-c017-2d655164bba7@oracle.com> References: <25349622-079b-83ea-c017-2d655164bba7@oracle.com> Message-ID: On 09/08/2017 01:39 AM, joe darcy wrote: >> Our plan is the following: >> a) Stabilize shenandoah/jdk10 >> ----- we are here ----- >> b) Pull recent changes from jdk10/hs (or jdk10/jdk10) -- it should be stable now; > > Note that we will have one final JDK 10 promotion before the integration, JDK 10 build 23. We plan > to propagate those changes down to the integration forests too. Okay, we shall take that in. Do you have ETA when that should happen? >> Do you have a script that could convert changesets against "split" repository to changesets for >> "consolidated" one? > > Erik Joelsson has published such a script in the third generation consolidation prototype: > > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000482.html > http://hg.openjdk.java.net/jdk10/consol-proto/file/54b061350f8e/bin/unshuffle_patch.sh > > Please give it a try. This seems to care about patches, not Mercurial changesets. Or the idea is to "hg export" to ASCII patch, run this script, and then "hg import" the unshuffled one? Going to try this some time next week. -Aleksey From roman at kennke.org Fri Sep 8 15:25:01 2017 From: roman at kennke.org (roman at kennke.org) Date: Fri, 08 Sep 2017 15:25:01 +0000 Subject: hg: shenandoah/jdk10/hotspot: Fix aarch64. Message-ID: <201709081525.v88FP2rB010467@aojmv0008.oracle.com> Changeset: 524ecbd01982 Author: rkennke Date: 2017-09-08 11:21 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/524ecbd01982 Fix aarch64. ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp From rkennke at redhat.com Fri Sep 8 15:24:42 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 8 Sep 2017 17:24:42 +0200 Subject: RFR: Factor out keep alive barriers in aarch64 Message-ID: <9e8195aa-5d0c-8c8d-a8fb-e49fed738afe@redhat.com> This is the same that I did for x86, but the aarch64 part. Test: hotspot_gc_shenandoah http://cr.openjdk.java.net/~rkennke/keepaliveaarch64/webrev/ Ok? From rkennke at redhat.com Fri Sep 8 15:25:31 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 8 Sep 2017 17:25:31 +0200 Subject: RFR: Selectable humongous threshold In-Reply-To: <38d3b358-002d-e57c-2442-37654e050cac@redhat.com> References: <38d3b358-002d-e57c-2442-37654e050cac@redhat.com> Message-ID: <68545b20-c416-40c6-54cf-c6b5117c4a43@redhat.com> Am 08.09.2017 um 16:06 schrieb Aleksey Shipilev: > This implements the experimental option to choose the humongous threshold: > http://cr.openjdk.java.net/~shade/shenandoah/humongous-threshold/webrev.01/ > > Testing: hotspot_gc_shenandoah, + new tests > > Thanks, > -Aleksey > Ok From rkennke at redhat.com Fri Sep 8 15:26:32 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 8 Sep 2017 17:26:32 +0200 Subject: shenandoah/jdk10 and JDK 10 repository consolidation In-Reply-To: References: <25349622-079b-83ea-c017-2d655164bba7@oracle.com> Message-ID: <20b6830c-b75c-855b-7205-feb8fc50eeda@redhat.com> Am 08.09.2017 um 16:09 schrieb Aleksey Shipilev: > On 09/08/2017 01:39 AM, joe darcy wrote: >>> Our plan is the following: >>> a) Stabilize shenandoah/jdk10 >>> ----- we are here ----- >>> b) Pull recent changes from jdk10/hs (or jdk10/jdk10) -- it should be stable now; >> >> Note that we will have one final JDK 10 promotion before the integration, JDK 10 build 23. We plan >> to propagate those changes down to the integration forests too. > > Okay, we shall take that in. Do you have ETA when that should happen? > >>> Do you have a script that could convert changesets against "split" repository to changesets for >>> "consolidated" one? >> >> Erik Joelsson has published such a script in the third generation consolidation prototype: >> >> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000482.html >> http://hg.openjdk.java.net/jdk10/consol-proto/file/54b061350f8e/bin/unshuffle_patch.sh >> >> Please give it a try. > > This seems to care about patches, not Mercurial changesets. Or the idea is to "hg export" to ASCII > patch, run this script, and then "hg import" the unshuffled one? Going to try this some time next week. > > -Aleksey > This could also be used in 'hg transplant' which I find a *very* useful HG plugin for dealing with backports across incompatible repositories (or stuff that needs changes on the fly). Roman From shade at redhat.com Fri Sep 8 15:26:30 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 Sep 2017 17:26:30 +0200 Subject: RFR: Factor out keep alive barriers in aarch64 In-Reply-To: <9e8195aa-5d0c-8c8d-a8fb-e49fed738afe@redhat.com> References: <9e8195aa-5d0c-8c8d-a8fb-e49fed738afe@redhat.com> Message-ID: <0300dc59-5d6e-4b10-c325-bbd2fe91a855@redhat.com> On 09/08/2017 05:24 PM, Roman Kennke wrote: > This is the same that I did for x86, but the aarch64 part. > > Test: hotspot_gc_shenandoah > > http://cr.openjdk.java.net/~rkennke/keepaliveaarch64/webrev/ > > Ok? OK. -Aleksey From roman at kennke.org Fri Sep 8 15:32:56 2017 From: roman at kennke.org (roman at kennke.org) Date: Fri, 08 Sep 2017 15:32:56 +0000 Subject: hg: shenandoah/jdk10/hotspot: Factor out keep alive barriers in aarch64. Message-ID: <201709081532.v88FWugO014654@aojmv0008.oracle.com> Changeset: 49d529af1237 Author: rkennke Date: 2017-09-08 11:23 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/49d529af1237 Factor out keep alive barriers in aarch64. ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/aarch64/vm/templateInterpreterGenerator_aarch64.cpp From ashipile at redhat.com Fri Sep 8 15:47:08 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 08 Sep 2017 15:47:08 +0000 Subject: hg: shenandoah/jdk10/hotspot: Selectable humongous threshold Message-ID: <201709081547.v88Fl8He021261@aojmv0008.oracle.com> Changeset: 4f91716062dc Author: shade Date: 2017-09-08 16:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/4f91716062dc Selectable humongous threshold ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp + test/gc/shenandoah/HumongousThreshold.java + test/gc/shenandoah/options/TestHumongousThresholdArgs.java From joe.darcy at oracle.com Fri Sep 8 16:13:14 2017 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 8 Sep 2017 09:13:14 -0700 Subject: shenandoah/jdk10 and JDK 10 repository consolidation In-Reply-To: References: <25349622-079b-83ea-c017-2d655164bba7@oracle.com> Message-ID: On 9/8/2017 7:09 AM, Aleksey Shipilev wrote: > On 09/08/2017 01:39 AM, joe darcy wrote: >>> Our plan is the following: >>> a) Stabilize shenandoah/jdk10 >>> ----- we are here ----- >>> b) Pull recent changes from jdk10/hs (or jdk10/jdk10) -- it should be stable now; >> Note that we will have one final JDK 10 promotion before the integration, JDK 10 build 23. We plan >> to propagate those changes down to the integration forests too. > Okay, we shall take that in. Do you have ETA when that should happen? If all goes according to plan, before Monday September 11. >>> Do you have a script that could convert changesets against "split" repository to changesets for >>> "consolidated" one? >> Erik Joelsson has published such a script in the third generation consolidation prototype: >> >> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000482.html >> http://hg.openjdk.java.net/jdk10/consol-proto/file/54b061350f8e/bin/unshuffle_patch.sh >> >> Please give it a try. > This seems to care about patches, not Mercurial changesets. Or the idea is to "hg export" to ASCII > patch, run this script, and then "hg import" the unshuffled one? Going to try this some time next week. > Right; I believe the current version of the script operates on patches rather than changesets. Thanks, -Joe From joe.darcy at oracle.com Fri Sep 8 18:42:36 2017 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 8 Sep 2017 11:42:36 -0700 Subject: shenandoah/jdk10 and JDK 10 repository consolidation In-Reply-To: References: <25349622-079b-83ea-c017-2d655164bba7@oracle.com> Message-ID: On 9/8/2017 9:13 AM, joe darcy wrote: > On 9/8/2017 7:09 AM, Aleksey Shipilev wrote: >> On 09/08/2017 01:39 AM, joe darcy wrote: >>>> Our plan is the following: >>>> a) Stabilize shenandoah/jdk10 >>>> ----- we are here ----- >>>> b) Pull recent changes from jdk10/hs (or jdk10/jdk10) -- it >>>> should be stable now; >>> Note that we will have one final JDK 10 promotion before the >>> integration, JDK 10 build 23. We plan >>> to propagate those changes down to the integration forests too. >> Okay, we shall take that in. Do you have ETA when that should happen? > > If all goes according to plan, before Monday September 11. > FYI, JDK 10 b23 tag now applied. Cheers, -Joe From shade at redhat.com Fri Sep 8 19:17:51 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 Sep 2017 21:17:51 +0200 Subject: RFR: JMX double-counts heap used size Message-ID: This is the regression from recent JMX fix. We should not report the same pool in both managers, because it will double the metrics the entire MemoryMXBean reports. Fix: http://cr.openjdk.java.net/~shade/shenandoah/jmx-double/webrev.01/ Testing: hotspot_gc_shenandoah + new test Thanks, -Aleksey From shade at redhat.com Fri Sep 8 19:21:29 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 Sep 2017 21:21:29 +0200 Subject: shenandoah/jdk10 and JDK 10 repository consolidation In-Reply-To: References: <25349622-079b-83ea-c017-2d655164bba7@oracle.com> Message-ID: <7d4aa22e-9e96-c618-91a8-ec7fdadf648f@redhat.com> On 09/08/2017 08:42 PM, joe darcy wrote: > On 9/8/2017 9:13 AM, joe darcy wrote: >> On 9/8/2017 7:09 AM, Aleksey Shipilev wrote: >>> On 09/08/2017 01:39 AM, joe darcy wrote: >>>>> Our plan is the following: >>>>> a) Stabilize shenandoah/jdk10 >>>>> ----- we are here ----- >>>>> b) Pull recent changes from jdk10/hs (or jdk10/jdk10) -- it should be stable now; >>>> Note that we will have one final JDK 10 promotion before the integration, JDK 10 build 23. We plan >>>> to propagate those changes down to the integration forests too. >>> Okay, we shall take that in. Do you have ETA when that should happen? >> >> If all goes according to plan, before Monday September 11. >> > > FYI, JDK 10 b23 tag now applied. Thanks, I see it. There seem to be no changes in Hotspot, so we don't care. We have pulled JDK 10 b22 this week. -Aleksey From cflood at redhat.com Fri Sep 8 19:25:22 2017 From: cflood at redhat.com (Christine Flood) Date: Fri, 8 Sep 2017 15:25:22 -0400 Subject: RFR: JMX double-counts heap used size In-Reply-To: References: Message-ID: Works for me. Looks good Thanks, Christine On Fri, Sep 8, 2017 at 3:17 PM, Aleksey Shipilev wrote: > This is the regression from recent JMX fix. We should not report the same > pool in both managers, > because it will double the metrics the entire MemoryMXBean reports. > > Fix: > http://cr.openjdk.java.net/~shade/shenandoah/jmx-double/webrev.01/ > > Testing: hotspot_gc_shenandoah + new test > > Thanks, > -Aleksey > > From ashipile at redhat.com Fri Sep 8 19:29:03 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 08 Sep 2017 19:29:03 +0000 Subject: hg: shenandoah/jdk10/hotspot: JMX double-counts heap used size Message-ID: <201709081929.v88JT3Kl019309@aojmv0008.oracle.com> Changeset: b0eaf099d8a8 Author: shade Date: 2017-09-08 21:26 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/b0eaf099d8a8 JMX double-counts heap used size ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp ! src/share/vm/services/shenandoahMemoryPool.cpp ! src/share/vm/services/shenandoahMemoryPool.hpp + test/gc/shenandoah/TestMemoryMXBeans.java From rkennke at redhat.com Fri Sep 8 19:29:07 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 8 Sep 2017 21:29:07 +0200 Subject: RFR: Increase timeout for TestGCOldWithShenandoah Message-ID: I ran into timeout problems with GCOld jtreg test on a big (but not fast) aarch64 box. This was all in heap verification code (single-threaded). Did some profiling, nothing obvious turned up, except lots of cache misses that we can't fix. This patch ups the timeout for the affected tests. http://cr.openjdk.java.net/~rkennke/timeout/webrev.00/ Ok? From shade at redhat.com Fri Sep 8 19:30:25 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 Sep 2017 21:30:25 +0200 Subject: RFR: Increase timeout for TestGCOldWithShenandoah In-Reply-To: References: Message-ID: <7ac87711-5eed-6593-2afd-7bc22b1b02f1@redhat.com> On 09/08/2017 09:29 PM, Roman Kennke wrote: > I ran into timeout problems with GCOld jtreg test on a big (but not > fast) aarch64 box. This was all in heap verification code > (single-threaded). Did some profiling, nothing obvious turned up, except > lots of cache misses that we can't fix. This patch ups the timeout for > the affected tests. > > http://cr.openjdk.java.net/~rkennke/timeout/webrev.00/ Okay, good. -Aleksey From roman at kennke.org Fri Sep 8 19:49:55 2017 From: roman at kennke.org (roman at kennke.org) Date: Fri, 08 Sep 2017 19:49:55 +0000 Subject: hg: shenandoah/jdk10/hotspot: Increase timeout for TestGCOldWithShenandoah. Message-ID: <201709081949.v88JntbE001628@aojmv0008.oracle.com> Changeset: a5d668eb33d9 Author: rkennke Date: 2017-09-08 15:47 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/a5d668eb33d9 Increase timeout for TestGCOldWithShenandoah. ! test/gc/stress/gcold/TestGCOldWithShenandoah.java From rkennke at redhat.com Fri Sep 8 22:00:24 2017 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 9 Sep 2017 00:00:24 +0200 Subject: RFR: Remove Shenandoah from TestSmallHeap jtreg test Message-ID: The TestSmallHeap test is bogus for Shenandoah. It verfies if the final max heap size is pagesize*heap_bytes_per_card. On a machine with 64K page size, this fails, because it ends up with an expected heap size of 32MB. But Shenandoah doesn't care about cards, and thus leaves heap size at 4MB (as passed in via -Xmx). I propose to remove Shenandoah from that test as quick fix. We may want to add a derived small-heap test to gc/shenandoah later. http://cr.openjdk.java.net/~rkennke/testsmallheap/webrev.00/ Test: hotspot_gc_shenandoah (well, duh, w/o that test now. but does pass all those tests on my big aarch64 box now). Ok? Or other opinions? Roman From shade at redhat.com Sat Sep 9 12:18:12 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 9 Sep 2017 14:18:12 +0200 Subject: RFR: Remove Shenandoah from TestSmallHeap jtreg test In-Reply-To: References: Message-ID: <947a6d71-feff-e2da-361c-de51e82a5f14@redhat.com> On 09/09/2017 12:00 AM, Roman Kennke wrote: > The TestSmallHeap test is bogus for Shenandoah. It verfies if the final > max heap size is pagesize*heap_bytes_per_card. On a machine with 64K > page size, this fails, because it ends up with an expected heap size of > 32MB. But Shenandoah doesn't care about cards, and thus leaves heap size > at 4MB (as passed in via -Xmx). > > I propose to remove Shenandoah from that test as quick fix. We may want > to add a derived small-heap test to gc/shenandoah later. > > http://cr.openjdk.java.net/~rkennke/testsmallheap/webrev.00/ Okay. Would be nice to split out the Shenandoah-specific test. -Aleksey From ashipile at redhat.com Mon Sep 11 10:02:13 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 11 Sep 2017 10:02:13 +0000 Subject: hg: shenandoah/jdk9/hotspot: 3 new changesets Message-ID: <201709111002.v8BA2DTl021746@aojmv0008.oracle.com> Changeset: 23228953ab8a Author: shade Date: 2017-09-11 11:35 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/23228953ab8a [backport] Selectable humongous threshold ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp + test/gc/shenandoah/HumongousThreshold.java + test/gc/shenandoah/options/TestHumongousThresholdArgs.java Changeset: 30bcce2017f7 Author: shade Date: 2017-09-11 11:36 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/30bcce2017f7 [backport] JMX double-counts heap used size ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp ! src/share/vm/services/shenandoahMemoryPool.cpp ! src/share/vm/services/shenandoahMemoryPool.hpp + test/gc/shenandoah/TestMemoryMXBeans.java Changeset: d95e74cf119f Author: shade Date: 2017-09-11 11:37 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/d95e74cf119f [backport] Increase timeout for TestGCOldWithShenandoah. ! test/gc/stress/TestGCOldWithShenandoah.java From shade at redhat.com Mon Sep 11 11:00:06 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 13:00:06 +0200 Subject: RFR: Make sure different Verifier levels work Message-ID: <03cefe8e-9f59-bdb4-67e3-ed038d005ac3@redhat.com> Setting -XX:ShenandoahVerifyLevel=0 currently fails with thread parity errors. This happens because we always instantiate ShenandoahRootsProcessor, and on some paths we don't claim threads, leading to this error. Fix: http://cr.openjdk.java.net/~shade/shenandoah/verifier-levels-test/webrev.01/ Testing: hotspot_gc_shenandoah Thanks, -Aleksey From rkennke at redhat.com Mon Sep 11 11:09:54 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 Sep 2017 13:09:54 +0200 Subject: RFR: Make sure different Verifier levels work In-Reply-To: <03cefe8e-9f59-bdb4-67e3-ed038d005ac3@redhat.com> References: <03cefe8e-9f59-bdb4-67e3-ed038d005ac3@redhat.com> Message-ID: Am 11.09.2017 um 13:00 schrieb Aleksey Shipilev: > Setting -XX:ShenandoahVerifyLevel=0 currently fails with thread parity errors. This happens because > we always instantiate ShenandoahRootsProcessor, and on some paths we don't claim threads, leading to > this error. > > Fix: > http://cr.openjdk.java.net/~shade/shenandoah/verifier-levels-test/webrev.01/ > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > Yup From roman at kennke.org Mon Sep 11 11:14:05 2017 From: roman at kennke.org (roman at kennke.org) Date: Mon, 11 Sep 2017 11:14:05 +0000 Subject: hg: shenandoah/jdk10/hotspot: Remove Shenandoah from TestSmallHeap jtreg test. Message-ID: <201709111114.v8BBE5ZS018696@aojmv0008.oracle.com> Changeset: 03f838ceddb0 Author: rkennke Date: 2017-09-11 07:11 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/03f838ceddb0 Remove Shenandoah from TestSmallHeap jtreg test. ! test/TEST.groups ! test/gc/TestSmallHeap.java From rkennke at redhat.com Mon Sep 11 11:31:21 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 Sep 2017 13:31:21 +0200 Subject: RFR: Fix/add comments on matrix barriers Message-ID: http://cr.openjdk.java.net/~rkennke/comments/webrev.00/ From ashipile at redhat.com Mon Sep 11 11:35:15 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 11 Sep 2017 11:35:15 +0000 Subject: hg: shenandoah/jdk10/hotspot: Make sure different Verifier levels work Message-ID: <201709111135.v8BBZFdD028097@aojmv0008.oracle.com> Changeset: 0915bc2afac7 Author: shade Date: 2017-09-11 13:18 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/0915bc2afac7 Make sure different Verifier levels work ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp + test/gc/shenandoah/TestVerifyLevels.java From shade at redhat.com Mon Sep 11 11:35:39 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 13:35:39 +0200 Subject: RFR: Fix/add comments on matrix barriers In-Reply-To: References: Message-ID: <91fe33eb-6d44-af50-6fa8-5f3b0808cabb@redhat.com> On 09/11/2017 01:31 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/comments/webrev.00/ Looks good. -Aleksey From roman at kennke.org Mon Sep 11 11:44:11 2017 From: roman at kennke.org (roman at kennke.org) Date: Mon, 11 Sep 2017 11:44:11 +0000 Subject: hg: shenandoah/jdk10/hotspot: Add comments in aarch64 matrix barrier, fix comment in x86 matrix barrier. Message-ID: <201709111144.v8BBiBwX000407@aojmv0008.oracle.com> Changeset: 6ba7bc11052b Author: rkennke Date: 2017-09-11 07:41 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/6ba7bc11052b Add comments in aarch64 matrix barrier, fix comment in x86 matrix barrier. ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp From shade at redhat.com Mon Sep 11 12:15:55 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 14:15:55 +0200 Subject: RFR: LotsOfCycles test always degrades to Full GC Message-ID: <6b43145e-0486-b8c8-6ca5-ac43cf0a2fcf@redhat.com> http://cr.openjdk.java.net/~shade/shenandoah/tests-lotscycles-stride/webrev.01/ This tests runs heavy allocation in a very small heaps, and always degrades to Full GC, thus defeating its purpose. The solution is to pace allocations. Thanks, -Aleksey From zgu at redhat.com Mon Sep 11 12:19:16 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 11 Sep 2017 08:19:16 -0400 Subject: RFR: LotsOfCycles test always degrades to Full GC In-Reply-To: <6b43145e-0486-b8c8-6ca5-ac43cf0a2fcf@redhat.com> References: <6b43145e-0486-b8c8-6ca5-ac43cf0a2fcf@redhat.com> Message-ID: <7c366a54-590d-78a8-8d6c-cb7009606305@redhat.com> Okay. -Zhengyu On 09/11/2017 08:15 AM, Aleksey Shipilev wrote: > http://cr.openjdk.java.net/~shade/shenandoah/tests-lotscycles-stride/webrev.01/ > > This tests runs heavy allocation in a very small heaps, and always degrades to Full GC, thus > defeating its purpose. The solution is to pace allocations. > > Thanks, > -Aleksey > From ashipile at redhat.com Mon Sep 11 12:24:54 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 11 Sep 2017 12:24:54 +0000 Subject: hg: shenandoah/jdk10/hotspot: LotsOfCycles test always degrades to Full GC Message-ID: <201709111224.v8BCOsor022727@aojmv0008.oracle.com> Changeset: 9fe565e6c944 Author: shade Date: 2017-09-11 14:16 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/9fe565e6c944 LotsOfCycles test always degrades to Full GC ! test/gc/shenandoah/LotsOfCycles.java From shade at redhat.com Mon Sep 11 12:34:23 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 14:34:23 +0200 Subject: RFR: TestSmallHeap test for Shenandoah Message-ID: <3dd86894-e6f2-0e3c-4817-9ec3bd85d546@redhat.com> http://cr.openjdk.java.net/~shade/shenandoah/tests-hw/webrev.01/ We are missing a very basic test that verifies we can start with small heap. Thanks, -Aleksey From zgu at redhat.com Mon Sep 11 12:36:37 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 11 Sep 2017 08:36:37 -0400 Subject: RFR: TestSmallHeap test for Shenandoah In-Reply-To: <3dd86894-e6f2-0e3c-4817-9ec3bd85d546@redhat.com> References: <3dd86894-e6f2-0e3c-4817-9ec3bd85d546@redhat.com> Message-ID: Good to me. -Zhengyu On 09/11/2017 08:34 AM, Aleksey Shipilev wrote: > http://cr.openjdk.java.net/~shade/shenandoah/tests-hw/webrev.01/ > > We are missing a very basic test that verifies we can start with small heap. > > Thanks, > -Aleksey > From ashipile at redhat.com Mon Sep 11 12:41:15 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 11 Sep 2017 12:41:15 +0000 Subject: hg: shenandoah/jdk10/hotspot: TestSmallHeap test for Shenandoah Message-ID: <201709111241.v8BCfFMI029162@aojmv0008.oracle.com> Changeset: 692d5c24b9dd Author: shade Date: 2017-09-11 14:35 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/692d5c24b9dd TestSmallHeap test for Shenandoah ! test/TEST.groups + test/gc/shenandoah/TestSmallHeap.java From ashipile at redhat.com Mon Sep 11 13:02:11 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 11 Sep 2017 13:02:11 +0000 Subject: hg: shenandoah/jdk10/hotspot: Amend "TestSmallHeap test for Shenandoah" with testgroup fix Message-ID: <201709111302.v8BD2BWE007243@aojmv0008.oracle.com> Changeset: fe8f1450f82b Author: shade Date: 2017-09-11 14:59 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/fe8f1450f82b Amend "TestSmallHeap test for Shenandoah" with testgroup fix ! test/TEST.groups From shade at redhat.com Mon Sep 11 13:05:32 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 15:05:32 +0200 Subject: RFR: Verifier should use BP::get_raw when getting _loc fwdptr Message-ID: This is similar to what we have elsewhere: $ hg diff diff -r fe8f1450f82b src/share/vm/gc/shenandoah/shenandoahVerifier.cpp --- a/src/share/vm/gc/shenandoah/shenandoahVerifier.cpp Mon Sep 11 14:59:19 2017 +0200 +++ b/src/share/vm/gc/shenandoah/shenandoahVerifier.cpp Mon Sep 11 15:04:39 2017 +0200 @@ -147,7 +147,7 @@ msg.append("Matrix connections:\n"); oop fwd_to = (oop) BrooksPointer::get_raw(obj); - oop fwd_from = BrooksPointer::forwardee(_loc); + oop fwd_from = (oop) BrooksPointer::get_raw(_loc); size_t from_idx = _heap->heap_region_index_containing(_loc); size_t to_idx = _heap->heap_region_index_containing(obj); Testing: hotspot_gc_shenandoah Thanks, -Aleksey From zgu at redhat.com Mon Sep 11 13:10:30 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 11 Sep 2017 09:10:30 -0400 Subject: RFR: Verifier should use BP::get_raw when getting _loc fwdptr In-Reply-To: References: Message-ID: Okay. -Zhengyu On 09/11/2017 09:05 AM, Aleksey Shipilev wrote: > This is similar to what we have elsewhere: > > $ hg diff > diff -r fe8f1450f82b src/share/vm/gc/shenandoah/shenandoahVerifier.cpp > --- a/src/share/vm/gc/shenandoah/shenandoahVerifier.cpp Mon Sep 11 14:59:19 2017 +0200 > +++ b/src/share/vm/gc/shenandoah/shenandoahVerifier.cpp Mon Sep 11 15:04:39 2017 +0200 > @@ -147,7 +147,7 @@ > msg.append("Matrix connections:\n"); > > oop fwd_to = (oop) BrooksPointer::get_raw(obj); > - oop fwd_from = BrooksPointer::forwardee(_loc); > + oop fwd_from = (oop) BrooksPointer::get_raw(_loc); > > size_t from_idx = _heap->heap_region_index_containing(_loc); > size_t to_idx = _heap->heap_region_index_containing(obj);Oka > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > From ashipile at redhat.com Mon Sep 11 13:14:50 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 11 Sep 2017 13:14:50 +0000 Subject: hg: shenandoah/jdk10/hotspot: Verifier should use BP::get_raw when getting _loc fwdptr Message-ID: <201709111314.v8BDEos0011833@aojmv0008.oracle.com> Changeset: 957389946d2c Author: shade Date: 2017-09-11 15:08 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/957389946d2c Verifier should use BP::get_raw when getting _loc fwdptr ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp From lennart.borjeson at cinnober.com Mon Sep 11 14:00:11 2017 From: lennart.borjeson at cinnober.com (=?utf-8?B?TGVubmFydCBCw7ZyamVzb24=?=) Date: Mon, 11 Sep 2017 14:00:11 +0000 Subject: Errors building shenandoah on MacOS Message-ID: Lately, when trying to compile shenandoah on MacOS, I get a lot of warnings and errors like the following (warnings I can probably live with but the errors are more troublesome): /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp:85:19: warning: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Wformat] r->first_alloc_seq_num(), r->last_alloc_seq_num(), count); ^~~~~~~~~~~~~~~~~~~~~~~~ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp:85:45: warning: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Wformat] r->first_alloc_seq_num(), r->last_alloc_seq_num(), count); ^~~~~~~~~~~~~~~~~~~~~~~ 2 warnings generated. /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp:75:11: warning: 4 enumeration values not handled in switch: '_humongous_start', '_humongous_cont', '_cset'... [-Wswitch] switch (_state) { ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp:95:11: warning: enumeration values '_humongous_start', '_humongous_cont', and '_trash' not handled in switch [-Wswitch] switch (_state) { ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp:112:11: warning: 6 enumeration values not handled in switch: '_regular', '_humongous_start', '_humongous_cont'... [-Wswitch] switch (_state) { ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp:126:11: warning: 6 enumeration values not handled in switch: '_regular', '_humongous_start', '_humongous_cont'... [-Wswitch] switch (_state) { ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp:141:11: warning: 4 enumeration values not handled in switch: '_empty_uncommitted', '_empty_committed', '_cset'... [-Wswitch] switch (_state) { ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp:161:11: warning: 4 enumeration values not handled in switch: '_empty_uncommitted', '_empty_committed', '_cset'... [-Wswitch] switch (_state) { ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp:185:11: warning: 6 enumeration values not handled in switch: '_empty_uncommitted', '_empty_committed', '_humongous_start'... [-Wswitch] switch (_state) { ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp:198:11: warning: enumeration values '_empty_uncommitted', '_empty_committed', and '_pinned' not handled in switch [-Wswitch] switch (_state) { ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp:217:11: warning: 6 enumeration values not handled in switch: '_empty_uncommitted', '_regular', '_humongous_start'... [-Wswitch] switch (_state) { ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp:231:11: warning: 6 enumeration values not handled in switch: '_regular', '_humongous_start', '_humongous_cont'... [-Wswitch] switch (_state) { ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp:356:40: warning: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Wformat] st->print("|FTS " SIZE_FORMAT_W(15), first_alloc_seq_num()); ~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp:357:40: warning: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Wformat] st->print("|LTS " SIZE_FORMAT_W(15), last_alloc_seq_num()); ~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~ 12 warnings generated. /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/opto/shenandoahSupport.cpp:1932:65: warning: for loop has empty body [-Wempty-body] for (; i < regions.length() && regions.at(i) != c; i+=2); ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/opto/shenandoahSupport.cpp:1932:65: note: put the semicolon on a separate line to silence this warning /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahVerifier.cpp:753:29: error: no matching function for call to 'load_acquire' size_t start_live = OrderAccess::load_acquire(&ld[r->humongous_start_region()->region_number()]); ^~~~~~~~~~~~~~~~~~~~~~~~~ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:55:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jbyte *' (aka 'const volatile signed char *') for 1st argument inline jbyte OrderAccess::load_acquire(const volatile jbyte* p) { return specialized_load_acquire(p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:56:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jshort *' (aka 'const volatile short *') for 1st argument inline jshort OrderAccess::load_acquire(const volatile jshort* p) { return specialized_load_acquire(p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:57:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jint *' (aka 'const volatile int *') for 1st argument inline jint OrderAccess::load_acquire(const volatile jint* p) { return specialized_load_acquire(p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:58:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jlong *' (aka 'const volatile long *') for 1st argument inline jlong OrderAccess::load_acquire(const volatile jlong* p) { return specialized_load_acquire(p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:59:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jfloat *' (aka 'const volatile float *') for 1st argument inline jfloat OrderAccess::load_acquire(const volatile jfloat* p) { return specialized_load_acquire(p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:60:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jdouble *' (aka 'const volatile double *') for 1st argument inline jdouble OrderAccess::load_acquire(const volatile jdouble* p) { return specialized_load_acquire(p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:61:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jubyte *' (aka 'const volatile unsigned char *') for 1st argument inline jubyte OrderAccess::load_acquire(const volatile jubyte* p) { return (jubyte) specialized_load_acquire((const volatile jbyte*)p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:62:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jushort *' (aka 'const volatile unsigned short *') for 1st argument inline jushort OrderAccess::load_acquire(const volatile jushort* p) { return (jushort)specialized_load_acquire((const volatile jshort*)p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:63:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile juint *' (aka 'const volatile unsigned int *') for 1st argument inline juint OrderAccess::load_acquire(const volatile juint* p) { return (juint) specialized_load_acquire((const volatile jint*)p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:64:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile julong *' (aka 'const volatile unsigned long long *') for 1st argument inline julong OrderAccess::load_acquire(const volatile julong* p) { return (julong) specialized_load_acquire((const volatile jlong*)p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/gc/shenandoah/shenandoahVerifier.cpp:758:21: error: no matching function for call to 'load_acquire' verf_live = OrderAccess::load_acquire(&ld[r->region_number()]); ^~~~~~~~~~~~~~~~~~~~~~~~~ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:55:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jbyte *' (aka 'const volatile signed char *') for 1st argument inline jbyte OrderAccess::load_acquire(const volatile jbyte* p) { return specialized_load_acquire(p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:56:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jshort *' (aka 'const volatile short *') for 1st argument inline jshort OrderAccess::load_acquire(const volatile jshort* p) { return specialized_load_acquire(p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:57:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jint *' (aka 'const volatile int *') for 1st argument inline jint OrderAccess::load_acquire(const volatile jint* p) { return specialized_load_acquire(p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:58:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jlong *' (aka 'const volatile long *') for 1st argument inline jlong OrderAccess::load_acquire(const volatile jlong* p) { return specialized_load_acquire(p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:59:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jfloat *' (aka 'const volatile float *') for 1st argument inline jfloat OrderAccess::load_acquire(const volatile jfloat* p) { return specialized_load_acquire(p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:60:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jdouble *' (aka 'const volatile double *') for 1st argument inline jdouble OrderAccess::load_acquire(const volatile jdouble* p) { return specialized_load_acquire(p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:61:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jubyte *' (aka 'const volatile unsigned char *') for 1st argument inline jubyte OrderAccess::load_acquire(const volatile jubyte* p) { return (jubyte) specialized_load_acquire((const volatile jbyte*)p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:62:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile jushort *' (aka 'const volatile unsigned short *') for 1st argument inline jushort OrderAccess::load_acquire(const volatile jushort* p) { return (jushort)specialized_load_acquire((const volatile jshort*)p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:63:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile juint *' (aka 'const volatile unsigned int *') for 1st argument inline juint OrderAccess::load_acquire(const volatile juint* p) { return (juint) specialized_load_acquire((const volatile jint*)p); } ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/runtime/orderAccess.inline.hpp:64:30: note: candidate function not viable: no known conversion from 'ShenandoahLivenessData *' (aka 'volatile unsigned long *') to 'const volatile julong *' (aka 'const volatile unsigned long long *') for 1st argument inline julong OrderAccess::load_acquire(const volatile julong* p) { return (julong) specialized_load_acquire((const volatile jlong*)p); } ^ 2 errors generated. Sadly, I?m not sufficiently knowledgable in C++ to pinpoint the error. I?m guessing there are differences in the default types in the compiler used on MacOS. Best regards, /Lennart B?rjeson From shade at redhat.com Mon Sep 11 14:09:26 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 16:09:26 +0200 Subject: Errors building shenandoah on MacOS In-Reply-To: References: Message-ID: <2ae712d1-e57c-5320-7894-ce70e1fca24b@redhat.com> Hi, On 09/11/2017 04:00 PM, Lennart B?rjeson wrote: > Sadly, I?m not sufficiently knowledgable in C++ to pinpoint the error. I?m guessing there are > differences in the default types in the compiler used on MacOS. Thanks for the logs. This is LLVM, right? We can try and fix the warnings blindly, but we would appreciate if you can try the fixes we would post on this list. -Aleksey From shade at redhat.com Mon Sep 11 14:16:20 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 16:16:20 +0200 Subject: RFR: Format mismatch for {first|last}_alloc_seq_num() Message-ID: <8b120562-7724-db64-9b99-bd581d88646b@redhat.com> Trivial fix: {first|last}_alloc_seq_num() are actually uint64_t, not size_t. $ hg diff diff -r 957389946d2c src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp --- a/src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp Mon Sep 11 15:08:31 2017 +0200 +++ b/src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp Mon Sep 11 16:13:52 2017 +0200 @@ -80,7 +80,7 @@ if (count > 0) { st->print("%8u, " SIZE_FORMAT_W(10) ", " SIZE_FORMAT_W(10) ", " SIZE_FORMAT_W(10) ", " - SIZE_FORMAT_W(8) ", " SIZE_FORMAT_W(8) ", %8u, {", + UINT64_FORMAT_W(8) ", " UINT64_FORMAT_W(8) ", %8u, {", from_idx, r->get_live_data_bytes(), r->used(), r->garbage(), r->first_alloc_seq_num(), r->last_alloc_seq_num(), count); for (uint to_idx = 0; to_idx < _stride; to_idx++) { diff -r 957389946d2c src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp --- a/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Mon Sep 11 15:08:31 2017 +0200 +++ b/src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Mon Sep 11 16:13:52 2017 +0200 @@ -353,8 +353,8 @@ st->print("|G %3d%%", (int) ((double) get_gclab_allocs() * 100 / capacity())); st->print("|S %3d%%", (int) ((double) get_shared_allocs() * 100 / capacity())); st->print("|L %3d%%", (int) ((double) get_live_data_bytes() * 100 / capacity())); - st->print("|FTS " SIZE_FORMAT_W(15), first_alloc_seq_num()); - st->print("|LTS " SIZE_FORMAT_W(15), last_alloc_seq_num()); + st->print("|FTS " UINT64_FORMAT_W(15), first_alloc_seq_num()); + st->print("|LTS " UINT64_FORMAT_W(15), last_alloc_seq_num()); if (is_root()) { st->print("|R"); } else { Testing: hotspot_fast_gc_shenandoah Thanks, -Aleksey From lennart.borjeson at cinnober.com Mon Sep 11 14:16:30 2017 From: lennart.borjeson at cinnober.com (=?utf-8?B?TGVubmFydCBCw7ZyamVzb24=?=) Date: Mon, 11 Sep 2017 14:16:30 +0000 Subject: Errors building shenandoah on MacOS Message-ID: > 11 sep. 2017 kl. 16:09 skrev Aleksey Shipilev : > > Hi, > > On 09/11/2017 04:00 PM, Lennart B?rjeson wrote: >> Sadly, I?m not sufficiently knowledgable in C++ to pinpoint the error. I?m guessing there are >> differences in the default types in the compiler used on MacOS. > > Thanks for the logs. This is LLVM, right? We can try and fix the warnings blindly, but we would > appreciate if you can try the fixes we would post on this list. > I?d be happy to test any fixes you might throw in my direction! /Lennart From shade at redhat.com Mon Sep 11 14:22:15 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 16:22:15 +0200 Subject: Errors building shenandoah on MacOS In-Reply-To: References: Message-ID: <0f366150-2e60-227a-fc6f-5189648b9465@redhat.com> On 09/11/2017 04:16 PM, Lennart B?rjeson wrote: >> 11 sep. 2017 kl. 16:09 skrev Aleksey Shipilev : >> On 09/11/2017 04:00 PM, Lennart B?rjeson wrote: >>> Sadly, I?m not sufficiently knowledgable in C++ to pinpoint the error. I?m guessing there are >>> differences in the default types in the compiler used on MacOS. >> >> Thanks for the logs. This is LLVM, right? We can try and fix the warnings blindly, but we would >> appreciate if you can try the fixes we would post on this list. >> > > I?d be happy to test any fixes you might throw in my direction! Okay, let me do the patch chain that fixes these known problems, and then you can try to apply it and build again. -Aleksey From shade at redhat.com Mon Sep 11 14:56:10 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 16:56:10 +0200 Subject: Errors building shenandoah on MacOS In-Reply-To: <0f366150-2e60-227a-fc6f-5189648b9465@redhat.com> References: <0f366150-2e60-227a-fc6f-5189648b9465@redhat.com> Message-ID: On 09/11/2017 04:22 PM, Aleksey Shipilev wrote: > On 09/11/2017 04:16 PM, Lennart B?rjeson wrote: >>> 11 sep. 2017 kl. 16:09 skrev Aleksey Shipilev : >>> On 09/11/2017 04:00 PM, Lennart B?rjeson wrote: >>>> Sadly, I?m not sufficiently knowledgable in C++ to pinpoint the error. I?m guessing there are >>>> differences in the default types in the compiler used on MacOS. >>> >>> Thanks for the logs. This is LLVM, right? We can try and fix the warnings blindly, but we would >>> appreciate if you can try the fixes we would post on this list. >>> >> >> I?d be happy to test any fixes you might throw in my direction! > > Okay, let me do the patch chain that fixes these known problems, and then you can try to apply it > and build again. How about this? http://cr.openjdk.java.net/~shade/shenandoah/try-macos-fix/webrev.01/ $ cd hotspot/ $ wget http://cr.openjdk.java.net/~shade/shenandoah/try-macos-fix/webrev.01/hotspot.changeset $ patch -p1 < hotspot.changeset Thanks, -Aleksey From lennart.borjeson at cinnober.com Mon Sep 11 15:22:46 2017 From: lennart.borjeson at cinnober.com (=?iso-8859-1?Q?Lennart_B=F6rjeson?=) Date: Mon, 11 Sep 2017 15:22:46 +0000 Subject: Errors building shenandoah on MacOS In-Reply-To: References: <0f366150-2e60-227a-fc6f-5189648b9465@redhat.com> Message-ID: > 11 sep. 2017 kl. 16:56 skrev Aleksey Shipilev : > > How about this? > http://cr.openjdk.java.net/~shade/shenandoah/try-macos-fix/webrev.01/ > > $ cd hotspot/ > $ wget http://cr.openjdk.java.net/~shade/shenandoah/try-macos-fix/webrev.01/hotspot.changeset > $ patch -p1 < hotspot.changeset > > Thanks, > -Aleksey > > Yes! That worked perfectly well, thank you. I can build and run Shenandoah! /Lennart From shade at redhat.com Mon Sep 11 15:30:14 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 17:30:14 +0200 Subject: RFR: (bulk) Fix build failures on Mac OS Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/try-macos-fix/webrev.01/ This is a bulk fix train, please review in bulk. I shall commit them as separate changesets. Brief tour of changes: *) alloc-seq-uint.patch: {first|last}_alloc_seq_num() are actually uint64_t, not size_t; *) hr-switches.patch: some compilers do not like switches that do not claim all enums; *) verifier-liveness.patch: some compilers do not like implicit size_t casts; *) for-loops.patch: some compilers do not like empty for-loop bodies; Testing: hotspot_gc_shenandoah Thanks, -Aleksey From rkennke at redhat.com Mon Sep 11 15:38:21 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 Sep 2017 17:38:21 +0200 Subject: RFR: (bulk) Fix build failures on Mac OS In-Reply-To: References: Message-ID: Am 11.09.2017 um 17:30 schrieb Aleksey Shipilev: > http://cr.openjdk.java.net/~shade/shenandoah/try-macos-fix/webrev.01/ > > This is a bulk fix train, please review in bulk. I shall commit them as separate changesets. Brief > tour of changes: > > *) alloc-seq-uint.patch: {first|last}_alloc_seq_num() are actually uint64_t, not size_t; > *) hr-switches.patch: some compilers do not like switches that do not claim all enums; > *) verifier-liveness.patch: some compilers do not like implicit size_t casts; > *) for-loops.patch: some compilers do not like empty for-loop bodies; > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > Looks good to me. From zgu at redhat.com Mon Sep 11 15:38:49 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 11 Sep 2017 11:38:49 -0400 Subject: RFR: (bulk) Fix build failures on Mac OS In-Reply-To: References: Message-ID: <0251cc28-81c0-4e89-b466-cc24bc4a863a@redhat.com> Looks good. -Zhengyu On 09/11/2017 11:30 AM, Aleksey Shipilev wrote: > http://cr.openjdk.java.net/~shade/shenandoah/try-macos-fix/webrev.01/ > > This is a bulk fix train, please review in bulk. I shall commit them as separate changesets. Brief > tour of changes: > > *) alloc-seq-uint.patch: {first|last}_alloc_seq_num() are actually uint64_t, not size_t; > *) hr-switches.patch: some compilers do not like switches that do not claim all enums; > *) verifier-liveness.patch: some compilers do not like implicit size_t casts; > *) for-loops.patch: some compilers do not like empty for-loop bodies; > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > From ashipile at redhat.com Mon Sep 11 16:13:54 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 11 Sep 2017 16:13:54 +0000 Subject: hg: shenandoah/jdk10/hotspot: 4 new changesets Message-ID: <201709111613.v8BGDs0d029457@aojmv0008.oracle.com> Changeset: 0a24c34c69b4 Author: shade Date: 2017-09-11 18:10 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/0a24c34c69b4 Fix build error: incorrect format for uint64_t values ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Changeset: 89b98d3d8b53 Author: shade Date: 2017-09-11 18:10 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/89b98d3d8b53 Fix build error: avoid loops with empty bodies ! src/share/vm/opto/shenandoahSupport.cpp Changeset: 1eef47f3f85f Author: shade Date: 2017-09-11 18:10 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/1eef47f3f85f Fix build error: switches over enums should take all enums ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Changeset: 08083048d754 Author: shade Date: 2017-09-11 18:10 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/08083048d754 Fix build error: verifier liveness should not be implicitly casted to size_t ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.hpp From shade at redhat.com Mon Sep 11 16:14:24 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 18:14:24 +0200 Subject: Errors building shenandoah on MacOS In-Reply-To: References: <0f366150-2e60-227a-fc6f-5189648b9465@redhat.com> Message-ID: <8b23ad6f-7742-6a42-fab2-2f016e0408dc@redhat.com> On 09/11/2017 05:22 PM, Lennart B?rjeson wrote: > That worked perfectly well, thank you. I can build and run Shenandoah! Pushed to shenandoah/jdk10, please try to build the clean workspace? Note that we do not regularly test on Mac OS, so your mileage may wary. It would be helpful if you try to pass jtreg tests on Mac OS. You would need this: 1. Download and unpack jtreg: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ 2. Hook up jtreg to the build: sh ./configure --with-jtreg= --with-debug-level=fastdebug 3. Run the tests: CONF=linux-x86_64-normal-server-fastdebug make images test TEST="hotspot_gc_shenandoah" Thanks, -Aleksey From shade at redhat.com Mon Sep 11 18:49:54 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 20:49:54 +0200 Subject: RFR: Common pause marker to capture everything before/after pause Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/pause-marks/webrev.01/ Our current pauses handling is inconsistent: some of them do not set up IsGCActiveMark, some of them miss record_gc_(start|stop). It makes sense to have a common "marker" for all pauses, and deal with everything that is needed to be done there. Testing: hotspot_gc_shenandoah The failure in TestShenandoahStrDedup prompted me to check the safepoint, hence the TODO. Thanks, -Aleksey From rkennke at redhat.com Mon Sep 11 18:52:43 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 Sep 2017 20:52:43 +0200 Subject: RFR: Common pause marker to capture everything before/after pause In-Reply-To: References: Message-ID: Am 11.09.2017 um 20:49 schrieb Aleksey Shipilev: > http://cr.openjdk.java.net/~shade/shenandoah/pause-marks/webrev.01/ > > Our current pauses handling is inconsistent: some of them do not set up IsGCActiveMark, some of them > miss record_gc_(start|stop). It makes sense to have a common "marker" for all pauses, and deal with > everything that is needed to be done there. > > Testing: hotspot_gc_shenandoah > > The failure in TestShenandoahStrDedup prompted me to check the safepoint, hence the TODO. > > Thanks, > -Aleksey > This looks good and useful. Go! From ashipile at redhat.com Mon Sep 11 19:08:29 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 11 Sep 2017 19:08:29 +0000 Subject: hg: shenandoah/jdk10/hotspot: Common pause marker to capture everything before/after pause Message-ID: <201709111908.v8BJ8TVh025326@aojmv0008.oracle.com> Changeset: 230b89b8e0d6 Author: shade Date: 2017-09-11 21:04 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/230b89b8e0d6 Common pause marker to capture everything before/after pause ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.cpp From shade at redhat.com Mon Sep 11 19:06:39 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 21:06:39 +0200 Subject: RFR: Two small changes to generational partial collections... In-Reply-To: <923b796e-b64f-3c5b-9e43-2f10769d6e25@redhat.com> References: <923b796e-b64f-3c5b-9e43-2f10769d6e25@redhat.com> Message-ID: <551c4947-09d4-e553-83cf-ed4cf0aee655@redhat.com> On 08/29/2017 03:35 PM, Aleksey Shipilev wrote: > On 08/29/2017 03:25 PM, Christine Flood wrote: >> Heuristics for partial gc included: >> if (used < prev_used) { >> // Major collection must have happened, "used" data is unreliable, >> wait for update. >> return false; >> } >> >> Except we weren't updating prev_used after full concurrent collections so >> we would have long dry spells with no partial collections. > > Hm, set_used_at_last_gc() is called from record_gc_end(). > > Does that mean we miss record_gc_end on update-refs path? Seems to me > VM_ShenandoahInitUpdateRefs::doit() and VM_ShenandoahFinalUpdateRefs::doit() should have the calls > to record_gc_start / record_gc_end, like other Shenandoah VM_Ops do. You don't need to do this part after recent change: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/230b89b8e0d6 Thanks, -Aleksey From shade at redhat.com Mon Sep 11 20:59:14 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Sep 2017 22:59:14 +0200 Subject: RFR: Fast-forward over humongous regions to keep "current" non-humongous Message-ID: <84c83a26-e75f-5562-f698-99f3a11db86b@redhat.com> http://cr.openjdk.java.net/~shade/shenandoah/freeset-ff/webrev.01/ There is an interesting corner case that shows up intermittently in our testing: ShFreeSet::current() fails with "should be humongous" assert. This is caused by the absence of fast-forwarding over the humongous regions in allocate_contiguous: it may so happen that the "next" region after current humongous allocation is humongous too, if heap was fragmented enough. Testing: hotspot_gc_shenandoah, stressing the failing test Thanks, -Aleksey From rkennke at redhat.com Mon Sep 11 21:17:20 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 Sep 2017 23:17:20 +0200 Subject: RFR: Fast-forward over humongous regions to keep "current" non-humongous In-Reply-To: <84c83a26-e75f-5562-f698-99f3a11db86b@redhat.com> References: <84c83a26-e75f-5562-f698-99f3a11db86b@redhat.com> Message-ID: <81DAEBEB-2AC0-469E-A6E2-A74BB24324A3@redhat.com> Ok Am 11. September 2017 22:59:14 MESZ schrieb Aleksey Shipilev : >http://cr.openjdk.java.net/~shade/shenandoah/freeset-ff/webrev.01/ > >There is an interesting corner case that shows up intermittently in our >testing: >ShFreeSet::current() fails with "should be humongous" assert. This is >caused by the absence of >fast-forwarding over the humongous regions in allocate_contiguous: it >may so happen that the "next" >region after current humongous allocation is humongous too, if heap was >fragmented enough. > >Testing: hotspot_gc_shenandoah, stressing the failing test > >Thanks, >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From ashipile at redhat.com Mon Sep 11 21:31:38 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 11 Sep 2017 21:31:38 +0000 Subject: hg: shenandoah/jdk10/hotspot: Fast-forward over humongous regions to keep "current" non-humongous Message-ID: <201709112131.v8BLVcN9001525@aojmv0008.oracle.com> Changeset: f13701dbeda7 Author: shade Date: 2017-09-11 23:16 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/f13701dbeda7 Fast-forward over humongous regions to keep "current" non-humongous ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.hpp From zgu at redhat.com Tue Sep 12 00:56:38 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 11 Sep 2017 20:56:38 -0400 Subject: RFR(S) Queuing string dedup candidates when they are evacuating at safepoints Message-ID: <6fd4c2b7-c60c-1ca0-ba76-d59cf8300780@redhat.com> String dedup protocol requires deduplication outside of safepoints. When strings are evacuated during safepoints, we need to queue the candidates and process them by string dedup thread later. Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/safepoint_strdedup/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu From shade at redhat.com Tue Sep 12 08:02:33 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 12 Sep 2017 10:02:33 +0200 Subject: RFR(S) Queuing string dedup candidates when they are evacuating at safepoints In-Reply-To: <6fd4c2b7-c60c-1ca0-ba76-d59cf8300780@redhat.com> References: <6fd4c2b7-c60c-1ca0-ba76-d59cf8300780@redhat.com> Message-ID: On 09/12/2017 02:56 AM, Zhengyu Gu wrote: > String dedup protocol requires deduplication outside of safepoints. When strings are evacuated > during safepoints, we need to queue the candidates and process them by string dedup thread later. > > Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/safepoint_strdedup/webrev.00/ Looks good. -Aleksey From lennart.borjeson at cinnober.com Tue Sep 12 08:17:48 2017 From: lennart.borjeson at cinnober.com (=?utf-8?B?TGVubmFydCBCw7ZyamVzb24=?=) Date: Tue, 12 Sep 2017 08:17:48 +0000 Subject: Errors building shenandoah on MacOS In-Reply-To: <8b23ad6f-7742-6a42-fab2-2f016e0408dc@redhat.com> References: <0f366150-2e60-227a-fc6f-5189648b9465@redhat.com> <8b23ad6f-7742-6a42-fab2-2f016e0408dc@redhat.com> Message-ID: <6750BBE6-5EC2-4A69-BFE2-EC4A85A23302@cinnober.com> 11 sep. 2017 kl. 18:14 skrev Aleksey Shipilev >: On 09/11/2017 05:22 PM, Lennart B?rjeson wrote: That worked perfectly well, thank you. I can build and run Shenandoah! Pushed to shenandoah/jdk10, please try to build the clean workspace? Note that we do not regularly test on Mac OS, so your mileage may wary. It would be helpful if you try to pass jtreg tests on Mac OS. You would need this: 1. Download and unpack jtreg: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ 2. Hook up jtreg to the build: sh ./configure --with-jtreg= --with-debug-level=fastdebug 3. Run the tests: CONF=linux-x86_64-normal-server-fastdebug make images test TEST="hotspot_gc_shenandoah" All tests PASSED. I also needed to add --disable-warnings-as-errors otherwise I got some trivial compile errors (sorry, forgot to include this in my previous post), and also some linking warnings due to my running a later MacOS (10.12) than the supposed build system (10.7, I believe). Anyway, if I configure as this: bash ./configure --disable-warnings-as-errors --with-jtreg=/opt/local/jtreg --with-debug-level=fastdebug and then: CONF=macosx-x86_64-normal-server-fastdebug make clean images test TEST="hotspot_gc_shenandoah" Everything compiles (with some warnings), builds, and passes all tests. [?] Test results: passed: 54 Report written to /Users/lennartb/RaT/openJDK/shenandoah-jdk10/build/macosx-x86_64-normal-server-fastdebug/testoutput/hotspot_gc_shenandoah/JTreport/html/report.html Results written to /Users/lennartb/RaT/openJDK/shenandoah-jdk10/build/macosx-x86_64-normal-server-fastdebug/testoutput/hotspot_gc_shenandoah/JTwork Summary: hotspot_gc_shenandoah TEST STATS: name=hotspot_gc_shenandoah run=54 pass=54 fail=0 EXIT CODE: 0 EXIT CODE: 0 Finished building targets 'clean images test' in configuration 'macosx-x86_64-normal-server-fastdebug' I summarize the compiler warnings below. If you want the full output I can mail it to you outside the mailing list. Best regards, /Lennart Compiling 11 properties into resource bundles for jdk.jartool /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/ci/ciInstanceKlass.cpp:186:21: warning: '&&' within '||' [-Wlogical-op-parentheses] if (!(offset >= 0 && offset < layout_helper() || (offset == BrooksPointer::byte_offset() && UseShenandoahGC))) { ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/ci/ciInstanceKlass.cpp:186:21: note: place parentheses around the '&&' expression to silence this warning if (!(offset >= 0 && offset < layout_helper() || (offset == BrooksPointer::byte_offset() && UseShenandoahGC))) { ^ ( ) [?] Compiling 101 properties into resource bundles for java.desktop /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/opto/escape.cpp:518:84: warning: '&&' within '||' [-Wlogical-op-parentheses] (opcode == Op_StoreP || opcode == Op_StoreN || opcode == Op_StoreNKlass) && ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/opto/escape.cpp:518:84: note: place parentheses around the '&&' expression to silence this warning (opcode == Op_StoreP || opcode == Op_StoreN || opcode == Op_StoreNKlass) && ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/opto/escape.cpp:737:84: warning: '&&' within '||' [-Wlogical-op-parentheses] (opcode == Op_StoreP || opcode == Op_StoreN || opcode == Op_StoreNKlass) && ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/opto/escape.cpp:737:84: note: place parentheses around the '&&' expression to silence this warning (opcode == Op_StoreP || opcode == Op_StoreN || opcode == Op_StoreNKlass) && ^ 2 warnings generated. [?] Creating support/symbols/ct.sym /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/opto/memnode.cpp:1135:48: warning: '&&' within '||' [-Wlogical-op-parentheses] value->in(0)->in(1)->in(0) != NULL && ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/opto/memnode.cpp:1135:48: note: place parentheses around the '&&' expression to silence this warning value->in(0)->in(1)->in(0) != NULL && ^ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/opto/memnode.cpp:1270:66: warning: '&&' within '||' [-Wlogical-op-parentheses] (count == 2) && elements[1]->Opcode() == Op_LShiftX && ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~ /Users/lennartb/RaT/openJDK/shenandoah-jdk10/hotspot/src/share/vm/opto/memnode.cpp:1270:66: note: place parentheses around the '&&' expression to silence this warning (count == 2) && elements[1]->Opcode() == Op_LShiftX && ^ 2 warnings generated. From shade at redhat.com Tue Sep 12 08:26:39 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 12 Sep 2017 10:26:39 +0200 Subject: Errors building shenandoah on MacOS In-Reply-To: <6750BBE6-5EC2-4A69-BFE2-EC4A85A23302@cinnober.com> References: <0f366150-2e60-227a-fc6f-5189648b9465@redhat.com> <8b23ad6f-7742-6a42-fab2-2f016e0408dc@redhat.com> <6750BBE6-5EC2-4A69-BFE2-EC4A85A23302@cinnober.com> Message-ID: <467b3b89-8235-6f25-a4aa-6e3461ece8c9@redhat.com> On 09/12/2017 10:17 AM, Lennart B?rjeson wrote: > All tests PASSED. Excellent, thank you! > I also needed to add --disable-warnings-as-errors otherwise I got some trivial compile errors > (sorry, forgot to include this in my previous post), and also some linking warnings due to my > running a later MacOS (10.12) than the supposed build system (10.7, I believe). We shall take a look at them a bit later. Some of these warnings are for the code we have got from upstream. It would be nice if you can try to build default jdk10/jdk10, and report build failures to hotspot-dev at . Thanks, -Aleksey From lennart.borjeson at cinnober.com Tue Sep 12 08:32:44 2017 From: lennart.borjeson at cinnober.com (=?utf-8?B?TGVubmFydCBCw7ZyamVzb24=?=) Date: Tue, 12 Sep 2017 08:32:44 +0000 Subject: Errors building shenandoah on MacOS Message-ID: > 12 sep. 2017 kl. 10:26 skrev Aleksey Shipilev : > > On 09/12/2017 10:17 AM, Lennart B?rjeson wrote: >> All tests PASSED. > > Excellent, thank you! > >> I also needed to add --disable-warnings-as-errors otherwise I got some trivial compile errors >> (sorry, forgot to include this in my previous post), and also some linking warnings due to my >> running a later MacOS (10.12) than the supposed build system (10.7, I believe). > > We shall take a look at them a bit later. Some of these warnings are for the code we have got from > upstream. It would be nice if you can try to build default jdk10/jdk10, and report build failures to > hotspot-dev at . > > I?ll do that as soon as the repository consolidation work has settled down and the smoke cleared? Best regards, /Lennart From zgu at redhat.com Tue Sep 12 11:38:53 2017 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 12 Sep 2017 11:38:53 +0000 Subject: hg: shenandoah/jdk10/hotspot: Queuing string dedup candidates when they are evacuating at safepoints Message-ID: <201709121138.v8CBcrwu013991@aojmv0008.oracle.com> Changeset: 94ddb45fce42 Author: zgu Date: 2017-09-12 07:04 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/94ddb45fce42 Queuing string dedup candidates when they are evacuating at safepoints ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahStringDedup.cpp ! src/share/vm/gc/shenandoah/shenandoahStringDedup.hpp From shade at redhat.com Tue Sep 12 12:38:14 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 12 Sep 2017 14:38:14 +0200 Subject: RFR: Humongous top() should be correct for iteration Message-ID: Setting ShenandoahHumongousThreshold=90 starts to crash VM during object iteration. This happens because we set "top" to "end" in humongous allocation path, and iteration uses that as the scanning boundary. This is incorrect with non-full humongous start region, which does not have anything past the actual object. While fixing that, we can also make humongous regions report their true use (because we put correct "top") and liveness. Fix: http://cr.openjdk.java.net/~shade/shenandoah/humongous-use/webrev.02/ Testing: hotspot_gc_shenandoah + added failing config to the test Thanks, -Aleksey From zgu at redhat.com Tue Sep 12 13:08:20 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 12 Sep 2017 09:08:20 -0400 Subject: RFR: Humongous top() should be correct for iteration In-Reply-To: References: Message-ID: <355c4f1d-364b-0571-a153-00a704d70af0@redhat.com> Looks good. -Zhengyu On 09/12/2017 08:38 AM, Aleksey Shipilev wrote: > Setting ShenandoahHumongousThreshold=90 starts to crash VM during object iteration. This happens > because we set "top" to "end" in humongous allocation path, and iteration uses that as the scanning > boundary. This is incorrect with non-full humongous start region, which does not have anything past > the actual object. While fixing that, we can also make humongous regions report their true use > (because we put correct "top") and liveness. > > Fix: > http://cr.openjdk.java.net/~shade/shenandoah/humongous-use/webrev.02/ > > Testing: hotspot_gc_shenandoah + added failing config to the test > > Thanks, > -Aleksey > From ashipile at redhat.com Tue Sep 12 13:11:56 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 12 Sep 2017 13:11:56 +0000 Subject: hg: shenandoah/jdk10/hotspot: Humongous top() should be correct for iteration Message-ID: <201709121311.v8CDBump002710@aojmv0008.oracle.com> Changeset: d0087940eda5 Author: shade Date: 2017-09-12 14:45 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/d0087940eda5 Humongous top() should be correct for iteration ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! test/gc/shenandoah/HumongousThreshold.java From shade at redhat.com Tue Sep 12 13:37:06 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 12 Sep 2017 15:37:06 +0200 Subject: RFR: All non-empty regions should have timestamps set Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/region-ts/webrev.01/ Refactor timestamp issuance code so that all non-empty regions, humongous included, get their timestamps. Verifier checks that too now. Testing: hotspot_gc_shenandoah Thanks, -Aleksey From roman at kennke.org Tue Sep 12 14:27:00 2017 From: roman at kennke.org (Roman Kennke) Date: Tue, 12 Sep 2017 16:27:00 +0200 Subject: RFR: All non-empty regions should have timestamps set In-Reply-To: References: Message-ID: <2433B4C8-AF09-4A51-BFA4-662B5AABCB51@kennke.org> Ok Am 12. September 2017 15:37:06 MESZ schrieb Aleksey Shipilev : >http://cr.openjdk.java.net/~shade/shenandoah/region-ts/webrev.01/ > >Refactor timestamp issuance code so that all non-empty regions, >humongous included, get their >timestamps. Verifier checks that too now. > >Testing: hotspot_gc_shenandoah > >Thanks, >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From ashipile at redhat.com Tue Sep 12 14:32:53 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 12 Sep 2017 14:32:53 +0000 Subject: hg: shenandoah/jdk10/hotspot: All non-empty regions should have timestamps set Message-ID: <201709121432.v8CEWrM1009878@aojmv0008.oracle.com> Changeset: 8ae976b1d043 Author: shade Date: 2017-09-12 15:45 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/8ae976b1d043 All non-empty regions should have timestamps set ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp From cflood at redhat.com Tue Sep 12 16:40:32 2017 From: cflood at redhat.com (Christine Flood) Date: Tue, 12 Sep 2017 12:40:32 -0400 Subject: Updated fix for jdk10 Generational Partial Heuristics... Message-ID: After: export JAVA_HOME=/home/chf/next/jdk10/build/linux-x86_64-normal-server-release/images/jdk Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 230.189 sec Before: export JAVA_HOME=/home/chf/next/jdk10_clean/build/linux-x86_64-normal-server-release/images/jdk Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 245.169 sec Webrev: http://cr.openjdk.java.net/~chf/GenerationalHeuristics/ Christine From shade at redhat.com Tue Sep 12 16:51:27 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 12 Sep 2017 18:51:27 +0200 Subject: Updated fix for jdk10 Generational Partial Heuristics... In-Reply-To: References: Message-ID: <545284e4-1ff7-ada3-0daa-b0be2d58d679@redhat.com> On 09/12/2017 06:40 PM, Christine Flood wrote: > Webrev: http://cr.openjdk.java.net/~chf/GenerationalHeuristics/ *) The correct idiom is: if (FLAG_IS_DEFAULT(ShenandoahRefProcFrequency)) { FLAG_SET_DEFAULT(ShenandoahRefProcFrequency, 1); } We use unconditional sets when option should be disabled without user intervening with it. *) Seems to me that entire deal with initialize() method can be gone if ShenandoahPartialHeuristics constructor accepts the size_t parameter for from_idxs initialization. You can seed it off the static const: static const size_t DEFAULT_THRESHOLD = 100; ShenandoahGenerationalPartialHeuristics() : ShenandoahPartialHeuristics(DEFAULT_THRESHOLD) { if (FLAG_IS_DEFAULT(ShenandoahPartialInboundThreshold)) { FLAG_SET_DEFAULT(ShenandoahPartialInboundThreshold, DEFAULT_THRESHOLD); } } *) This line is superfluous: 942 log_info(gc)("Initializing partial collection from_idxs"); *) Do the block at new line: 1233 if (maybe_add_heap_region(contender, collection_set)) { count++;} if (maybe_add_heap_region(contender, collection_set)) { count++; } Thanks, -Aleksey From shade at redhat.com Tue Sep 12 16:54:10 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 12 Sep 2017 18:54:10 +0200 Subject: Updated fix for jdk10 Generational Partial Heuristics... In-Reply-To: <545284e4-1ff7-ada3-0daa-b0be2d58d679@redhat.com> References: <545284e4-1ff7-ada3-0daa-b0be2d58d679@redhat.com> Message-ID: On 09/12/2017 06:51 PM, Aleksey Shipilev wrote: > *) Seems to me that entire deal with initialize() method can be gone if ShenandoahPartialHeuristics > constructor accepts the size_t parameter for from_idxs initialization. You can seed it off the > static const: > > static const size_t DEFAULT_THRESHOLD = 100; > > ShenandoahGenerationalPartialHeuristics() : ShenandoahPartialHeuristics(DEFAULT_THRESHOLD) { > if (FLAG_IS_DEFAULT(ShenandoahPartialInboundThreshold)) { > FLAG_SET_DEFAULT(ShenandoahPartialInboundThreshold, DEFAULT_THRESHOLD); > } > } Or screw it, and just initialize from_idx with num_regions() size? -Aleksey From ashipile at redhat.com Tue Sep 12 18:20:01 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 12 Sep 2017 18:20:01 +0000 Subject: hg: shenandoah/jdk9/hotspot: 13 new changesets Message-ID: <201709121820.v8CIK2dn001075@aojmv0008.oracle.com> Changeset: 7508dff42878 Author: shade Date: 2017-09-12 18:36 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/7508dff42878 [backport] Remove Shenandoah from TestSmallHeap jtreg test. ! test/TEST.groups ! test/gc/TestSmallHeap.java Changeset: 8b9b1e201177 Author: shade Date: 2017-09-12 18:37 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/8b9b1e201177 [backport] Make sure different Verifier levels work ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp + test/gc/shenandoah/TestVerifyLevels.java Changeset: 2482cbb1ef2c Author: shade Date: 2017-09-12 18:58 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/2482cbb1ef2c [backport] Fix aarch64. ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Changeset: b282f97ffcd3 Author: shade Date: 2017-09-12 19:00 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/b282f97ffcd3 [backport] Add comments in aarch64 matrix barrier, fix comment in x86 matrix barrier. ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp Changeset: 17aa25d11bbe Author: shade Date: 2017-09-12 19:01 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/17aa25d11bbe [backport] LotsOfCycles test always degrades to Full GC ! test/gc/shenandoah/LotsOfCycles.java Changeset: 56dd311c488f Author: shade Date: 2017-09-12 19:02 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/56dd311c488f [backport] TestSmallHeap test for Shenandoah ! test/TEST.groups + test/gc/shenandoah/TestSmallHeap.java Changeset: 925d23737a99 Author: shade Date: 2017-09-12 19:02 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/925d23737a99 [backport] Verifier should use BP::get_raw when getting _loc fwdptr ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp Changeset: 219abdf11bcd Author: shade Date: 2017-09-12 19:04 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/219abdf11bcd [backport] Fix build error: incorrect format for uint64_t values ! src/share/vm/gc/shenandoah/shenandoahConnectionMatrix.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Changeset: dc9de25911a5 Author: shade Date: 2017-09-12 19:05 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/dc9de25911a5 [backport] Fix build error: avoid loops with empty bodies ! src/share/vm/opto/shenandoahSupport.cpp Changeset: 5faf0f339aa4 Author: shade Date: 2017-09-12 19:06 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/5faf0f339aa4 [backport] Fix build error: switches over enums should take all enums ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp Changeset: c10c0181e865 Author: shade Date: 2017-09-12 19:22 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/c10c0181e865 [backport] Fix build error: verifier liveness should not be implicitly casted to size_t ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.hpp Changeset: 1a5ed6135447 Author: shade Date: 2017-09-12 19:35 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/1a5ed6135447 [backport] Common pause marker to capture everything before/after pause ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.cpp Changeset: 2f71f3d10b01 Author: shade Date: 2017-09-12 19:36 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/2f71f3d10b01 [backport] Fast-forward over humongous regions to keep "current" non-humongous ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.hpp From shade at redhat.com Wed Sep 13 09:56:11 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 Sep 2017 11:56:11 +0200 Subject: RFR: Cap heap size for TestRegionSizeArgs test Message-ID: <5ba5be28-47e3-fbdf-a352-19082c15bbb4@redhat.com> http://cr.openjdk.java.net/~shade/shenandoah/tests-trgs/webrev.01/ On large machine that has enormous default heap size, TestRegionSizeArgs begins to timeout. This happens for small heap region size settings which yields lots of regions. The startup sequence in Shenandoah adds all these regions into the freeset *and* it checks contains() on them in assert, which exhibits quadratic behavior. Thanks, -Aleksey From rkennke at redhat.com Wed Sep 13 10:10:04 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 Sep 2017 12:10:04 +0200 Subject: RFR: Cap heap size for TestRegionSizeArgs test In-Reply-To: <5ba5be28-47e3-fbdf-a352-19082c15bbb4@redhat.com> References: <5ba5be28-47e3-fbdf-a352-19082c15bbb4@redhat.com> Message-ID: <5708656b-290a-e59d-7be7-f5336cd8dd55@redhat.com> Am 13.09.2017 um 11:56 schrieb Aleksey Shipilev: > http://cr.openjdk.java.net/~shade/shenandoah/tests-trgs/webrev.01/ > > On large machine that has enormous default heap size, TestRegionSizeArgs begins to timeout. This > happens for small heap region size settings which yields lots of regions. The startup sequence in > Shenandoah adds all these regions into the freeset *and* it checks contains() on them in assert, > which exhibits quadratic behavior. > > Thanks, > -Aleksey > OK From ashipile at redhat.com Wed Sep 13 10:13:31 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 13 Sep 2017 10:13:31 +0000 Subject: hg: shenandoah/jdk10/hotspot: Cap heap size for TestRegionSizeArgs test Message-ID: <201709131013.v8DADVvt006087@aojmv0008.oracle.com> Changeset: 7ccdc534e493 Author: shade Date: 2017-09-13 12:10 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/7ccdc534e493 Cap heap size for TestRegionSizeArgs test ! test/gc/shenandoah/options/TestRegionSizeArgs.java From ashipile at redhat.com Wed Sep 13 10:48:16 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 13 Sep 2017 10:48:16 +0000 Subject: hg: shenandoah/jdk9/hotspot: 4 new changesets Message-ID: <201709131048.v8DAmHcc021400@aojmv0008.oracle.com> Changeset: 148b6110a760 Author: shade Date: 2017-09-13 12:22 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/148b6110a760 [backport] Queuing string dedup candidates when they are evacuating at safepoints ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahStringDedup.cpp ! src/share/vm/gc/shenandoah/shenandoahStringDedup.hpp Changeset: 87009ee287eb Author: shade Date: 2017-09-13 12:23 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/87009ee287eb [backport] Humongous top() should be correct for iteration ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! test/gc/shenandoah/HumongousThreshold.java Changeset: 19bf362dd0e2 Author: shade Date: 2017-09-13 12:23 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/19bf362dd0e2 [backport] All non-empty regions should have timestamps set ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp Changeset: 8f1944655284 Author: shade Date: 2017-09-13 12:39 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/8f1944655284 [backport] Cap heap size for TestRegionSizeArgs test ! test/gc/shenandoah/options/TestRegionSizeArgs.java From shade at redhat.com Wed Sep 13 11:38:52 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 Sep 2017 13:38:52 +0200 Subject: RFC: jdk10+23 merge Message-ID: <42d91a94-e3b8-2e5a-acc9-288169f1741e@redhat.com> Hi, There is the final pre-consolidation merge from jdk10/jdk10, that brings lots of things for jdk/ (mostly client fixes), and nothing in other subrepos. It makes sense to pick it up anyway for sanity. Ok? Passes hotspot_gc_shenandoah Thanks, -Aleksey From rkennke at redhat.com Wed Sep 13 19:33:58 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 Sep 2017 21:33:58 +0200 Subject: RFC: jdk10+23 merge In-Reply-To: <42d91a94-e3b8-2e5a-acc9-288169f1741e@redhat.com> References: <42d91a94-e3b8-2e5a-acc9-288169f1741e@redhat.com> Message-ID: <3feca676-5827-14da-f9fd-e7007f8fb654@redhat.com> Am 13.09.2017 um 13:38 schrieb Aleksey Shipilev: > Hi, > > There is the final pre-consolidation merge from jdk10/jdk10, that brings lots of things for jdk/ > (mostly client fixes), and nothing in other subrepos. It makes sense to pick it up anyway for > sanity. Ok? > > Passes hotspot_gc_shenandoah > > Thanks, > -Aleksey > Yes of course From ashipile at redhat.com Wed Sep 13 19:37:21 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 13 Sep 2017 19:37:21 +0000 Subject: hg: shenandoah/jdk10/corba: Added tag jdk-10+23 for changeset 479805760256 Message-ID: <201709131937.v8DJbLP9012103@aojmv0008.oracle.com> Changeset: 821b4751ba97 Author: lana Date: 2017-09-08 18:24 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/corba/rev/821b4751ba97 Added tag jdk-10+23 for changeset 479805760256 ! .hgtags From ashipile at redhat.com Wed Sep 13 19:37:23 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 13 Sep 2017 19:37:23 +0000 Subject: hg: shenandoah/jdk10/jaxp: Added tag jdk-10+23 for changeset 7b77f4c26025 Message-ID: <201709131937.v8DJbN64012161@aojmv0008.oracle.com> Changeset: 784201b9cfc4 Author: lana Date: 2017-09-08 18:24 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jaxp/rev/784201b9cfc4 Added tag jdk-10+23 for changeset 7b77f4c26025 ! .hgtags From ashipile at redhat.com Wed Sep 13 19:37:23 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 13 Sep 2017 19:37:23 +0000 Subject: hg: shenandoah/jdk10/jaxws: Added tag jdk-10+23 for changeset 3aaaaf69b6c3 Message-ID: <201709131937.v8DJbNjF012190@aojmv0008.oracle.com> Changeset: eabfe5e1affc Author: lana Date: 2017-09-08 18:24 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jaxws/rev/eabfe5e1affc Added tag jdk-10+23 for changeset 3aaaaf69b6c3 ! .hgtags From ashipile at redhat.com Wed Sep 13 19:37:24 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 13 Sep 2017 19:37:24 +0000 Subject: hg: shenandoah/jdk10/langtools: Added tag jdk-10+23 for changeset 214ffa12262b Message-ID: <201709131937.v8DJbOgi012263@aojmv0008.oracle.com> Changeset: 19293ea3999f Author: lana Date: 2017-09-08 18:24 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/langtools/rev/19293ea3999f Added tag jdk-10+23 for changeset 214ffa12262b ! .hgtags From ashipile at redhat.com Wed Sep 13 19:37:26 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 13 Sep 2017 19:37:26 +0000 Subject: hg: shenandoah/jdk10/nashorn: Added tag jdk-10+23 for changeset f5bdafee7f93 Message-ID: <201709131937.v8DJbQD1012294@aojmv0008.oracle.com> Changeset: 3397ed166912 Author: lana Date: 2017-09-08 18:24 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/nashorn/rev/3397ed166912 Added tag jdk-10+23 for changeset f5bdafee7f93 ! .hgtags From ashipile at redhat.com Wed Sep 13 19:37:29 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 13 Sep 2017 19:37:29 +0000 Subject: hg: shenandoah/jdk10/hotspot: 2 new changesets Message-ID: <201709131937.v8DJbT8O012306@aojmv0008.oracle.com> Changeset: 5ab7a67bc155 Author: lana Date: 2017-09-08 18:24 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/5ab7a67bc155 Added tag jdk-10+23 for changeset 1a9c2e07a826 ! .hgtags Changeset: 9b67b38d86b6 Author: shade Date: 2017-09-13 13:07 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/9b67b38d86b6 Merge ! .hgtags From ashipile at redhat.com Wed Sep 13 19:37:39 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 13 Sep 2017 19:37:39 +0000 Subject: hg: shenandoah/jdk10: 21 new changesets Message-ID: <201709131937.v8DJbd3g012638@aojmv0008.oracle.com> Changeset: 2745676498c8 Author: erikj Date: 2017-09-04 13:36 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/2745676498c8 8185928: Generate OpenJDK builds for Mac platform JDK 9.0.3 and beyond in Mach 5 Reviewed-by: ihse, tbell ! common/conf/jib-profiles.js Changeset: 13a1041e2950 Author: erikj Date: 2017-09-06 16:05 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/13a1041e2950 8186983: CompileJavaModule.gmk overrides values from a custom extension gmk Reviewed-by: ihse, dholmes Contributed-by: jason_yong at uk.ibm.com ! make/CompileJavaModules.gmk Changeset: 4a19a122c9c0 Author: psadhukhan Date: 2017-05-27 12:52 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/4a19a122c9c0 6461834: Minimize WindowsLookAndFeel classes included with Unix JDKs Reviewed-by: ihse, aniyogi, prr ! make/CompileJavaModules.gmk Changeset: 0ab1563646b3 Author: prr Date: 2017-06-02 14:46 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/0ab1563646b3 Merge ! make/CompileJavaModules.gmk - test/lib/jdk/test/lib/wrappers/InfiniteLoop.java - test/lib/jdk/test/lib/wrappers/TimeLimitedRunner.java Changeset: e578a44a664d Author: prr Date: 2017-06-23 09:53 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/e578a44a664d Merge ! make/CompileJavaModules.gmk Changeset: 3c6d0016ac56 Author: prr Date: 2017-07-06 09:36 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/3c6d0016ac56 Merge Changeset: 2979523627fc Author: prr Date: 2017-07-17 09:13 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/2979523627fc Merge Changeset: bad488f91279 Author: prr Date: 2017-07-20 09:38 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/bad488f91279 Merge Changeset: b5cbad5e2d2b Author: psadhukhan Date: 2017-07-21 10:22 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/b5cbad5e2d2b 8184813: Class javax/swing/plaf/metal/MetalFontDesktopProperty is broken in JDK10 Reviewed-by: prr, serb ! make/CompileJavaModules.gmk Changeset: 7ddec150df64 Author: prr Date: 2017-07-25 14:07 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/7ddec150df64 Merge Changeset: 6ffac2137a73 Author: prr Date: 2017-07-27 12:36 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/6ffac2137a73 Merge Changeset: ff0a3ced95bb Author: prr Date: 2017-08-07 09:45 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/ff0a3ced95bb Merge Changeset: 06a8738dc385 Author: prr Date: 2017-08-14 10:48 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/06a8738dc385 Merge Changeset: b135df98eeb6 Author: prr Date: 2017-08-18 11:27 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/b135df98eeb6 Merge - common/autoconf/lib-elf.m4 ! make/CompileJavaModules.gmk Changeset: 2c6a29c6d5c7 Author: prr Date: 2017-08-23 12:05 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/2c6a29c6d5c7 Merge Changeset: 6e6404f32f75 Author: prr Date: 2017-08-29 10:48 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/6e6404f32f75 Merge Changeset: c28ca694db97 Author: prr Date: 2017-08-31 10:49 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/c28ca694db97 Merge Changeset: b32db08bea9a Author: prr Date: 2017-09-05 10:10 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/b32db08bea9a Merge Changeset: dbc0484fa215 Author: prr Date: 2017-09-07 08:52 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/dbc0484fa215 Merge ! make/CompileJavaModules.gmk Changeset: 62306e615de1 Author: lana Date: 2017-09-08 18:24 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/62306e615de1 Added tag jdk-10+23 for changeset dbc0484fa215 ! .hgtags Changeset: 9fa9fde43b77 Author: shade Date: 2017-09-13 13:08 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/rev/9fa9fde43b77 Merge From ashipile at redhat.com Wed Sep 13 19:38:03 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Wed, 13 Sep 2017 19:38:03 +0000 Subject: hg: shenandoah/jdk10/jdk: 76 new changesets Message-ID: <201709131938.v8DJc5gO013015@aojmv0008.oracle.com> Changeset: 4276a5e50032 Author: xiaofeya Date: 2017-09-04 17:46 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/4276a5e50032 8134989: java/net/MulticastSocket/TestInterfaces.java failed due to unexpected IP address Reviewed-by: rriggs, chegar, msheppar ! test/java/net/MulticastSocket/TestInterfaces.java Changeset: a6c0c022f56f Author: lbourges Date: 2017-05-17 22:05 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/a6c0c022f56f 8180055: Upgrade the Marlin renderer in Java2D Summary: added the double-precision variant + MarlinFX backports + Improved MarlinTileGenerator + higher precision of the cubic / quadratic curve Reviewed-by: flar, pnarayanan ! src/java.desktop/share/classes/sun/java2d/marlin/ArrayCacheConst.java ! src/java.desktop/share/classes/sun/java2d/marlin/ByteArrayCache.java ! src/java.desktop/share/classes/sun/java2d/marlin/CollinearSimplifier.java ! src/java.desktop/share/classes/sun/java2d/marlin/Curve.java + src/java.desktop/share/classes/sun/java2d/marlin/DCollinearSimplifier.java + src/java.desktop/share/classes/sun/java2d/marlin/DCurve.java + src/java.desktop/share/classes/sun/java2d/marlin/DDasher.java + src/java.desktop/share/classes/sun/java2d/marlin/DHelpers.java + src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java + src/java.desktop/share/classes/sun/java2d/marlin/DPathConsumer2D.java + src/java.desktop/share/classes/sun/java2d/marlin/DRenderer.java + src/java.desktop/share/classes/sun/java2d/marlin/DRendererContext.java + src/java.desktop/share/classes/sun/java2d/marlin/DStroker.java + src/java.desktop/share/classes/sun/java2d/marlin/DTransformingPathConsumer2D.java ! src/java.desktop/share/classes/sun/java2d/marlin/Dasher.java + src/java.desktop/share/classes/sun/java2d/marlin/DoubleArrayCache.java ! src/java.desktop/share/classes/sun/java2d/marlin/FloatArrayCache.java ! src/java.desktop/share/classes/sun/java2d/marlin/FloatMath.java ! src/java.desktop/share/classes/sun/java2d/marlin/Helpers.java + src/java.desktop/share/classes/sun/java2d/marlin/IRendererContext.java ! src/java.desktop/share/classes/sun/java2d/marlin/IntArrayCache.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinCache.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinConst.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinProperties.java + src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderer.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinTileGenerator.java ! src/java.desktop/share/classes/sun/java2d/marlin/OffHeapArray.java ! src/java.desktop/share/classes/sun/java2d/marlin/Renderer.java ! src/java.desktop/share/classes/sun/java2d/marlin/RendererContext.java ! src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java ! src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java ! src/java.desktop/share/classes/sun/java2d/marlin/Version.java ! src/java.desktop/share/classes/sun/java2d/pipe/RenderingEngine.java Changeset: c4822869431e Author: ssadetsky Date: 2017-05-19 07:25 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/c4822869431e 8132299: Shift + Mouse wheel ScrollPane horizontal scrolling doesn't work on Linux but works on Mac. Reviewed-by: arapte, azvegint ! src/java.desktop/unix/native/libawt_xawt/xawt/XWindow.c ! test/java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java Changeset: 8af6f583c64e Author: psadhukhan Date: 2017-05-22 11:21 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/8af6f583c64e 7042497: javax.swing.JOptionPane.showInternalConfirmDialog throws RuntimeException Reviewed-by: ssadetsky, aniyogi ! src/java.desktop/share/classes/javax/swing/JOptionPane.java + test/javax/swing/JOptionPane/7042497/JOptionPaneConfirmDlgTest.java Changeset: 78765a0b65f2 Author: prr Date: 2017-05-22 09:34 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/78765a0b65f2 Merge - src/java.base/share/specs/serialization/changelog.md - src/java.base/share/specs/serialization/images/class.gif - test/java/nio/channels/DatagramChannel/NetworkConfiguration.java - test/lib/testlibrary/jdk/testlibrary/FilterClassLoader.java - test/lib/testlibrary/jdk/testlibrary/IOUtils.java - test/lib/testlibrary/jdk/testlibrary/NetworkConfiguration.java - test/lib/testlibrary/jdk/testlibrary/ParentLastURLClassLoader.java - test/lib/testlibrary/jdk/testlibrary/SerializationUtils.java - test/lib/testlibrary/jdk/testlibrary/management/InputArguments.java Changeset: 1df761aac102 Author: prr Date: 2017-05-25 09:15 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/1df761aac102 Merge - src/java.base/share/classes/sun/security/ssl/RecordType.java - test/lib/testlibrary/ModuleInfoMaker.java - test/lib/testlibrary/jdk/testlibrary/LockFreeLogManager.java - test/lib/testlibrary/jdk/testlibrary/management/ThreadMXBeanTool.java Changeset: c7bdf294af3f Author: psadhukhan Date: 2017-05-27 12:55 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/c7bdf294af3f 6461834: Minimize WindowsLookAndFeel classes included with Unix JDKs Reviewed-by: ihse, aniyogi, prr ! src/java.desktop/share/classes/module-info.java + src/java.desktop/windows/classes/module-info.java.extra ! test/com/sun/java/swing/plaf/windows/Test6824600.java ! test/javax/swing/JButton/4796987/bug4796987.java ! test/javax/swing/JComboBox/4199622/bug4199622.java ! test/javax/swing/JComboBox/8015300/Test8015300.java ! test/javax/swing/JFileChooser/8046391/bug8046391.java ! test/javax/swing/JInternalFrame/6725409/bug6725409.java ! test/javax/swing/JSlider/6524424/bug6524424.java ! test/javax/swing/JTree/8004298/bug8004298.java ! test/javax/swing/border/Test4856008.java ! test/javax/swing/border/Test6978482.java Changeset: 13f281a646ec Author: prr Date: 2017-06-02 14:45 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/13f281a646ec Merge - make/data/docs-resources/specs/resources/jdk-default.css - test/java/io/Serializable/evolution/AddedExternField/run.sh - test/java/io/Serializable/evolution/RenamePackage/run.sh - test/java/io/Serializable/maskSyntheticModifier/Test.java - test/java/io/Serializable/maskSyntheticModifier/run.sh - test/java/io/Serializable/packageAccess/Test.java - test/java/io/Serializable/packageAccess/run.sh - test/java/io/Serializable/resolveClass/consTest/Test.java - test/java/io/Serializable/resolveClass/consTest/run.sh - test/java/io/Serializable/resolveClass/deserializeButton/Test.java - test/java/io/Serializable/resolveClass/deserializeButton/run.sh - test/java/io/Serializable/serialver/classpath/Test.java - test/java/io/Serializable/serialver/classpath/run.sh - test/java/io/Serializable/serialver/nested/Test.java - test/java/io/Serializable/serialver/nested/run.sh - test/java/io/Serializable/subclass/Test.java - test/java/io/Serializable/subclass/run.sh - test/java/io/Serializable/superclassDataLoss/Test.java - test/java/io/Serializable/superclassDataLoss/run.sh - test/java/io/Serializable/unnamedPackageSwitch/Test.java - test/java/io/Serializable/unnamedPackageSwitch/run.sh - test/java/net/Socket/OldSocketImpl.sh - test/java/net/URL/B5086147.sh - test/java/net/URLClassLoader/B5077773.java - test/java/net/URLClassLoader/B5077773.sh - test/java/net/URLClassLoader/closetest/build.sh - test/java/net/URLClassLoader/closetest/build2.sh - test/java/net/URLClassLoader/getresourceasstream/test.sh - test/java/net/URLClassLoader/sealing/checksealed.sh - test/java/net/URLConnection/6212146/test.sh - test/java/net/URLConnection/UNCTest.sh - test/java/nio/Buffer/LimitDirectMemory.sh - test/java/nio/channels/AsynchronousChannelGroup/Attack.java - test/java/nio/channels/AsynchronousChannelGroup/PrivilegedThreadFactory.java - test/java/nio/channels/AsynchronousChannelGroup/run_any_task.sh - test/lib/testlibrary/JavaToolUtils.java - test/lib/testlibrary/jdk/testlibrary/FileUtils.java - test/lib/testlibrary/jdk/testlibrary/JarUtils.java - test/lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/CodeCacheOverflowProcessor.java - test/lib/testlibrary/jsr292/com/oracle/testlibrary/jsr292/Helper.java - test/tools/jar/multiRelease/data/runtimetest/base/testpackage/Helper.java - test/tools/jar/multiRelease/data/runtimetest/base/testpackage/Main.java - test/tools/jar/multiRelease/data/runtimetest/base/versionResource - test/tools/jar/multiRelease/data/runtimetest/v10/testpackage/Helper.java - test/tools/jar/multiRelease/data/runtimetest/v10/testpackage/Main.java - test/tools/jar/multiRelease/data/runtimetest/v10/versionResource - test/tools/jar/multiRelease/data/runtimetest/v9/testpackage/Helper.java - test/tools/jar/multiRelease/data/runtimetest/v9/testpackage/Main.java - test/tools/jar/multiRelease/data/runtimetest/v9/versionResource Changeset: d23d309ef85a Author: psadhukhan Date: 2017-06-06 10:58 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/d23d309ef85a 6962725: Regtest javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux Reviewed-by: serb ! test/javax/swing/JFileChooser/6738668/bug6738668.java ! test/javax/swing/JFileChooser/6738668/security.policy Changeset: 7d3e0c5b5e25 Author: aghaisas Date: 2017-06-07 16:43 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/7d3e0c5b5e25 8180370: Characters are skipped on input of Korean text on OS X Reviewed-by: serb, prr Contributed-by: sreeprakash.s at oracle.com ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m + test/javax/swing/JTextField/MissingCharsKorean/MissingCharsKorean.java Changeset: e582ee8842d6 Author: aghaisas Date: 2017-06-13 14:32 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/e582ee8842d6 6267105: UIDefaults.getUIError dumps error message to System.err and also throws Error. Reviewed-by: prr, ssadetsky Contributed-by: shashidhara.veerabhadraiah at oracle.com ! src/java.desktop/share/classes/javax/swing/UIDefaults.java Changeset: 905ba4e83b0c Author: aghaisas Date: 2017-06-15 17:13 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/905ba4e83b0c 8181782: [TESTBUG] [Macosx] JTextAreaEmojiTest is not executed Reviewed-by: psadhukhan, aniyogi Contributed-by: sreeprakash.s at oracle.com ! test/javax/swing/JTextArea/8148555/JTextAreaEmojiTest.java Changeset: 17d2d44e306c Author: psadhukhan Date: 2017-06-16 11:07 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/17d2d44e306c 8182031: Swing's ComboBox Popup opens and closes immediately Reviewed-by: azvegint ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboPopup.java + test/javax/swing/JComboBox/8182031/ComboPopupTest.java Changeset: 0ec14d6528ef Author: psadhukhan Date: 2017-06-18 19:52 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/0ec14d6528ef 8177699: Some swing and awt tests are not in TEST.groups Reviewed-by: serb ! test/TEST.groups + test/com/apple/laf/TEST.properties + test/sun/applet/TEST.properties Changeset: fd9a519897e5 Author: psadhukhan Date: 2017-06-21 10:30 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/fd9a519897e5 8075918: The regression-swing case failed as the long Tab titles are not clipped with dots at the end with NimbusLookAndFeel Reviewed-by: serb, aniyogi ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthGraphicsUtils.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! test/javax/swing/JTabbedPane/4310381/bug4310381.java Changeset: 4cdd5d954479 Author: psadhukhan Date: 2017-06-22 19:28 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/4cdd5d954479 8043315: Nimbus: Setting Nimbus.Overrides property affects custom keymap installation Reviewed-by: serb, azvegint ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java + test/javax/swing/plaf/nimbus/TestNimbusOverride.java Changeset: a00c069b6a3b Author: prr Date: 2017-06-23 09:48 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/a00c069b6a3b Merge - src/java.base/share/classes/overview-core.html - src/java.base/share/specs/serialization/class.md - src/java.base/share/specs/serialization/examples.md - src/java.base/share/specs/serialization/exceptions.md - src/java.base/share/specs/serialization/images/version.gif - src/java.base/share/specs/serialization/index.md - src/java.base/share/specs/serialization/input.md - src/java.base/share/specs/serialization/output.md - src/java.base/share/specs/serialization/protocol.md - src/java.base/share/specs/serialization/security.md - src/java.base/share/specs/serialization/serial-arch.md - src/java.base/share/specs/serialization/version.md ! src/java.desktop/share/classes/module-info.java - src/java.desktop/share/specs/AWT_Native_Interface.html - src/java.management/share/specs/JVM-MANAGEMENT-MIB.mib ! test/TEST.groups - test/java/io/File/MacPathTest.sh - test/java/io/File/basic.sh - test/java/io/FileOutputStream/FileOpen.sh - test/java/io/FileOutputStream/FileOpenNeg.java - test/java/io/FileOutputStream/FileOpenPos.java - test/java/io/Serializable/class/NonSerialA_1.java - test/java/io/Serializable/class/NonSerialA_2.java - test/java/io/Serializable/class/SerialA.java - test/java/io/Serializable/class/SerialA_1.java - test/java/io/Serializable/class/SerialA_2.java - test/java/io/Serializable/class/SerialA_3.java - test/java/io/Serializable/class/Test.java - test/java/io/Serializable/class/run.sh - test/java/nio/channels/Selector/lots_of_updates.sh - test/java/nio/channels/SocketChannel/Open.sh - test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh - test/java/nio/channels/spi/SelectorProvider/inheritedChannel/run_tests.sh - test/java/nio/charset/Charset/default.sh - test/java/nio/charset/coders/CheckSJISMappingProp.sh - test/java/nio/charset/spi/Test.java - test/java/nio/charset/spi/basic.sh - test/java/nio/file/Files/delete_on_close.sh - test/java/nio/file/Files/walkFileTree/PrintFileTree.java - test/java/nio/file/Files/walkFileTree/find.sh - test/java/nio/file/Path/MacPathTest.sh - test/java/util/Arrays/ParallelPrefix.java - test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/resources/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/resources/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/basic/src/mainbundles/jdk/test/resources/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/simple/src/bundles/jdk/test/resources/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/jdk/test/resources/exported/classes/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/classes/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/visibility/src/named.bundles/jdk/test/resources/props/MyResourcesProvider.java - test/java/util/ResourceBundle/modules/xmlformat/src/bundles/jdk/test/resources/MyResourcesProvider.java - test/lib/testlibrary/CompilerUtils.java - test/lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java - test/sun/net/InetAddress/nameservice/dns/cname.sh - test/sun/net/ftp/MarkResetTest.sh - test/sun/net/www/protocol/file/DirPermissionDenied.sh - test/sun/net/www/protocol/jar/B5105410.sh - test/sun/net/www/protocol/jar/copyin.sh - test/sun/net/www/protocol/jar/getcontenttype.sh - test/sun/net/www/protocol/jar/jarbug/run.sh - test/sun/net/www/protocol/jar/jarbug/src/test/RunAllTests.java - test/sun/net/www/protocol/jrt/other_resources.sh Changeset: f834f39cb870 Author: prr Date: 2017-06-29 13:07 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/f834f39cb870 Merge - make/src/classes/build/tools/docs/GenDocsBundlePage.java - make/src/classes/build/tools/docs/docs-bundle-page.html - make/src/classes/build/tools/docs/docs-module-groups.properties ! src/java.desktop/share/classes/javax/swing/JOptionPane.java ! src/java.desktop/share/classes/module-info.java - src/java.instrument/share/classes/java/lang/instrument/package.html - test/java/util/ServiceLoader/modules/BadProvidersTest.java - test/java/util/ServiceLoader/modules/Basic.java - test/java/util/ServiceLoader/modules/badfactories/badreturntype/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/classnotpublic/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/classnotpublic/Service.java - test/java/util/ServiceLoader/modules/badfactories/methodnotpublic/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/methodnotpublic/Service.java - test/java/util/ServiceLoader/modules/badfactories/returnsnull/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/returnsnull/Service.java - test/java/util/ServiceLoader/modules/badfactories/throwsexception/ProviderFactory.java - test/java/util/ServiceLoader/modules/badfactories/throwsexception/Service.java - test/java/util/ServiceLoader/modules/badproviders/ctornotpublic/Provider.java - test/java/util/ServiceLoader/modules/badproviders/ctornotpublic/Service.java - test/java/util/ServiceLoader/modules/badproviders/notasubtype/Provider.java - test/java/util/ServiceLoader/modules/badproviders/notpublic/Provider.java - test/java/util/ServiceLoader/modules/badproviders/notpublic/Service.java - test/java/util/ServiceLoader/modules/badproviders/throwsexception/Provider.java - test/java/util/ServiceLoader/modules/badproviders/throwsexception/Service.java - test/java/util/ServiceLoader/modules/modules/bananascript/module-info.java - test/java/util/ServiceLoader/modules/modules/bananascript/org/banana/BananaScript.java - test/java/util/ServiceLoader/modules/modules/bananascript/org/banana/BananaScriptEngineFactory.java - test/java/util/ServiceLoader/modules/modules/test1/module-info.java - test/java/util/ServiceLoader/modules/modules/test1/p/ProviderFactory.java - test/java/util/ServiceLoader/modules/modules/test1/p/Service.java - test/java/util/ServiceLoader/modules/modules/test2/module-info.java - test/java/util/ServiceLoader/modules/modules/test2/p/Provider.java - test/java/util/ServiceLoader/modules/modules/test2/p/Service.java - test/java/util/ServiceLoader/modules/src/pearscript/META-INF/services/javax.script.ScriptEngineFactory - test/java/util/ServiceLoader/modules/src/pearscript/org/pear/PearScript.java - test/java/util/ServiceLoader/modules/src/pearscript/org/pear/PearScriptEngineFactory.java - test/lib/testlibrary/jdk/testlibrary/Platform.java - test/tools/launcher/modules/permit/AttemptAccess.java - test/tools/launcher/modules/permit/PermitIllegalAccess.java Changeset: 08ec9924fcbf Author: psadhukhan Date: 2017-06-30 11:03 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/08ec9924fcbf 8182402: Tooltip for Desktop button is in English when non-English locale is set Reviewed-by: azvegint ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: 19098b855e42 Author: psadhukhan Date: 2017-07-01 09:56 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/19098b855e42 8075063: Context menu closes on mouse scroll Reviewed-by: ssadetsky ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java + test/javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java Changeset: e1e784e7fe35 Author: psadhukhan Date: 2017-07-01 10:00 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/e1e784e7fe35 8182577: Exception when Tab key moves focus to a JCheckbox with a custom ButtonModel Reviewed-by: ssadetsky, serb, kcr ! src/java.desktop/share/classes/javax/swing/ButtonModel.java ! src/java.desktop/share/classes/javax/swing/JToggleButton.java ! src/java.desktop/share/classes/javax/swing/LayoutFocusTraversalPolicy.java + test/javax/swing/DefaultButtonModel/DefaultButtonModelCrashTest.java Changeset: e11953665ba7 Author: psadhukhan Date: 2017-07-04 13:37 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/e11953665ba7 7190539: Nimbus LaF: JPopupMenu reacts on Ctrl+Enter Reviewed-by: ssadetsky, azvegint ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java + test/javax/swing/JPopupMenu/4870644/bug4870644.java Changeset: 1b869adc86f2 Author: mbaesken Date: 2017-06-30 16:32 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/1b869adc86f2 8183286: Some java/awt and javax/swing tests miss headful jtreg keyword Reviewed-by: serb, clanger ! test/java/awt/Choice/ChoicePopupLocation/ChoicePopupLocation.java ! test/java/awt/Dialog/DialogAboveFrame/DialogAboveFrameTest.java ! test/java/awt/Frame/ObscuredFrame/ObscuredFrameTest.java ! test/java/awt/PopupMenu/PopupMenuLocation.java ! test/java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java ! test/java/awt/Robot/MultiScreenRobotPosition/MultiScreenRobotPosition.java ! test/java/awt/Window/WindowDeadlockTest/WindowDeadlockTest.java ! test/java/awt/font/TextLayout/ArabicDiacriticTest.java ! test/javax/accessibility/JList/AccessibleJListChildNPETest.java ! test/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java ! test/javax/swing/JFrame/AlwaysOnTop/AlwaysOnTopImeTest.java ! test/javax/swing/JLightweightFrame/JLightweightFrameRoundTest.java ! test/javax/swing/JRadioButton/ButtonGroupFocus/ButtonGroupFocusTest.java ! test/javax/swing/JTree/4633594/JTreeFocusTest.java ! test/javax/swing/plaf/basic/BasicComboPopup/JComboBoxPopupLocation/JComboBoxPopupLocation.java ! test/javax/swing/text/html/StyleSheet/bug4936917.java Changeset: ef390b05c25d Author: aghaisas Date: 2017-07-06 16:45 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/ef390b05c25d 8165213: [TESTBUG] [PIT] consistent failure of a new regtest for 8163193 Reviewed-by: psadhukhan, serb Contributed-by: shashidhara.veerabhadraiah at oracle.com ! test/javax/swing/plaf/metal/MetalGradient/8163193/ButtonGradientTest.java Changeset: 509e7250736b Author: prr Date: 2017-07-06 09:22 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/509e7250736b Merge Changeset: 5fcac4064fdd Author: serb Date: 2017-07-06 15:54 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/5fcac4064fdd 8178403: DirectAudio in JavaSound may hang and leak Reviewed-by: prr, alitvinov ! src/java.desktop/share/classes/com/sun/media/sound/DirectAudioDevice.java ! test/ProblemList.txt ! test/javax/sound/sampled/Clip/ClipCloseLoss.java Changeset: 87cfff8aeacb Author: aghaisas Date: 2017-07-10 14:55 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/87cfff8aeacb 6919529: NPE from MultiUIDefaults.getUIError Reviewed-by: aghaisas, psadhukhan, serb Contributed-by: shashidhara.veerabhadraiah at oracle.com ! src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java + test/javax/swing/MultiUIDefaults/NPECheck/MultiUIDefaultsNPECheck.java Changeset: 2e4cdfc780cd Author: serb Date: 2017-07-10 14:41 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/2e4cdfc780cd 8183576: Synchronization in BufferedImage.setRGB(int x, int y, int rgb) is not necessary Reviewed-by: prr, flar, pnarayanan ! src/java.desktop/share/classes/java/awt/image/BufferedImage.java Changeset: 72c480992841 Author: psadhukhan Date: 2017-07-13 12:14 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/72c480992841 8184016: Text in native popup is not always updated with Sogou IME Reviewed-by: ssadetsky ! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp Changeset: 62976d44cbc7 Author: psadhukhan Date: 2017-07-14 10:30 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/62976d44cbc7 8183529: FilleChooser in "Detail view" does not change the Language of the column headings Reviewed-by: ssadetsky ! src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp Changeset: 2d8f013734a2 Author: psadhukhan Date: 2017-07-15 11:15 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/2d8f013734a2 8184244: UIDefaults.addResourceBundle uses system class loader Reviewed-by: serb, ssadetsky ! src/java.desktop/share/classes/javax/swing/UIDefaults.java Changeset: 93b7bd25273e Author: jdv Date: 2017-07-17 14:18 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/93b7bd25273e 8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java Reviewed-by: serb, pnarayanan ! test/javax/imageio/plugins/shared/CanWriteSequence.java ! test/javax/imageio/plugins/shared/WriteAfterAbort.java Changeset: da56caf26b5c Author: prr Date: 2017-07-17 09:14 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/da56caf26b5c Merge ! test/ProblemList.txt - test/java/lang/System/MacEncoding/MacJNUEncoding.sh Changeset: f2a6d80dd60e Author: prr Date: 2017-07-20 09:38 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/f2a6d80dd60e Merge Changeset: 134501ad7b2a Author: psadhukhan Date: 2017-07-21 10:23 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/134501ad7b2a 8184813: Class javax/swing/plaf/metal/MetalFontDesktopProperty is broken in JDK10 Reviewed-by: prr, serb ! src/java.desktop/share/classes/module-info.java - src/java.desktop/windows/classes/module-info.java.extra ! test/com/sun/java/swing/plaf/windows/Test6824600.java ! test/javax/swing/JButton/4796987/bug4796987.java ! test/javax/swing/JComboBox/4199622/bug4199622.java ! test/javax/swing/JComboBox/8015300/Test8015300.java ! test/javax/swing/JFileChooser/8046391/bug8046391.java ! test/javax/swing/JInternalFrame/6725409/bug6725409.java ! test/javax/swing/JSlider/6524424/bug6524424.java ! test/javax/swing/JTree/8004298/bug8004298.java ! test/javax/swing/border/Test4856008.java ! test/javax/swing/border/Test6978482.java Changeset: e282991b6970 Author: serb Date: 2017-07-21 16:27 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/e282991b6970 8134256: copy/paste duplicated tests in some condition statements Reviewed-by: azvegint ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java ! src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java + test/javax/swing/plaf/nimbus/AbstractRegionPainter/PaintContextScaleValidation.java + test/javax/swing/text/html/StyleSheet/BackgroundImage/BackgroundImagePosition.java Changeset: b0d7bf900075 Author: aghaisas Date: 2017-07-24 11:54 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/b0d7bf900075 8183341: Better cleanup for javax/imageio/AllowSearch.java Reviewed-by: prr, jdv, pnarayanan Contributed-by: shashidhara.veerabhadraiah at oracle.com ! test/javax/imageio/AllowSearch.java Changeset: 971e17807496 Author: prr Date: 2017-07-25 14:07 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/971e17807496 Merge Changeset: 0ef02247a818 Author: psadhukhan Date: 2017-07-26 10:47 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/0ef02247a818 8173739: JPopupMenu does not disappear on KeyEvent Reviewed-by: serb ! src/java.desktop/share/classes/javax/swing/JInternalFrame.java + test/javax/swing/JPopupMenu/8173739/TestPopupMenu.java Changeset: 1a2ad984d501 Author: prr Date: 2017-07-27 12:36 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/1a2ad984d501 Merge - src/java.base/share/classes/sun/net/www/protocol/https/DefaultHostnameVerifier.java - src/java.base/share/classes/sun/util/locale/LocaleEquivalentMaps.java - test/java/lang/ClassLoader/deadlock/Alice.java - test/java/lang/ClassLoader/deadlock/Bob.java - test/java/lang/ClassLoader/deadlock/Starter.java - test/java/lang/ClassLoader/deadlock/SupAlice.java - test/java/lang/ClassLoader/deadlock/SupBob.java - test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh - test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh - test/java/util/Locale/tools/EquivMapsGenerator.java - test/java/util/Locale/tools/language-subtag-registry.txt Changeset: 88de64439af6 Author: psadhukhan Date: 2017-07-28 10:26 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/88de64439af6 7190581: Nimbus: PgDn at the bottom causes scrolling Reviewed-by: ssadetsky ! src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java ! test/javax/swing/JTextArea/4697612/bug4697612.java Changeset: d4e5f053e75b Author: serb Date: 2017-07-28 14:39 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/d4e5f053e75b 8139050: -[AWTView draggingEnded:]: unrecognized selector message during drag and drop Reviewed-by: azvegint ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m ! test/java/awt/dnd/MissingEventsOnModalDialog/MissingEventsOnModalDialogTest.java + test/javax/swing/dnd/8139050/NativeErrorsInTableDnD.java Changeset: 59b6ea076972 Author: pkbalakr Date: 2017-08-02 11:26 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/59b6ea076972 8027154: [TESTBUG] Test java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails Reviewed-by: serb, arapte Contributed-by: krishna.addepalli at oracle.com ! test/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java Changeset: c2e469517e00 Author: aghaisas Date: 2017-08-03 14:55 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/c2e469517e00 8058785: Nimbus disabled tooltip needs border Reviewed-by: serb, pkbalakr Contributed-by: shashidhara.veerabhadraiah at oracle.com ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf + test/javax/swing/plaf/nimbus/TestDisabledToolTipBorder.java Changeset: 705766d47a97 Author: serb Date: 2017-08-04 18:39 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/705766d47a97 8185093: Expensive multi-core choke point when any graphics objects are created Reviewed-by: prr, flar ! src/java.desktop/share/classes/java/awt/GraphicsEnvironment.java Changeset: 4b0d12ba70b8 Author: aghaisas Date: 2017-08-07 10:02 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/4b0d12ba70b8 8178106: There is no error message pop up when clicking 'create folder' button Reviewed-by: serb, psadhukhan Contributed-by: shashidhara.veerabhadraiah at oracle.com ! test/javax/swing/JFileChooser/8067660/FileChooserTest.java Changeset: 7975190ee1b6 Author: prr Date: 2017-08-07 09:45 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/7975190ee1b6 Merge - src/java.base/share/classes/jdk/internal/module/SystemModuleFinder.java - test/java/lang/ClassLoader/getResource/GetResource.sh - test/tools/launcher/modules/patch/systemmodules/src1/java.base/jdk/internal/modules/SystemModules.java Changeset: 8c41faaf67ba Author: dmarkov Date: 2017-08-08 14:07 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/8c41faaf67ba 8177414: Missing key events on Mac Os Reviewed-by: serb, prr ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m + test/java/awt/InputMethods/InputMethodKeyEventsTest/InputMethodKeyEventsTest.java Changeset: d5b73eedc4a7 Author: azvegint Date: 2017-08-10 10:41 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/d5b73eedc4a7 8178448: MenuBar item handler fired twice Reviewed-by: serb ! src/java.desktop/share/classes/java/awt/Desktop.java ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 9dbe51fc9d6f Author: psadhukhan Date: 2017-08-10 10:46 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/9dbe51fc9d6f 8185890: Intermittent NPE in JLightweightFrame when updating cursor aceoss multiple graphics devices Reviewed-by: azvegint ! src/java.desktop/share/classes/sun/swing/JLightweightFrame.java Changeset: 77a5ad135a29 Author: serb Date: 2017-08-10 15:17 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/77a5ad135a29 8153871: [macosx] Low-level error on OS X 10.11 with DnD in Swing Reviewed-by: azvegint ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSource.m ! test/javax/swing/dnd/8139050/NativeErrorsInTableDnD.java Changeset: fd986bf973c6 Author: mhalder Date: 2017-08-11 18:17 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/fd986bf973c6 8136999: [macosx] NSException and NPE in a crash test Reviewed-by: serb Contributed-by: manajit.halder at oracle.com ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTarget.m + test/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java Changeset: aad7d9872662 Author: prr Date: 2017-08-14 10:47 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/aad7d9872662 Merge ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: 0d9457fb89b2 Author: prr Date: 2017-08-16 11:31 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/0d9457fb89b2 Merge Changeset: 53edc766d217 Author: serb Date: 2017-08-17 13:51 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/53edc766d217 8185683: Inaccessible and unused classes can be removed from java.desktop module Reviewed-by: prr, kcr - src/java.desktop/macosx/classes/apple/laf/AquaLookAndFeel.java - src/java.desktop/macosx/classes/com/apple/eawt/ApplicationAdapter.java - src/java.desktop/macosx/classes/com/apple/eawt/ApplicationEvent.java - src/java.desktop/macosx/classes/com/apple/eawt/ApplicationListener.java - src/java.desktop/share/classes/com/sun/java/swing/Painter.java - src/java.desktop/share/classes/com/sun/java/swing/plaf/nimbus/AbstractRegionPainter.java - src/java.desktop/share/classes/com/sun/java/swing/plaf/nimbus/NimbusLookAndFeel.java ! test/javax/swing/JTable/6937798/bug6937798.java ! test/javax/swing/plaf/nimbus/Test6741426.java Changeset: c32965c8e99b Author: dbatrak Date: 2017-08-17 19:24 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/c32965c8e99b 8174744: [macos] Wrong rendering of string containing surrogate pairs Reviewed-by: prr, serb ! src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java + test/java/awt/FontClass/SurrogateTest/SuppCharDrawTest.java Changeset: 6e85acfe02c5 Author: lbourges Date: 2017-08-18 10:12 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/6e85acfe02c5 8186364: RFE: API for java.awt.geom.Path2D storage trimming Reviewed-by: prr, flar ! src/java.desktop/share/classes/java/awt/geom/Path2D.java ! test/java/awt/geom/Path2D/Path2DCopyConstructor.java Changeset: 7fef0f800d52 Author: prr Date: 2017-08-18 11:25 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/7fef0f800d52 Merge ! test/ProblemList.txt Changeset: ade058e0f067 Author: serb Date: 2017-08-18 14:03 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/ade058e0f067 8186263: The SunDropTargetEvent sometimes is not dispatched Reviewed-by: prr ! src/java.desktop/share/classes/java/awt/EventQueue.java ! src/java.desktop/share/classes/sun/awt/dnd/SunDropTargetEvent.java ! test/java/awt/dnd/RemoveDropTargetCrashTest/RemoveDropTargetCrashTest.java Changeset: 2d4405f3f8f8 Author: serb Date: 2017-08-22 09:41 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/2d4405f3f8f8 8186474: WColor class is superseded by the SystemColor and should be removed Reviewed-by: azvegint - src/java.desktop/windows/classes/sun/awt/windows/WColor.java ! src/java.desktop/windows/classes/sun/awt/windows/WPanelPeer.java ! src/java.desktop/windows/native/libawt/windows/awt_Color.cpp ! src/java.desktop/windows/native/libawt/windows/awt_Color.h Changeset: ac927d179ff9 Author: prr Date: 2017-08-23 09:28 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/ac927d179ff9 8184135: Remove obsolete dga code and binaries from Solaris SPARC build. Reviewed-by: serb, psadhukhan, pnarayanan ! make/lib/Awt2dLibraries.gmk ! make/mapfiles/libawt/mapfile-mawt-vers ! make/mapfiles/libawt/mapfile-vers-linux ! make/mapfiles/libawt_xawt/mapfile-vers ! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java ! src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java ! src/java.desktop/unix/native/common/java2d/x11/X11SurfaceData.c ! src/java.desktop/unix/native/common/java2d/x11/X11SurfaceData.h - src/java.desktop/unix/native/libsunwjdga/dgalock.c - src/java.desktop/unix/native/libsunwjdga/jdga.h - src/java.desktop/unix/native/libsunwjdga/jdgadevice.h ! test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.sh Changeset: 737070667c78 Author: prr Date: 2017-08-23 12:05 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/737070667c78 Merge - src/java.base/share/classes/java/lang/doc-files/capchi.gif - src/java.base/share/classes/java/lang/doc-files/capiota.gif - src/java.base/share/classes/java/lang/doc-files/capsigma.gif - src/java.base/share/classes/java/lang/doc-files/captheta.gif - src/java.base/share/classes/java/lang/doc-files/capupsil.gif - src/java.base/share/classes/java/lang/doc-files/chi.gif - src/java.base/share/classes/java/lang/doc-files/iota.gif - src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc21.gif - src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc38.gif - src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc40.gif - src/java.base/share/classes/java/lang/doc-files/javalang.doc.anc41.gif - src/java.base/share/classes/java/lang/doc-files/sigma1.gif - src/java.base/share/classes/java/lang/doc-files/theta.gif - src/java.base/share/classes/java/lang/doc-files/upsilon.gif - src/jdk.security.auth/share/classes/com/sun/security/auth/PolicyFile.java - src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericGroupPrincipal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisNumericUserPrincipal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/SolarisPrincipal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/X500Principal.java - src/jdk.security.auth/share/classes/com/sun/security/auth/module/SolarisLoginModule.java - src/jdk.security.auth/share/classes/com/sun/security/auth/module/SolarisSystem.java - src/jdk.security.auth/solaris/native/libjaas/Solaris.c - test/java/security/Provider/TestSecurityProvider.java - test/java/security/Provider/TestSecurityProviderClient.java - test/java/security/modules/ModularTest.java - test/javax/security/auth/login/modules/TEST.properties Changeset: f68026915934 Author: serb Date: 2017-08-24 11:30 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/f68026915934 8186261: 4 JNI primitive type mismatch defect groups in XlibWrapper.c Reviewed-by: azvegint ! src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c Changeset: 66539c09c053 Author: prr Date: 2017-08-28 11:53 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/66539c09c053 8186317: Cache font layout tables for use by harfbuzz Reviewed-by: srl, pnarayanan ! src/java.desktop/share/classes/sun/font/SunLayoutEngine.java ! src/java.desktop/share/native/common/font/fontscalerdefs.h ! src/java.desktop/share/native/libfontmanager/HBShaper.c ! src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc ! src/java.desktop/share/native/libfontmanager/hb-jdk.h ! src/java.desktop/share/native/libfontmanager/sunFont.c Changeset: 77d046dced5d Author: prr Date: 2017-08-29 10:47 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/77d046dced5d Merge - test/lib/testlibrary/ClassFileInstaller.java Changeset: 9bae8d7e5b8a Author: pkbalakr Date: 2017-08-30 16:56 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/9bae8d7e5b8a 8175015: FileSystemView.isDrive(File) memory leak on "C:\" file reference Reviewed-by: serb, psadhukhan Contributed-by: krishna.addepalli at oracle.com ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java + test/sun/awt/shell/FileSystemViewMemoryLeak.java Changeset: 892a8e0b5834 Author: serb Date: 2017-08-01 14:18 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/892a8e0b5834 8177951: Charset problem when the name of the sound device contains Chinese character Reviewed-by: amenkov, serb Contributed-by: Charlie Jiang ! make/lib/SoundLibraries.gmk + src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_Charset_Util.cpp + src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_Charset_Util.h ! src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_DirectSound.cpp ! src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_MidiIn.cpp ! src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_MidiOut.c ! src/java.desktop/windows/native/libjsound/PLATFORM_API_WinOS_Ports.c Changeset: dbb5b171a16b Author: azvegint Date: 2017-08-31 09:28 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/dbb5b171a16b 8181786: Extra runLater causes impossible states to be possible using javafx.embed.singleThread=true Reviewed-by: kcr ! src/java.desktop/share/classes/java/awt/EventDispatchThread.java ! src/java.desktop/share/classes/java/awt/EventQueue.java Changeset: cd9b04ac647e Author: prr Date: 2017-08-31 10:51 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/cd9b04ac647e Merge - make/data/charsetmapping/euc_tw.map ! src/java.desktop/share/classes/java/awt/EventQueue.java Changeset: cb4fd968fb83 Author: prr Date: 2017-08-31 13:09 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/cb4fd968fb83 8183351: Better cleanup for jdk/test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh Reviewed-by: serb ! test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh Changeset: c6f9f9e5f186 Author: serb Date: 2017-08-31 13:00 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/c6f9f9e5f186 8181566: JavaSound javadoc clarification Reviewed-by: amenkov ! src/java.desktop/share/classes/javax/sound/midi/InvalidMidiDataException.java ! src/java.desktop/share/classes/javax/sound/midi/MetaMessage.java ! src/java.desktop/share/classes/javax/sound/midi/MidiDevice.java ! src/java.desktop/share/classes/javax/sound/midi/MidiDeviceReceiver.java ! src/java.desktop/share/classes/javax/sound/midi/MidiDeviceTransmitter.java ! src/java.desktop/share/classes/javax/sound/midi/MidiFileFormat.java ! src/java.desktop/share/classes/javax/sound/midi/MidiMessage.java ! src/java.desktop/share/classes/javax/sound/midi/MidiSystem.java ! src/java.desktop/share/classes/javax/sound/midi/MidiUnavailableException.java ! src/java.desktop/share/classes/javax/sound/midi/Receiver.java ! src/java.desktop/share/classes/javax/sound/midi/Sequencer.java ! src/java.desktop/share/classes/javax/sound/midi/ShortMessage.java ! src/java.desktop/share/classes/javax/sound/midi/SoundbankResource.java ! src/java.desktop/share/classes/javax/sound/midi/Synthesizer.java ! src/java.desktop/share/classes/javax/sound/midi/SysexMessage.java ! src/java.desktop/share/classes/javax/sound/midi/Track.java ! src/java.desktop/share/classes/javax/sound/midi/Transmitter.java ! src/java.desktop/share/classes/javax/sound/midi/VoiceStatus.java ! src/java.desktop/share/classes/javax/sound/midi/package-info.java ! src/java.desktop/share/classes/javax/sound/midi/spi/MidiFileReader.java ! src/java.desktop/share/classes/javax/sound/midi/spi/MidiFileWriter.java ! src/java.desktop/share/classes/javax/sound/midi/spi/SoundbankReader.java ! src/java.desktop/share/classes/javax/sound/midi/spi/package-info.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioFileFormat.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioFormat.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioInputStream.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioPermission.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioSystem.java ! src/java.desktop/share/classes/javax/sound/sampled/BooleanControl.java ! src/java.desktop/share/classes/javax/sound/sampled/Clip.java ! src/java.desktop/share/classes/javax/sound/sampled/CompoundControl.java ! src/java.desktop/share/classes/javax/sound/sampled/Control.java ! src/java.desktop/share/classes/javax/sound/sampled/DataLine.java ! src/java.desktop/share/classes/javax/sound/sampled/Line.java ! src/java.desktop/share/classes/javax/sound/sampled/LineEvent.java ! src/java.desktop/share/classes/javax/sound/sampled/LineUnavailableException.java ! src/java.desktop/share/classes/javax/sound/sampled/Mixer.java ! src/java.desktop/share/classes/javax/sound/sampled/Port.java ! src/java.desktop/share/classes/javax/sound/sampled/ReverbType.java ! src/java.desktop/share/classes/javax/sound/sampled/SourceDataLine.java ! src/java.desktop/share/classes/javax/sound/sampled/UnsupportedAudioFileException.java ! src/java.desktop/share/classes/javax/sound/sampled/package-info.java ! src/java.desktop/share/classes/javax/sound/sampled/spi/AudioFileReader.java ! src/java.desktop/share/classes/javax/sound/sampled/spi/AudioFileWriter.java ! src/java.desktop/share/classes/javax/sound/sampled/spi/package-info.java Changeset: ad37f4ce2062 Author: serb Date: 2017-08-31 15:47 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/ad37f4ce2062 8184435: Cleanup of javadoc in javax.print package Reviewed-by: prr, psadhukhan ! src/java.desktop/share/classes/javax/print/AttributeException.java ! src/java.desktop/share/classes/javax/print/CancelablePrintJob.java ! src/java.desktop/share/classes/javax/print/Doc.java ! src/java.desktop/share/classes/javax/print/DocFlavor.java ! src/java.desktop/share/classes/javax/print/DocPrintJob.java ! src/java.desktop/share/classes/javax/print/FlavorException.java ! src/java.desktop/share/classes/javax/print/MimeType.java ! src/java.desktop/share/classes/javax/print/MultiDoc.java ! src/java.desktop/share/classes/javax/print/MultiDocPrintJob.java ! src/java.desktop/share/classes/javax/print/MultiDocPrintService.java ! src/java.desktop/share/classes/javax/print/PrintException.java ! src/java.desktop/share/classes/javax/print/PrintService.java ! src/java.desktop/share/classes/javax/print/PrintServiceLookup.java ! src/java.desktop/share/classes/javax/print/ServiceUI.java ! src/java.desktop/share/classes/javax/print/ServiceUIFactory.java ! src/java.desktop/share/classes/javax/print/SimpleDoc.java ! src/java.desktop/share/classes/javax/print/StreamPrintService.java ! src/java.desktop/share/classes/javax/print/StreamPrintServiceFactory.java ! src/java.desktop/share/classes/javax/print/URIException.java ! src/java.desktop/share/classes/javax/print/attribute/Attribute.java ! src/java.desktop/share/classes/javax/print/attribute/AttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/AttributeSetUtilities.java ! src/java.desktop/share/classes/javax/print/attribute/DateTimeSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/DocAttribute.java ! src/java.desktop/share/classes/javax/print/attribute/DocAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/EnumSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/HashAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashDocAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashPrintJobAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashPrintRequestAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/HashPrintServiceAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/IntegerSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/PrintJobAttribute.java ! src/java.desktop/share/classes/javax/print/attribute/PrintJobAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/PrintRequestAttribute.java ! src/java.desktop/share/classes/javax/print/attribute/PrintRequestAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/PrintServiceAttribute.java ! src/java.desktop/share/classes/javax/print/attribute/PrintServiceAttributeSet.java ! src/java.desktop/share/classes/javax/print/attribute/ResolutionSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/SetOfIntegerSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/Size2DSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/SupportedValuesAttribute.java ! src/java.desktop/share/classes/javax/print/attribute/TextSyntax.java ! src/java.desktop/share/classes/javax/print/attribute/URISyntax.java ! src/java.desktop/share/classes/javax/print/attribute/UnmodifiableSetException.java ! src/java.desktop/share/classes/javax/print/attribute/package-info.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Chromaticity.java ! src/java.desktop/share/classes/javax/print/attribute/standard/ColorSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Compression.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Copies.java ! src/java.desktop/share/classes/javax/print/attribute/standard/CopiesSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtCompleted.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtCreation.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtProcessing.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Destination.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DialogTypeSelection.java ! src/java.desktop/share/classes/javax/print/attribute/standard/DocumentName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Fidelity.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Finishings.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobHoldUntil.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressions.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressionsCompleted.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressionsSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctets.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctetsProcessed.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctetsSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheets.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheetsCompleted.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheetsSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobMessageFromOperator.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobOriginatingUserName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobPriority.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobPrioritySupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobSheets.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobState.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobStateReason.java ! src/java.desktop/share/classes/javax/print/attribute/standard/JobStateReasons.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Media.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaPrintableArea.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaSize.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaSizeName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MediaTray.java ! src/java.desktop/share/classes/javax/print/attribute/standard/MultipleDocumentHandling.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberOfDocuments.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberOfInterveningJobs.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberUp.java ! src/java.desktop/share/classes/javax/print/attribute/standard/NumberUpSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/OrientationRequested.java ! src/java.desktop/share/classes/javax/print/attribute/standard/OutputDeviceAssigned.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PDLOverrideSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PageRanges.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PagesPerMinute.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PagesPerMinuteColor.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PresentationDirection.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrintQuality.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterInfo.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterLocation.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMakeAndModel.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMessageFromOperator.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMoreInfo.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterResolution.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterState.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReason.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterURI.java ! src/java.desktop/share/classes/javax/print/attribute/standard/QueuedJobCount.java ! src/java.desktop/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java ! src/java.desktop/share/classes/javax/print/attribute/standard/RequestingUserName.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Severity.java ! src/java.desktop/share/classes/javax/print/attribute/standard/SheetCollate.java ! src/java.desktop/share/classes/javax/print/attribute/standard/Sides.java ! src/java.desktop/share/classes/javax/print/attribute/standard/package-info.java ! src/java.desktop/share/classes/javax/print/event/PrintEvent.java ! src/java.desktop/share/classes/javax/print/event/PrintJobAdapter.java ! src/java.desktop/share/classes/javax/print/event/PrintJobAttributeEvent.java ! src/java.desktop/share/classes/javax/print/event/PrintJobAttributeListener.java ! src/java.desktop/share/classes/javax/print/event/PrintJobEvent.java ! src/java.desktop/share/classes/javax/print/event/PrintJobListener.java ! src/java.desktop/share/classes/javax/print/event/PrintServiceAttributeEvent.java ! src/java.desktop/share/classes/javax/print/event/PrintServiceAttributeListener.java ! src/java.desktop/share/classes/javax/print/event/package-info.java ! src/java.desktop/share/classes/javax/print/package-info.java Changeset: 6581f08c67b6 Author: pnarayanan Date: 2017-09-01 12:32 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/6581f08c67b6 8164971: PNG metadata does not handle ImageCreationTime Reviewed-by: prr, bpb, jdv Contributed-by: prahalad.kumar.narayanan at oracle.com ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageReader.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java + test/javax/imageio/plugins/png/PngCreationTimeTest.java Changeset: 70359afda5d0 Author: pnarayanan Date: 2017-09-03 19:31 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/70359afda5d0 8187113: test/javax/imageio/plugins/png/PngCreationTimeTest.java fails Reviewed-by: serb, psadhukhan Contributed-by: prahalad.kumar.narayanan at oracle.com ! test/javax/imageio/plugins/png/PngCreationTimeTest.java + test/javax/imageio/plugins/png/duke.png Changeset: f3f6f6410d2d Author: prr Date: 2017-09-05 10:09 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/f3f6f6410d2d Merge - src/java.rmi/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java - src/java.rmi/share/classes/sun/rmi/transport/tcp/MultiplexConnectionInfo.java - src/java.rmi/share/classes/sun/rmi/transport/tcp/MultiplexInputStream.java - src/java.rmi/share/classes/sun/rmi/transport/tcp/MultiplexOutputStream.java Changeset: 777356696811 Author: lana Date: 2017-09-08 18:24 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/jdk/rev/777356696811 Added tag jdk-10+23 for changeset f3f6f6410d2d ! .hgtags From cflood at redhat.com Wed Sep 13 22:23:47 2017 From: cflood at redhat.com (Christine Flood) Date: Wed, 13 Sep 2017 18:23:47 -0400 Subject: Updated fix for jdk10 Generational Partial Heuristics... In-Reply-To: References: <545284e4-1ff7-ada3-0daa-b0be2d58d679@redhat.com> Message-ID: http://cr.openjdk.java.net/~chf/GenerationalHeuristics/webrev.05/ On Tue, Sep 12, 2017 at 1:32 PM, Aleksey Shipilev wrote: > You are replying offlist. > > Okay. Then you should run initialize() on all heuristics, not only on > minor one. > > -Aleksey > > On 09/12/2017 07:29 PM, Christine Flood wrote: > > I like the num_regions solution but unfortunately the heap isn't > initialized yet so we don't have > > access to it. > > > > There is precedent for running initialize after creating the instance > (we do it for heap) and it's > > cleaner once we have all the data we need to get the right settings > rather than passing in > > parameters to constructors. > > > > Christine > > > > > > > > On Tue, Sep 12, 2017 at 12:54 PM, Aleksey Shipilev > wrote: > > > > On 09/12/2017 06:51 PM, Aleksey Shipilev wrote: > > > *) Seems to me that entire deal with initialize() method can be > gone if ShenandoahPartialHeuristics > > > constructor accepts the size_t parameter for from_idxs > initialization. You can seed it off the > > > static const: > > > > > > static const size_t DEFAULT_THRESHOLD = 100; > > > > > > ShenandoahGenerationalPartialHeuristics() : > ShenandoahPartialHeuristics(DEFAULT_THRESHOLD) { > > > if (FLAG_IS_DEFAULT(ShenandoahPartialInboundThreshold)) { > > > FLAG_SET_DEFAULT(ShenandoahPartialInboundThreshold, > DEFAULT_THRESHOLD); > > > } > > > } > > > > Or screw it, and just initialize from_idx with num_regions() size? > > > > -Aleksey > > > > > > > > > > > From shade at redhat.com Thu Sep 14 07:51:08 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Sep 2017 09:51:08 +0200 Subject: Updated fix for jdk10 Generational Partial Heuristics... In-Reply-To: References: <545284e4-1ff7-ada3-0daa-b0be2d58d679@redhat.com> Message-ID: On 09/14/2017 12:23 AM, Christine Flood wrote: > http://cr.openjdk.java.net/~chf/GenerationalHeuristics/webrev.05/ Looks good, except for missing braces here: 1567 if (_minor_heuristics != NULL) 1568 _minor_heuristics->initialize(); Fix that, and push. -Aleksey From ashipile at redhat.com Thu Sep 14 09:15:58 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 14 Sep 2017 09:15:58 +0000 Subject: hg: shenandoah/jdk8u/hotspot: 35 new changesets Message-ID: <201709140915.v8E9FxMM016000@aojmv0008.oracle.com> Changeset: 426a1f029177 Author: shade Date: 2017-09-08 18:30 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/426a1f029177 [backport] BrooksPointer tracing overwhelms -Xlog:gc=trace ! src/share/vm/gc_implementation/shenandoah/brooksPointer.hpp ! src/share/vm/gc_implementation/shenandoah/brooksPointer.inline.hpp Changeset: 769bb1e08b39 Author: shade Date: 2017-09-08 18:37 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/769bb1e08b39 [backport] Reclaimed humongous regions should count towards immediate garbage ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: 3e8e3968d375 Author: shade Date: 2017-09-08 18:49 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/3e8e3968d375 [backport] Allocation latency tracing ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/numberSeq.hpp Changeset: 49abf426abcf Author: shade Date: 2017-09-12 21:05 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/49abf426abcf [backport] Refactor region flags into finite state machine ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! test/gc/shenandoah/TestHeapAlloc.java Changeset: 4d917425a9c7 Author: shade Date: 2017-09-12 21:27 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/4d917425a9c7 [backport] Cleanup "dirty" mentions ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: d98601e596a7 Author: shade Date: 2017-09-12 21:40 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/d98601e596a7 [backport] Verifier should walk cset and humongous regions ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 776f9f5aea8c Author: shade Date: 2017-09-12 23:08 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/776f9f5aea8c [backport] Allow allocations in pinned regions ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp Changeset: 21e21f086c96 Author: shade Date: 2017-09-12 23:22 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/21e21f086c96 [backport] Refactor ShenandoahHeapLock ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahHeapLock.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 3203290ff33f Author: shade Date: 2017-09-12 23:31 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/3203290ff33f [backport] Templatize and improve inlining of arraycopy and clone barriers. ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp Changeset: 0ee27b44f20c Author: shade Date: 2017-09-13 09:54 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/0ee27b44f20c [backport] Refactor ShConcThread dispatch ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp Changeset: 31d1fb1c1321 Author: shade Date: 2017-09-13 10:35 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/31d1fb1c1321 [backport] Mark heuristics diagnostic/experimental ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! test/gc/shenandoah/EvilSyncBug.java ! test/gc/shenandoah/LotsOfCycles.java ! test/gc/shenandoah/MXNotificationsFullGC.java ! test/gc/shenandoah/ShenandoahJNICritical.sh ! test/gc/shenandoah/TestPeriodicGC.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/acceptance/AllocIntArrays.java ! test/gc/shenandoah/acceptance/AllocObjectArrays.java ! test/gc/shenandoah/acceptance/AllocObjects.java ! test/gc/shenandoah/acceptance/HeapUncommit.java ! test/gc/shenandoah/acceptance/RetainObjects.java ! test/gc/shenandoah/acceptance/StringInternCleanup.java ! test/gc/shenandoah/compiler/C1VectorizedMismatch.java ! test/gc/shenandoah/compiler/TestReferenceCAS.java + test/gc/shenandoah/options/TestHeuristicsUnlock.java ! test/gc/shenandoah/options/TestShenandoahArgumentRanges.java ! test/gc/shenandoah/options/TestSingleThreadedShenandoah.java Changeset: a78869114f5c Author: shade Date: 2017-09-13 11:01 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/a78869114f5c [backport] "continuous" heuristics ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! test/gc/shenandoah/LotsOfCycles.java ! test/gc/shenandoah/TestPeriodicGC.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/acceptance/AllocIntArrays.java ! test/gc/shenandoah/acceptance/AllocObjectArrays.java ! test/gc/shenandoah/acceptance/AllocObjects.java ! test/gc/shenandoah/acceptance/HeapUncommit.java ! test/gc/shenandoah/acceptance/RetainObjects.java ! test/gc/shenandoah/acceptance/StringInternCleanup.java ! test/gc/shenandoah/options/TestHeuristicsUnlock.java Changeset: 4e52439c04ac Author: shade Date: 2017-09-13 11:05 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/4e52439c04ac [backport] Verify humongous regions liveness ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 2726992a51b6 Author: shade Date: 2017-09-13 11:21 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/2726992a51b6 [backport] Refactor ShenandoahHeapRegionSet ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: d921e6a42b82 Author: shade Date: 2017-09-13 12:49 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/d921e6a42b82 [backport] Cap heap size for TestRegionSizeArgs test ! test/gc/shenandoah/options/TestRegionSizeArgs.java Changeset: 06ee46e9d9c5 Author: shade Date: 2017-09-13 12:57 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/06ee46e9d9c5 [backport] On-demand commit as heap resizing strategy ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! test/gc/shenandoah/TestHeapAlloc.java ! test/gc/shenandoah/options/AlwaysPreTouch.java Changeset: 0325411ecc92 Author: shade Date: 2017-09-13 13:19 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/0325411ecc92 [backport] Assorted monitoring support fixes ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! test/TEST.groups ! test/gc/metaspace/TestMetaspacePerfCounters.java Changeset: 863e5a4afd8e Author: shade Date: 2017-09-13 13:21 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/863e5a4afd8e [backport] Pinning humongous regions should be allowed ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp Changeset: a19ca1ccf660 Author: shade Date: 2017-09-13 20:45 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/a19ca1ccf660 [backport] Unlock more GC-specific tests for Shenandoah ! src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp ! test/TEST.groups ! test/gc/TestSystemGC.java ! test/gc/arguments/TestAlignmentToUseLargePages.java ! test/gc/arguments/TestUseCompressedOopsErgo.java ! test/gc/logging/TestGCId.java ! test/gc/shenandoah/ShenandoahJNICritical.sh + test/gc/startup_warnings/TestShenandoah.java Changeset: 06d6ca3cd399 Author: shade Date: 2017-09-13 21:09 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/06d6ca3cd399 [backport] Update counters on slow-path more rarely ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: ccfea3eabb60 Author: shade Date: 2017-09-13 21:17 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/ccfea3eabb60 [backport] Consistent print_on and tty handling ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp Changeset: 33bd3f6d9a87 Author: shade Date: 2017-09-13 21:25 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/33bd3f6d9a87 [backport] Region (byte|word) shifts as the replacement for divisions ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/opto/shenandoahSupport.cpp Changeset: 68b55443bb60 Author: shade Date: 2017-09-13 21:42 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/68b55443bb60 [backport] Add JVMTI notifications to Shenandoah GC pauses. ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp Changeset: a5a99e1f4466 Author: shade Date: 2017-09-13 22:00 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/a5a99e1f4466 [backport] Refactor ShenandoahFreeSet + Fast-forward over humongous regions to keep "current" non-humongous ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: a957b764d7c8 Author: shade Date: 2017-09-13 22:07 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/a957b764d7c8 [backport] Make sure we have at least one memory pool per memory manager (JMX) + JMX double-counts heap used size ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp ! src/share/vm/services/shenandoahMemoryPool.cpp ! src/share/vm/services/shenandoahMemoryPool.hpp + test/gc/shenandoah/TestMemoryMXBeans.java + test/gc/shenandoah/TestMemoryPools.java Changeset: 9b2ae3d67c01 Author: shade Date: 2017-09-13 22:07 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/9b2ae3d67c01 [backport] Disable biased locking by default ! src/share/vm/runtime/arguments.cpp Changeset: 056a90e9ae73 Author: shade Date: 2017-09-13 22:55 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/056a90e9ae73 [backport] Avoid Full STW GC on System.gc() + related fixes ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp + test/gc/shenandoah/options/TestExplicitGC.java + test/gc/shenandoah/options/TestExplicitGCNoConcurrent.java Changeset: 061730bc2522 Author: shade Date: 2017-09-14 10:44 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/061730bc2522 [backport] Selectable humongous threshold + Humongous top() should be correct for iteration ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp + test/gc/shenandoah/HumongousThreshold.java + test/gc/shenandoah/options/TestHumongousThresholdArgs.java Changeset: 77a140b367b1 Author: shade Date: 2017-09-14 10:46 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/77a140b367b1 [backport] Make sure different Verifier levels work ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp + test/gc/shenandoah/TestVerifyLevels.java Changeset: 5fc1d4931283 Author: shade Date: 2017-09-14 10:49 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/5fc1d4931283 [backport] LotsOfCycles test always degrades to Full GC ! test/gc/shenandoah/LotsOfCycles.java Changeset: 57add6045f73 Author: shade Date: 2017-09-14 10:50 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/57add6045f73 [backport] TestSmallHeap test for Shenandoah ! test/TEST.groups + test/gc/shenandoah/TestSmallHeap.java Changeset: 4841b273467d Author: shade Date: 2017-09-14 10:52 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/4841b273467d [backport] Fix build error: avoid loops with empty bodies ! src/share/vm/opto/shenandoahSupport.cpp Changeset: b09a89ab0606 Author: shade Date: 2017-09-14 10:57 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/b09a89ab0606 [backport] Fix build error: switches over enums should take all enums ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp Changeset: ab25892f7434 Author: shade Date: 2017-09-14 10:59 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/ab25892f7434 [backport] Fix build error: verifier liveness should not be implicitly casted to size_t ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp Changeset: 9b16dfefb385 Author: shade Date: 2017-09-14 11:12 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/9b16dfefb385 [backport] Common pause marker to capture everything before/after pause ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp From ashipile at redhat.com Thu Sep 14 09:44:57 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 14 Sep 2017 09:44:57 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Fix build error in release config. Message-ID: <201709140944.v8E9ivs9005089@aojmv0008.oracle.com> Changeset: fe583d4e28de Author: shade Date: 2017-09-14 11:42 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/fe583d4e28de Fix build error in release config. ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp From rkennke at redhat.com Thu Sep 14 13:20:03 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Sep 2017 15:20:03 +0200 Subject: RFR: Fix, improve and refactor matrix barrier on AAarch64 Message-ID: <663e9c13-6139-4781-43c0-cd20b259310c@redhat.com> This patch fixes an issue in the aarch64 interpreter matrix barrier that caused TestGCOldWithShenandoah to fail verification. The reason was that we invoke the storeval-(read-)barrier *after* we copied the newval, and then pass the original to the matrix barrier, thus connecting the wrong regions. The patch does: - Move the storeval barrier before copying the newval - Add a tmp3 arg to the shenandoah_write_barrier_post() to make it consistent (we've been using 2 tmp regs passed via function call, and 1 implicit) - Implement the fast matrix math as a bonus Test: hotspot_gc_shenandoah http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.00/ Ok? From shade at redhat.com Thu Sep 14 13:52:07 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Sep 2017 15:52:07 +0200 Subject: RFR: Fix, improve and refactor matrix barrier on AAarch64 In-Reply-To: <663e9c13-6139-4781-43c0-cd20b259310c@redhat.com> References: <663e9c13-6139-4781-43c0-cd20b259310c@redhat.com> Message-ID: <9523f308-a01f-bb3b-0182-fc15e706e476@redhat.com> On 09/14/2017 03:20 PM, Roman Kennke wrote: > This patch fixes an issue in the aarch64 interpreter matrix barrier that caused > TestGCOldWithShenandoah to fail verification. The reason was that we invoke the > storeval-(read-)barrier *after* we copied the newval, and then pass the original to the matrix > barrier, thus connecting the wrong regions. > > The patch does: > - Move the storeval barrier before copying the newval > - Add a tmp3 arg to the shenandoah_write_barrier_post() to make it consistent (we've been using 2 > tmp regs passed via function call, and 1 implicit) > - Implement the fast matrix math as a bonus > > Test: hotspot_gc_shenandoah > > http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.00/ *) Passing third parameter makes the method consistent with what? shenandoah_write_barrier_post in x86 uses rscratch1 without having it passed via register. g1_write_barrier_post also does not pass rscratch1, but uses it. *) If you are using optimized math, why do you need heap base now? 3925 unsigned long offset; 3926 adrp(tmp3, ExternalAddress(ShenandoahHeap::heap()->base()), offset); 3927 assert(offset == 0, "Heap base address must be page aligned"); Thanks, -Aleksey From rkennke at redhat.com Thu Sep 14 14:39:32 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Sep 2017 16:39:32 +0200 Subject: RFR: Fix, improve and refactor matrix barrier on AAarch64 In-Reply-To: <9523f308-a01f-bb3b-0182-fc15e706e476@redhat.com> References: <663e9c13-6139-4781-43c0-cd20b259310c@redhat.com> <9523f308-a01f-bb3b-0182-fc15e706e476@redhat.com> Message-ID: <1fb68f54-1c70-6601-5c76-17abc249de63@redhat.com> Am 14.09.2017 um 15:52 schrieb Aleksey Shipilev: > On 09/14/2017 03:20 PM, Roman Kennke wrote: >> This patch fixes an issue in the aarch64 interpreter matrix barrier that caused >> TestGCOldWithShenandoah to fail verification. The reason was that we invoke the >> storeval-(read-)barrier *after* we copied the newval, and then pass the original to the matrix >> barrier, thus connecting the wrong regions. >> >> The patch does: >> - Move the storeval barrier before copying the newval >> - Add a tmp3 arg to the shenandoah_write_barrier_post() to make it consistent (we've been using 2 >> tmp regs passed via function call, and 1 implicit) >> - Implement the fast matrix math as a bonus >> >> Test: hotspot_gc_shenandoah >> >> http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.00/ > *) Passing third parameter makes the method consistent with what? shenandoah_write_barrier_post in > x86 uses rscratch1 without having it passed via register. g1_write_barrier_post also does not pass > rscratch1, but uses it. Most with itself. It seemed wrong to me to declare two temp regs as args, then use 3, and use 1 implicitely. Also, it made experimenting/changing temp reg while debugging easier. Do you want me to change it back? > *) If you are using optimized math, why do you need heap base now? > > 3925 unsigned long offset; > 3926 adrp(tmp3, ExternalAddress(ShenandoahHeap::heap()->base()), offset); > 3927 assert(offset == 0, "Heap base address must be page aligned"); Good catch! http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.01/ Better? Roman From shade at redhat.com Thu Sep 14 14:42:40 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Sep 2017 16:42:40 +0200 Subject: RFR: Fix, improve and refactor matrix barrier on AAarch64 In-Reply-To: <1fb68f54-1c70-6601-5c76-17abc249de63@redhat.com> References: <663e9c13-6139-4781-43c0-cd20b259310c@redhat.com> <9523f308-a01f-bb3b-0182-fc15e706e476@redhat.com> <1fb68f54-1c70-6601-5c76-17abc249de63@redhat.com> Message-ID: On 09/14/2017 04:39 PM, Roman Kennke wrote: > Am 14.09.2017 um 15:52 schrieb Aleksey Shipilev: >> *) Passing third parameter makes the method consistent with what? shenandoah_write_barrier_post in >> x86 uses rscratch1 without having it passed via register. g1_write_barrier_post also does not pass >> rscratch1, but uses it. > Most with itself. It seemed wrong to me to declare two temp regs as args, then use 3, and use 1 > implicitely. Also, it made experimenting/changing temp reg while debugging easier. Do you want me to > change it back? Yeah, change it back: I'd like to be consistent across arches and collectors. > http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.01/ Good, except for rscratch1 change. -Aleksey From rkennke at redhat.com Thu Sep 14 15:19:18 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Sep 2017 17:19:18 +0200 Subject: RFR: Fix, improve and refactor matrix barrier on AAarch64 In-Reply-To: References: <663e9c13-6139-4781-43c0-cd20b259310c@redhat.com> <9523f308-a01f-bb3b-0182-fc15e706e476@redhat.com> <1fb68f54-1c70-6601-5c76-17abc249de63@redhat.com> Message-ID: Am 14.09.2017 um 16:42 schrieb Aleksey Shipilev: > On 09/14/2017 04:39 PM, Roman Kennke wrote: >> Am 14.09.2017 um 15:52 schrieb Aleksey Shipilev: >>> *) Passing third parameter makes the method consistent with what? shenandoah_write_barrier_post in >>> x86 uses rscratch1 without having it passed via register. g1_write_barrier_post also does not pass >>> rscratch1, but uses it. >> Most with itself. It seemed wrong to me to declare two temp regs as args, then use 3, and use 1 >> implicitely. Also, it made experimenting/changing temp reg while debugging easier. Do you want me to >> change it back? > Yeah, change it back: I'd like to be consistent across arches and collectors. > >> http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.01/ > Good, except for rscratch1 change. Ok, I made it a compromise: kept the method signature the same (i.e. 2 tmp args), and declare tmp3 at the beginning of the code block to be rscratch1. http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.02/ Good now? From shade at redhat.com Thu Sep 14 15:20:23 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Sep 2017 17:20:23 +0200 Subject: RFR: Fix, improve and refactor matrix barrier on AAarch64 In-Reply-To: References: <663e9c13-6139-4781-43c0-cd20b259310c@redhat.com> <9523f308-a01f-bb3b-0182-fc15e706e476@redhat.com> <1fb68f54-1c70-6601-5c76-17abc249de63@redhat.com> Message-ID: <2be8f1fc-ff13-867a-e8d7-ba03ced758b2@redhat.com> On 09/14/2017 05:19 PM, Roman Kennke wrote: > Am 14.09.2017 um 16:42 schrieb Aleksey Shipilev: >> On 09/14/2017 04:39 PM, Roman Kennke wrote: >>> Am 14.09.2017 um 15:52 schrieb Aleksey Shipilev: >>>> *) Passing third parameter makes the method consistent with what? shenandoah_write_barrier_post in >>>> x86 uses rscratch1 without having it passed via register. g1_write_barrier_post also does not pass >>>> rscratch1, but uses it. >>> Most with itself. It seemed wrong to me to declare two temp regs as args, then use 3, and use 1 >>> implicitely. Also, it made experimenting/changing temp reg while debugging easier. Do you want me to >>> change it back? >> Yeah, change it back: I'd like to be consistent across arches and collectors. >> >>> http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.01/ >> Good, except for rscratch1 change. > > Ok, I made it a compromise: kept the method signature the same (i.e. 2 tmp args), and declare tmp3 > at the beginning of the code block to be rscratch1. > > http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.02/ Fine then. -Aleksey From roman at kennke.org Thu Sep 14 15:23:58 2017 From: roman at kennke.org (roman at kennke.org) Date: Thu, 14 Sep 2017 15:23:58 +0000 Subject: hg: shenandoah/jdk10/hotspot: Fix, improve and refactor matrix barrier on AAarch64. Message-ID: <201709141523.v8EFNwiK000782@aojmv0008.oracle.com> Changeset: 4c74a522ee99 Author: rkennke Date: 2017-09-14 11:09 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/4c74a522ee99 Fix, improve and refactor matrix barrier on AAarch64. ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/templateTable_aarch64.cpp From rkennke at redhat.com Thu Sep 14 17:09:01 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Sep 2017 19:09:01 +0200 Subject: RFR: Refactor evac-in-progress flag to more general gc-phase flag Message-ID: <497f0816-fc85-0622-f0b5-05510f841cc9@redhat.com> Here's another one in preparation of concurrent partial GC: This patch refactors the Thread::evacuation_in_progress flag to a more general gc_phase_in_progress flag. Instead of checking for 0 or != 0, it must now be masked with an appropriate gc-phase-mask before checking. Each bit represents a GC phase. For now, I've only done EVACUATION on bit 0. The idea here is that when storing an oop, we usually do: - check satb-in-progress (and do satb-barrier if so) - check evacuation-in-progress (and do write-barrier if so) and with conc partial, we want to check for conc-partial-in-progress and do a special barrier too. Putting all in one flag allows us to load the flag once, and test it repeatedly. The compiler may even common this flag-loading over multiple stores. Test: hotspot_gc_shenandoah on x86 and aarch64 http://cr.openjdk.java.net/~rkennke/gc-phase-flag/webrev.00/ From shade at redhat.com Thu Sep 14 18:04:36 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Sep 2017 20:04:36 +0200 Subject: RFR: Refactor evac-in-progress flag to more general gc-phase flag In-Reply-To: <497f0816-fc85-0622-f0b5-05510f841cc9@redhat.com> References: <497f0816-fc85-0622-f0b5-05510f841cc9@redhat.com> Message-ID: <73fa425a-1830-af7a-b914-8eec211c14d3@redhat.com> On 09/14/2017 07:09 PM, Roman Kennke wrote: > Here's another one in preparation of concurrent partial GC: > > This patch refactors the Thread::evacuation_in_progress flag to a more general gc_phase_in_progress > flag. Instead of checking for 0 or != 0, it must now be masked with an appropriate gc-phase-mask > before checking. Each bit represents a GC phase. For now, I've only done EVACUATION on bit 0. > > The idea here is that when storing an oop, we usually do: > > - check satb-in-progress (and do satb-barrier if so) > - check evacuation-in-progress (and do write-barrier if so) > > and with conc partial, we want to check for conc-partial-in-progress and do a special barrier too. > > Putting all in one flag allows us to load the flag once, and test it repeatedly. The compiler may > even common this flag-loading over multiple stores. > > Test: hotspot_gc_shenandoah on x86 and aarch64 > > http://cr.openjdk.java.net/~rkennke/gc-phase-flag/webrev.00/ *) There is no commonning for SATB and evac flags in this patch, right? *) aarch64 tests for EVACUATION_BITPOS: 63 __ tbz(rscratch1, ShenandoahHeap::EVACUATION_BITPOS, done); x86 tests for EVACUATION: 5623 testb(gc_phase_in_progress, ShenandoahHeap::EVACUATION); Why this discrepancy? *) Indent is wrong: 1610 static ByteSize gc_phase_in_progress_offset() { return byte_offset_of(JavaThread, _gc_phase_in_progress); } *) I wonder if state getters should really be left as "bool"-s: 166 char JavaThread::gc_phase_in_progress() const { 167 return _gc_phase_in_progress; 168 } ...e.g.: bool JavaThread::evacuation_in_progress() const ... Can't say for sure without seeing where is going. Thanks, -Aleksey From rkennke at redhat.com Thu Sep 14 18:27:41 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Sep 2017 20:27:41 +0200 Subject: RFR: Refactor evac-in-progress flag to more general gc-phase flag In-Reply-To: <73fa425a-1830-af7a-b914-8eec211c14d3@redhat.com> References: <497f0816-fc85-0622-f0b5-05510f841cc9@redhat.com> <73fa425a-1830-af7a-b914-8eec211c14d3@redhat.com> Message-ID: Am 14.09.2017 um 20:04 schrieb Aleksey Shipilev: > On 09/14/2017 07:09 PM, Roman Kennke wrote: >> Here's another one in preparation of concurrent partial GC: >> >> This patch refactors the Thread::evacuation_in_progress flag to a more general gc_phase_in_progress >> flag. Instead of checking for 0 or != 0, it must now be masked with an appropriate gc-phase-mask >> before checking. Each bit represents a GC phase. For now, I've only done EVACUATION on bit 0. >> >> The idea here is that when storing an oop, we usually do: >> >> - check satb-in-progress (and do satb-barrier if so) >> - check evacuation-in-progress (and do write-barrier if so) >> >> and with conc partial, we want to check for conc-partial-in-progress and do a special barrier too. >> >> Putting all in one flag allows us to load the flag once, and test it repeatedly. The compiler may >> even common this flag-loading over multiple stores. >> >> Test: hotspot_gc_shenandoah on x86 and aarch64 >> >> http://cr.openjdk.java.net/~rkennke/gc-phase-flag/webrev.00/ > *) There is no commonning for SATB and evac flags in this patch, right? Not yet. This is the next step. > *) aarch64 tests for EVACUATION_BITPOS: > > 63 __ tbz(rscratch1, ShenandoahHeap::EVACUATION_BITPOS, done); > > x86 tests for EVACUATION: > > 5623 testb(gc_phase_in_progress, ShenandoahHeap::EVACUATION); > > Why this discrepancy? Because the aarch64 tbz instruction takes the bit position as argument, not a mask. > *) Indent is wrong: > > 1610 static ByteSize gc_phase_in_progress_offset() { return byte_offset_of(JavaThread, > _gc_phase_in_progress); } Fixed in webrev below. > *) I wonder if state getters should really be left as "bool"-s: > > 166 char JavaThread::gc_phase_in_progress() const { > 167 return _gc_phase_in_progress; > 168 } > > ...e.g.: > > bool JavaThread::evacuation_in_progress() const ... > > Can't say for sure without seeing where is going. My reasoning is that the actual meaning of gc_phase in thread.hpp is GC-specific and thus opaque. Maybe in the future, another GC will use the same field(s), but with other set of GC phases. I'd put/leave the bool state getters in ShenandoahHeap, and get rid of the corresponding fields there. (In fact, we may want to put some sort of opaque void* there to allow GCs to manage thread-local data structures... but that is clearly another story) Only intendation is changed as you requested above: http://cr.openjdk.java.net/~rkennke/gc-phase-flag/webrev.01/ Ok to push? Roman From shade at redhat.com Thu Sep 14 18:28:55 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Sep 2017 20:28:55 +0200 Subject: RFR: Refactor evac-in-progress flag to more general gc-phase flag In-Reply-To: References: <497f0816-fc85-0622-f0b5-05510f841cc9@redhat.com> <73fa425a-1830-af7a-b914-8eec211c14d3@redhat.com> Message-ID: <406a227b-dcac-6423-6353-a12b89edaa64@redhat.com> On 09/14/2017 08:27 PM, Roman Kennke wrote: > Only intendation is changed as you requested above: > http://cr.openjdk.java.net/~rkennke/gc-phase-flag/webrev.01/ > > Ok to push? OK -Aleksey From shade at redhat.com Thu Sep 14 18:56:50 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Sep 2017 20:56:50 +0200 Subject: RFR: Asynchronous region recycling Message-ID: <2af839d4-29a3-e8f0-734c-453404fb77c3@redhat.com> http://cr.openjdk.java.net/~shade/shenandoah/async-recycle/webrev.02/ With large heaps that lead to large number of regions, we spend a lot of time (compared to the rest of the pause) in recycling the regions. This gets worse when partial collections are enabled, and we need to clean up the matrix then. We have done some optimizations there, but nothing beats making recycling really asynchronous. Recent heap region work enables us to do this! Brief tour of changes: *) Reclaim is now split into "trashing" (marking region Trash) and the actual "recycling" (marking region Empty); *) Introduced "Concurrent Cleanup" phase that runs after Final Mark, Final Update Refs and Partial to pick up asynchronous recycling. Folded "Concurrent Reset Bitmaps" into that phase. *) Verifier checks there are no lingering Trash regions between the phases/cycles. This would be committed as separate changeset. *) recycle_trash() is the entry point for asyncronous recycling. It uses a few tricks to improve performance. Notably, acquiring the locks very shortly to alleviate allocation stalls. *) Allocation paths make the attempt to recycle some trash regions on allocation failure. This is needed in case we have acquired the heap lock before the recycler had chance to run. *) Minor changes in FreeSet to first check for region present, and then checking the size. Otherwise duplicate regions blow the size assert first. Running SPECjvm:serial on 100 GB heap: http://cr.openjdk.java.net/~shade/shenandoah/async-recycle/serial-before.txt http://cr.openjdk.java.net/~shade/shenandoah/async-recycle/serial-after.txt Testing: hotspot_gc_shenandoah, benchmarks Thanks, -Aleksey From rkennke at redhat.com Thu Sep 14 19:39:01 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Sep 2017 21:39:01 +0200 Subject: RFR: Asynchronous region recycling In-Reply-To: <2af839d4-29a3-e8f0-734c-453404fb77c3@redhat.com> References: <2af839d4-29a3-e8f0-734c-453404fb77c3@redhat.com> Message-ID: <4f0284d8-c163-bf86-e727-497c1691af0a@redhat.com> Am 14.09.2017 um 20:56 schrieb Aleksey Shipilev: > http://cr.openjdk.java.net/~shade/shenandoah/async-recycle/webrev.02/ > > With large heaps that lead to large number of regions, we spend a lot of time (compared to the rest > of the pause) in recycling the regions. This gets worse when partial collections are enabled, and we > need to clean up the matrix then. We have done some optimizations there, but nothing beats making > recycling really asynchronous. Recent heap region work enables us to do this! > > Brief tour of changes: > > *) Reclaim is now split into "trashing" (marking region Trash) and the actual "recycling" (marking > region Empty); > > *) Introduced "Concurrent Cleanup" phase that runs after Final Mark, Final Update Refs and Partial > to pick up asynchronous recycling. Folded "Concurrent Reset Bitmaps" into that phase. > > *) Verifier checks there are no lingering Trash regions between the phases/cycles. This would be > committed as separate changeset. > > *) recycle_trash() is the entry point for asyncronous recycling. It uses a few tricks to improve > performance. Notably, acquiring the locks very shortly to alleviate allocation stalls. > > *) Allocation paths make the attempt to recycle some trash regions on allocation failure. This is > needed in case we have acquired the heap lock before the recycler had chance to run. > > *) Minor changes in FreeSet to first check for region present, and then checking the size. > Otherwise duplicate regions blow the size assert first. > > Running SPECjvm:serial on 100 GB heap: > http://cr.openjdk.java.net/~shade/shenandoah/async-recycle/serial-before.txt > http://cr.openjdk.java.net/~shade/shenandoah/async-recycle/serial-after.txt > > Testing: hotspot_gc_shenandoah, benchmarks > > Thanks, > -Aleksey > Looks good to me. Great work! ~28 -> 5ms pause? Impressive! :-) Roman From roman at kennke.org Fri Sep 15 08:31:53 2017 From: roman at kennke.org (roman at kennke.org) Date: Fri, 15 Sep 2017 08:31:53 +0000 Subject: hg: shenandoah/jdk10/hotspot: Refactor evac-in-progress flag to more general gc-phase flag. Message-ID: <201709150831.v8F8VrV8012118@aojmv0008.oracle.com> Changeset: 21f981ddecf1 Author: rkennke Date: 2017-09-13 09:55 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/21f981ddecf1 Refactor evac-in-progress flag to more general gc-phase flag. ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/opto/shenandoahSupport.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/thread.inline.hpp From ashipile at redhat.com Fri Sep 15 08:57:01 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 15 Sep 2017 08:57:01 +0000 Subject: hg: shenandoah/jdk10/hotspot: 2 new changesets Message-ID: <201709150857.v8F8v1Ic022746@aojmv0008.oracle.com> Changeset: 9de50bb66465 Author: shade Date: 2017-09-15 10:31 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/9de50bb66465 Verify regions status ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.hpp Changeset: 38af548c7ff8 Author: shade Date: 2017-09-15 10:31 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/38af548c7ff8 Asynchronous region recycling ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapLock.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp From shade at redhat.com Fri Sep 15 11:43:59 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 15 Sep 2017 13:43:59 +0200 Subject: RFR: Heap region sampling should publish region states Message-ID: <7c47c528-e339-7f37-866d-c7aa1a1e7c77@redhat.com> http://cr.openjdk.java.net/~shade/shenandoah/sampling-regionstates/webrev.01/ Visualizer changes are ready for this. Thanks, -Aleksey From rkennke at redhat.com Fri Sep 15 11:50:17 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 15 Sep 2017 13:50:17 +0200 Subject: RFR: Heap region sampling should publish region states In-Reply-To: <7c47c528-e339-7f37-866d-c7aa1a1e7c77@redhat.com> References: <7c47c528-e339-7f37-866d-c7aa1a1e7c77@redhat.com> Message-ID: Okidoki Am 15. September 2017 13:43:59 MESZ schrieb Aleksey Shipilev : >http://cr.openjdk.java.net/~shade/shenandoah/sampling-regionstates/webrev.01/ > >Visualizer changes are ready for this. > >Thanks, >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From ashipile at redhat.com Fri Sep 15 12:12:06 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 15 Sep 2017 12:12:06 +0000 Subject: hg: shenandoah/jdk10/hotspot: Heap region sampling should publish region states Message-ID: <201709151212.v8FCC655001675@aojmv0008.oracle.com> Changeset: 81064310822e Author: shade Date: 2017-09-15 13:51 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/81064310822e Heap region sampling should publish region states ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionCounters.hpp From zgu at redhat.com Fri Sep 15 14:15:59 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 15 Sep 2017 10:15:59 -0400 Subject: RFR: Fixup roots after partial GC failed Message-ID: We need to fixup roots after partial failed (just as SH::evacuate_and_update()). full-gc's update_roots() does not do the trick, 'cause it crosses safepoints, frames moved. Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/evac_dpt/webrev.00/index.html Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu From shade at redhat.com Fri Sep 15 14:22:57 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 15 Sep 2017 16:22:57 +0200 Subject: RFR: Fixup roots after partial GC failed In-Reply-To: References: Message-ID: On 09/15/2017 04:15 PM, Zhengyu Gu wrote: > We need to fixup roots after partial failed (just as SH::evacuate_and_update()). full-gc's > update_roots() does not do the trick, 'cause it crosses safepoints, frames moved. > > > Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/evac_dpt/webrev.00/index.html Looks good to me. It is weird to see that partial GC abort is also handled by conc_gc_cancelled flag. This assumes we are sliding into Full GC at that point, right? 341 } else { 342 // Fixup roots to make them consistent 343 _heap->fixup_roots(); 344 } Thanks, -Aleksey From zgu at redhat.com Fri Sep 15 14:26:02 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 15 Sep 2017 10:26:02 -0400 Subject: RFR: Fixup roots after partial GC failed In-Reply-To: References: Message-ID: <806140c7-414d-3d80-29f3-4b00a5d46e35@redhat.com> On 09/15/2017 10:22 AM, Aleksey Shipilev wrote: > On 09/15/2017 04:15 PM, Zhengyu Gu wrote: >> We need to fixup roots after partial failed (just as SH::evacuate_and_update()). full-gc's >> update_roots() does not do the trick, 'cause it crosses safepoints, frames moved. >> >> >> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/evac_dpt/webrev.00/index.html > > Looks good to me. > > It is weird to see that partial GC abort is also handled by conc_gc_cancelled flag. This assumes we > are sliding into Full GC at that point, right? > > 341 } else { > 342 // Fixup roots to make them consistent > 343 _heap->fixup_roots(); > 344 } > Yes. Make me wonder if we still need update_roots() in full-gc, since we should fix them up before that. Any opinions? or I will take a look. Thanks, -Zhengyu > Thanks, > -Aleksey > From zgu at redhat.com Fri Sep 15 14:30:07 2017 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 15 Sep 2017 14:30:07 +0000 Subject: hg: shenandoah/jdk10/hotspot: Fixup roots after partial GC failed Message-ID: <201709151430.v8FEU7sr012960@aojmv0008.oracle.com> Changeset: 240918f62fc2 Author: zgu Date: 2017-09-15 10:26 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/240918f62fc2 Fixup roots after partial GC failed ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp From zgu at redhat.com Fri Sep 15 15:01:31 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 15 Sep 2017 11:01:31 -0400 Subject: RFR: Fixup roots after partial GC failed In-Reply-To: <806140c7-414d-3d80-29f3-4b00a5d46e35@redhat.com> References: <806140c7-414d-3d80-29f3-4b00a5d46e35@redhat.com> Message-ID: <44a6757f-27ba-240d-b5ae-a10eed0167ca@redhat.com> > > Make me wonder if we still need update_roots() in full-gc, since we > should fix them up before that. > > Any opinions? or I will take a look. Never mind, they are different! -Zhengyu > > Thanks, > > -Zhengyu > > >> Thanks, >> -Aleksey >> From rkennke at redhat.com Fri Sep 15 18:38:44 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 15 Sep 2017 20:38:44 +0200 Subject: RFR: Remove obsolete and unused reduce-storeval-barrier optimization code Message-ID: This is an almost 1:1 revert of an earlier changeset that attempted to optimize storeval barriers. The idea back then was that when we check for conc-mark-in-progress anyway, we could just as well only invoke the storeval (i.e. read) - barrier if conc-mark is active. It never worked very well (and we never turned it on by default) and gained us anything significant. But now it's even worse: updating-refs now also happens outside conc-mark, and thus the whole idea is obsolete. In fact, maybe we can do something smarter once all the X_in_progress flags have been folded into the gc-phase-field (need to see this when it's there). The patch removes the code, and thus reduces our upstream diff. Test: hotspot_gc_shenandoah http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.00/ Ok? From rkennke at redhat.com Fri Sep 15 19:04:58 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 15 Sep 2017 21:04:58 +0200 Subject: RFR: Remove obsolete and unused reduce-storeval-barrier optimization code In-Reply-To: References: Message-ID: <470e40cb-26b3-3aae-42ca-4363a7c4904c@redhat.com> Don't bother reviewing this. I made a mistake. I removed the newval in some cases, but we do need it for the matrix barrier that is part of our C2 pre-barrier code path. I'll post an updated webrev soon (not today I guess... it's late here and almost weekend...) Roman > This is an almost 1:1 revert of an earlier changeset that attempted to > optimize storeval barriers. The idea back then was that when we check > for conc-mark-in-progress anyway, we could just as well only invoke > the storeval (i.e. read) - barrier if conc-mark is active. It never > worked very well (and we never turned it on by default) and gained us > anything significant. But now it's even worse: updating-refs now also > happens outside conc-mark, and thus the whole idea is obsolete. In > fact, maybe we can do something smarter once all the X_in_progress > flags have been folded into the gc-phase-field (need to see this when > it's there). The patch removes the code, and thus reduces our upstream > diff. > > Test: hotspot_gc_shenandoah > > http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.00/ > > > Ok? > From rkennke at redhat.com Sat Sep 16 09:37:57 2017 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 16 Sep 2017 11:37:57 +0200 Subject: RFR: Remove obsolete and unused reduce-storeval-barrier optimization code In-Reply-To: <470e40cb-26b3-3aae-42ca-4363a7c4904c@redhat.com> References: <470e40cb-26b3-3aae-42ca-4363a7c4904c@redhat.com> Message-ID: Ok. I fixed one place in library_call.cpp in the cmpxchg intrinsics. Everything else should be ok: http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.01/ Ok? Roman > Don't bother reviewing this. I made a mistake. I removed the newval in > some cases, but we do need it for the matrix barrier that is part of > our C2 pre-barrier code path. I'll post an updated webrev soon (not > today I guess... it's late here and almost weekend...) > > Roman > >> This is an almost 1:1 revert of an earlier changeset that attempted >> to optimize storeval barriers. The idea back then was that when we >> check for conc-mark-in-progress anyway, we could just as well only >> invoke the storeval (i.e. read) - barrier if conc-mark is active. It >> never worked very well (and we never turned it on by default) and >> gained us anything significant. But now it's even worse: >> updating-refs now also happens outside conc-mark, and thus the whole >> idea is obsolete. In fact, maybe we can do something smarter once all >> the X_in_progress flags have been folded into the gc-phase-field >> (need to see this when it's there). The patch removes the code, and >> thus reduces our upstream diff. >> >> Test: hotspot_gc_shenandoah >> >> http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.00/ >> >> >> Ok? >> > From rkennke at redhat.com Sun Sep 17 11:56:21 2017 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 17 Sep 2017 13:56:21 +0200 Subject: RFR: Message-ID: This builds on top of the remove-reduce-storeval-barrier-optimization patch. It refactors our conc-mark-in-progress flag together with the satb-in-progress-flag into our new gc-phase-in-progress bitfield. Notable stuff: - The patch removes a 2nd check for satb-in-progress in C1. I'll propose this upstream asap. - The G1/Shenandoah pre-barriers are refactored such that the satb-active (G1) and bitfield-concmark-checks (Sheanndoah) are now separated, while keeping the rest of the inlined SATB-queue-pushing code shared. - I noticed the store-checks code is wrong in both x86 and aarch64. We want to check the storeval-oops only when update-refs is in progress, but do the check statically, we need to do the check at runtime though because we might update refs during separate phase or during conc-mark. This should be fixed, but separately (and probably benefits from folding update-refs-in-progress into the bitfield too) - It involves quite a bit of refactoring in C2. I am fairly confident that it is correct. Would be good to have Roland take a look too. We should also check with Roland whether or not this is sufficient to allow commoning loads and checks of the bitfield, or if we need extra optimization passes for this. Test: hotspot_gc_shenandoah both x86 and aarch64 http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.01/ Roman From rkennke at redhat.com Sun Sep 17 12:11:04 2017 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 17 Sep 2017 14:11:04 +0200 Subject: RFR: Refactor conc-mark-in-progress/satb-active flags to use gc-phase-in-progress Message-ID: his builds on top of the remove-reduce-storeval-barrier-optimization patch. It refactors our conc-mark-in-progress flag together with the satb-in-progress-flag into our new gc-phase-in-progress bitfield. Notable stuff: - The patch removes a 2nd check for satb-in-progress in C1. I'll propose this upstream asap. - The G1/Shenandoah pre-barriers are refactored such that the satb-active (G1) and bitfield-concmark-checks (Sheanndoah) are now separated, while keeping the rest of the inlined SATB-queue-pushing code shared. - I noticed the store-checks code is wrong in both x86 and aarch64. We want to check the storeval-oops only when update-refs is in progress, but do the check statically, we need to do the check at runtime though because we might update refs during separate phase or during conc-mark. This should be fixed, but separately (and probably benefits from folding update-refs-in-progress into the bitfield too) - It involves quite a bit of refactoring in C2. I am fairly confident that it is correct. Would be good to have Roland take a look too. We should also check with Roland whether or not this is sufficient to allow commoning loads and checks of the bitfield, or if we need extra optimization passes for this. Test: hotspot_gc_shenandoah both x86 and aarch64 http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.01/ Roman From shade at redhat.com Mon Sep 18 09:58:01 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Sep 2017 11:58:01 +0200 Subject: RFR: Remove obsolete and unused reduce-storeval-barrier optimization code In-Reply-To: References: <470e40cb-26b3-3aae-42ca-4363a7c4904c@redhat.com> Message-ID: <1354604b-4a1e-09f1-b7fc-8acf5d3671fa@redhat.com> On 09/16/2017 11:37 AM, Roman Kennke wrote: > Ok. I fixed one place in library_call.cpp in the cmpxchg intrinsics. Everything else should be ok: > > http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.01/ *) I wonder if instead of putting shenandoah_storeval_barrier prior to store_oop_* calls, we are better putting the barriers calls inside of them? Under UseShenandoahGC flag? Otherwise, I see missing shenandoah_storeval_barrier in GraphKit::builtin_throw and Parse::expand_multianewarray. Seems good otherwise. Thanks, -Aleksey From shade at redhat.com Mon Sep 18 11:06:51 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Sep 2017 13:06:51 +0200 Subject: RFR: Store checks should run most of the time Message-ID: <5e1e7799-268f-c340-9a86-d27f8a5d38f8@redhat.com> http://cr.openjdk.java.net/~shade/shenandoah/store-check-cm-ur/webrev.02/ Current store check code is wrong at least for x86: it checks ShenandoahUpdateRefsEarly which is ccstr coerced to the bool. Also, it has to actually check for both CM and UR flags, not choosing one statically. After Roman's change that makes storeval barriers unconditional, we can actually only check for EVAC in progress, and thus cover most of the stores most of the time. Did AArch64 change blindly. Testing: hotspot_gc_shenandoah, simple jcstress with -XX:+ShenandoahStoreCheck Thanks, -Aleksey From rkennke at redhat.com Mon Sep 18 11:33:30 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 18 Sep 2017 13:33:30 +0200 Subject: RFR: Store checks should run most of the time In-Reply-To: <5e1e7799-268f-c340-9a86-d27f8a5d38f8@redhat.com> References: <5e1e7799-268f-c340-9a86-d27f8a5d38f8@redhat.com> Message-ID: <835251F1-7A9A-4FE5-88F4-EFB274A5EB93@redhat.com> Looks good. Except - Use the bitfield evac check? The field in SH is likely to go away soon . I can check+fix aarch64 Am 18. September 2017 13:06:51 MESZ schrieb Aleksey Shipilev : >http://cr.openjdk.java.net/~shade/shenandoah/store-check-cm-ur/webrev.02/ > >Current store check code is wrong at least for x86: it checks >ShenandoahUpdateRefsEarly which is >ccstr coerced to the bool. Also, it has to actually check for both CM >and UR flags, not choosing one >statically. After Roman's change that makes storeval barriers >unconditional, we can actually only >check for EVAC in progress, and thus cover most of the stores most of >the time. > >Did AArch64 change blindly. > >Testing: hotspot_gc_shenandoah, simple jcstress with >-XX:+ShenandoahStoreCheck > >Thanks, >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From shade at redhat.com Mon Sep 18 11:39:51 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Sep 2017 13:39:51 +0200 Subject: RFR: Store checks should run most of the time In-Reply-To: <835251F1-7A9A-4FE5-88F4-EFB274A5EB93@redhat.com> References: <5e1e7799-268f-c340-9a86-d27f8a5d38f8@redhat.com> <835251F1-7A9A-4FE5-88F4-EFB274A5EB93@redhat.com> Message-ID: On 09/18/2017 01:33 PM, Roman Kennke wrote: > Looks good. Except > - Use the bitfield evac check? The field in SH is likely to go away soon . I'd rather keep this in separate changeset, as to simplify backports. > I can check+fix aarch64 Please do. Thanks, -Aleksey From rkennke at redhat.com Mon Sep 18 11:40:31 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 18 Sep 2017 13:40:31 +0200 Subject: RFR: Store checks should run most of the time In-Reply-To: References: <5e1e7799-268f-c340-9a86-d27f8a5d38f8@redhat.com> <835251F1-7A9A-4FE5-88F4-EFB274A5EB93@redhat.com> Message-ID: <426CC443-CAF2-4746-93AA-449D3601CF61@redhat.com> OK then Am 18. September 2017 13:39:51 MESZ schrieb Aleksey Shipilev : >On 09/18/2017 01:33 PM, Roman Kennke wrote: >> Looks good. Except >> - Use the bitfield evac check? The field in SH is likely to go away >soon . > >I'd rather keep this in separate changeset, as to simplify backports. > >> I can check+fix aarch64 > >Please do. > >Thanks, >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From zgu at redhat.com Mon Sep 18 12:42:09 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 18 Sep 2017 08:42:09 -0400 Subject: RFR: Ensure tasks use correct number of workers Message-ID: Ensure that GC tasks follow parallel/concurrent worker protocol, use correct number of worker threads. Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/assert_workers/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu From shade at redhat.com Mon Sep 18 13:10:22 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Sep 2017 15:10:22 +0200 Subject: RFR: Ensure tasks use correct number of workers In-Reply-To: References: Message-ID: On 09/18/2017 02:42 PM, Zhengyu Gu wrote: > Ensure that GC tasks follow parallel/concurrent worker protocol, use correct number of worker threads. > > Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/assert_workers/webrev.00/ *) I see that ShenandoahCollectorPolicy computes the number of workers for different phases. Do we want at least do the call to to policy, instead of using ParallelGCThreads/ConcGCThreads directly? This will capture all worker count decisions, however static, in one place. *) How long is TestGCThreadGroups? It seems to be derived from LotsOfCycles test, but we can really do much smaller allocation target, e.g. 10x lower? *) Typo "SWT": 257 void ShenandoahPartialGC::do_partial_collection() { 258 assert(SafepointSynchronize::is_at_safepoint(), "SWT partial GC"); *) Type "none-regular": 44 // bypass concurrent/parallel protocol check for none-regular paths, e.g. verifier, etc. Thanks, -Aleksey From rkennke at redhat.com Mon Sep 18 13:27:08 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 18 Sep 2017 15:27:08 +0200 Subject: RFR: Store checks should run most of the time In-Reply-To: References: <5e1e7799-268f-c340-9a86-d27f8a5d38f8@redhat.com> <835251F1-7A9A-4FE5-88F4-EFB274A5EB93@redhat.com> Message-ID: <35230c7d-f7d4-83f3-9611-9aca388202f1@redhat.com> >> I can check+fix aarch64 > Please do. Shenandoah on AArch64 builds with the patch applied, and VerifyJCStressTest runs fine. This test enables this particular code path. Roman From ashipile at redhat.com Mon Sep 18 13:31:08 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 18 Sep 2017 13:31:08 +0000 Subject: hg: shenandoah/jdk10/hotspot: Store checks should run most of the time Message-ID: <201709181331.v8IDV8Lg021457@aojmv0008.oracle.com> Changeset: f385c15b00fc Author: shade Date: 2017-09-18 13:19 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/f385c15b00fc Store checks should run most of the time ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp From zgu at redhat.com Mon Sep 18 13:28:49 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 18 Sep 2017 09:28:49 -0400 Subject: RFR: Ensure tasks use correct number of workers In-Reply-To: References: Message-ID: <1c92af4d-8eac-83c8-ba04-f0250b7d8b1c@redhat.com> On 09/18/2017 09:10 AM, Aleksey Shipilev wrote: > On 09/18/2017 02:42 PM, Zhengyu Gu wrote: >> Ensure that GC tasks follow parallel/concurrent worker protocol, use correct number of worker threads. >> >> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/assert_workers/webrev.00/ > > *) I see that ShenandoahCollectorPolicy computes the number of workers for different phases. Do we > want at least do the call to to policy, instead of using ParallelGCThreads/ConcGCThreads directly? > This will capture all worker count decisions, however static, in one place. Let's do it separately. It does not cover all scenarios, I think. > > *) How long is TestGCThreadGroups? It seems to be derived from LotsOfCycles test, but we can really > do much smaller allocation target, e.g. 10x lower? It did not timeout. Okay to lower target to 1/10 - Done. > > *) Typo "SWT": > > 257 void ShenandoahPartialGC::do_partial_collection() { > 258 assert(SafepointSynchronize::is_at_safepoint(), "SWT partial GC"); > > *) Type "none-regular": > > 44 // bypass concurrent/parallel protocol check for none-regular paths, e.g. verifier, etc. > Fixed. Updated: http://cr.openjdk.java.net/~zgu/shenandoah/assert_workers/webrev.01/ Thanks, -Zhengyu > Thanks, > -Aleksey > From rkennke at redhat.com Mon Sep 18 13:30:07 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 18 Sep 2017 15:30:07 +0200 Subject: RFR: Remove obsolete and unused reduce-storeval-barrier optimization code In-Reply-To: <1354604b-4a1e-09f1-b7fc-8acf5d3671fa@redhat.com> References: <470e40cb-26b3-3aae-42ca-4363a7c4904c@redhat.com> <1354604b-4a1e-09f1-b7fc-8acf5d3671fa@redhat.com> Message-ID: <58adf638-5c98-2a9f-adfc-85fc7485bfa6@redhat.com> Am 18.09.2017 um 11:58 schrieb Aleksey Shipilev: > On 09/16/2017 11:37 AM, Roman Kennke wrote: >> Ok. I fixed one place in library_call.cpp in the cmpxchg intrinsics. Everything else should be ok: >> >> http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.01/ > *) I wonder if instead of putting shenandoah_storeval_barrier prior to store_oop_* calls, we are > better putting the barriers calls inside of them? Under UseShenandoahGC flag? Otherwise, I see > missing shenandoah_storeval_barrier in GraphKit::builtin_throw and Parse::expand_multianewarray. > > Seems good otherwise. Good point. Like this? http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.02/ From shade at redhat.com Mon Sep 18 13:31:28 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Sep 2017 15:31:28 +0200 Subject: RFR: Ensure tasks use correct number of workers In-Reply-To: <1c92af4d-8eac-83c8-ba04-f0250b7d8b1c@redhat.com> References: <1c92af4d-8eac-83c8-ba04-f0250b7d8b1c@redhat.com> Message-ID: On 09/18/2017 03:28 PM, Zhengyu Gu wrote: > On 09/18/2017 09:10 AM, Aleksey Shipilev wrote: >> *) I see that ShenandoahCollectorPolicy computes the number of workers for different phases. Do we >> want at least do the call to to policy, instead of using ParallelGCThreads/ConcGCThreads directly? >> This will capture all worker count decisions, however static, in one place. > > Let's do it separately. It does not cover all scenarios, I think. Sure. Please take care of it. > Updated: http://cr.openjdk.java.net/~zgu/shenandoah/assert_workers/webrev.01/ Looks good! -Aleksey From zgu at redhat.com Mon Sep 18 13:44:26 2017 From: zgu at redhat.com (zgu at redhat.com) Date: Mon, 18 Sep 2017 13:44:26 +0000 Subject: hg: shenandoah/jdk10/hotspot: Ensure tasks use correct number of workers Message-ID: <201709181344.v8IDiQ7a026354@aojmv0008.oracle.com> Changeset: 3057f2726c51 Author: zgu Date: 2017-09-18 09:36 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/3057f2726c51 Ensure tasks use correct number of workers ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc/shenandoah/shenandoahWorkGroup.cpp ! src/share/vm/gc/shenandoah/shenandoahWorkGroup.hpp From shade at redhat.com Mon Sep 18 13:41:45 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Sep 2017 15:41:45 +0200 Subject: RFR: Remove obsolete and unused reduce-storeval-barrier optimization code In-Reply-To: <58adf638-5c98-2a9f-adfc-85fc7485bfa6@redhat.com> References: <470e40cb-26b3-3aae-42ca-4363a7c4904c@redhat.com> <1354604b-4a1e-09f1-b7fc-8acf5d3671fa@redhat.com> <58adf638-5c98-2a9f-adfc-85fc7485bfa6@redhat.com> Message-ID: <3e9d8ce4-ced8-7ca4-3ec4-b01e567e3319@redhat.com> On 09/18/2017 03:30 PM, Roman Kennke wrote: > Am 18.09.2017 um 11:58 schrieb Aleksey Shipilev: >> On 09/16/2017 11:37 AM, Roman Kennke wrote: >>> Ok. I fixed one place in library_call.cpp in the cmpxchg intrinsics. Everything else should be ok: >>> >>> http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.01/ >> *) I wonder if instead of putting shenandoah_storeval_barrier prior to store_oop_* calls, we are >> better putting the barriers calls inside of them? Under UseShenandoahGC flag? Otherwise, I see >> missing shenandoah_storeval_barrier in GraphKit::builtin_throw and Parse::expand_multianewarray. >> >> Seems good otherwise. > Good point. Like this? > > http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.02/ Looks better. So, the shenandoah_storeval_barrier from LibraryCallKit::LibraryCallKit::inline_unsafe_load_store is now subsumed by something else? Can't see by what. -Aleksey From roman at kennke.org Mon Sep 18 13:52:23 2017 From: roman at kennke.org (Roman Kennke) Date: Mon, 18 Sep 2017 15:52:23 +0200 Subject: RFR: Remove obsolete and unused reduce-storeval-barrier optimization code In-Reply-To: <3e9d8ce4-ced8-7ca4-3ec4-b01e567e3319@redhat.com> References: <470e40cb-26b3-3aae-42ca-4363a7c4904c@redhat.com> <1354604b-4a1e-09f1-b7fc-8acf5d3671fa@redhat.com> <58adf638-5c98-2a9f-adfc-85fc7485bfa6@redhat.com> <3e9d8ce4-ced8-7ca4-3ec4-b01e567e3319@redhat.com> Message-ID: <678ce8a9-5c5d-b552-9389-e035913acc4b@kennke.org> Am 18.09.2017 um 15:41 schrieb Aleksey Shipilev: > On 09/18/2017 03:30 PM, Roman Kennke wrote: >> Am 18.09.2017 um 11:58 schrieb Aleksey Shipilev: >>> On 09/16/2017 11:37 AM, Roman Kennke wrote: >>>> Ok. I fixed one place in library_call.cpp in the cmpxchg intrinsics. Everything else should be ok: >>>> >>>> http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.01/ >>> *) I wonder if instead of putting shenandoah_storeval_barrier prior to store_oop_* calls, we are >>> better putting the barriers calls inside of them? Under UseShenandoahGC flag? Otherwise, I see >>> missing shenandoah_storeval_barrier in GraphKit::builtin_throw and Parse::expand_multianewarray. >>> >>> Seems good otherwise. >> Good point. Like this? >> >> http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.02/ > Looks better. > > So, the shenandoah_storeval_barrier from LibraryCallKit::LibraryCallKit::inline_unsafe_load_store is > now subsumed by something else? Can't see by what. Good catch! I re-instated the storeval-barrier in the T_OBJECT versions of the unsafe_load_store intrinsics, the same way it has been before I introduced the optimization back then: http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.03/ Roman From shade at redhat.com Mon Sep 18 14:56:25 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Sep 2017 16:56:25 +0200 Subject: RFR: Remove obsolete and unused reduce-storeval-barrier optimization code In-Reply-To: <678ce8a9-5c5d-b552-9389-e035913acc4b@kennke.org> References: <470e40cb-26b3-3aae-42ca-4363a7c4904c@redhat.com> <1354604b-4a1e-09f1-b7fc-8acf5d3671fa@redhat.com> <58adf638-5c98-2a9f-adfc-85fc7485bfa6@redhat.com> <3e9d8ce4-ced8-7ca4-3ec4-b01e567e3319@redhat.com> <678ce8a9-5c5d-b552-9389-e035913acc4b@kennke.org> Message-ID: <03bd3307-e6d8-4a30-5f6f-cc129420e33b@redhat.com> On 09/18/2017 03:52 PM, Roman Kennke wrote: > I re-instated the storeval-barrier in the T_OBJECT versions of the unsafe_load_store intrinsics, > the same way it has been before I introduced the optimization back then: > > http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.03/ Okay, good. -Aleksey From rwestrel at redhat.com Tue Sep 19 11:55:10 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Tue, 19 Sep 2017 11:55:10 +0000 Subject: hg: shenandoah/jdk10/hotspot: PhiNode::has_only_data_users() needs to apply to shenandoah barrier only Message-ID: <201709191155.v8JBtAvO025415@aojmv0008.oracle.com> Changeset: d78ca7e360db Author: roland Date: 2017-09-19 13:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/d78ca7e360db PhiNode::has_only_data_users() needs to apply to shenandoah barrier only ! src/share/vm/opto/cfgnode.cpp From rwestrel at redhat.com Tue Sep 19 12:09:43 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Tue, 19 Sep 2017 12:09:43 +0000 Subject: hg: shenandoah/jdk9/hotspot: [backport] PhiNode::has_only_data_users() needs to apply to shenandoah barrier only Message-ID: <201709191209.v8JC9h9G008758@aojmv0008.oracle.com> Changeset: 5a2c94c904a3 Author: roland Date: 2017-09-19 13:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/5a2c94c904a3 [backport] PhiNode::has_only_data_users() needs to apply to shenandoah barrier only ! src/share/vm/opto/cfgnode.cpp From rwestrel at redhat.com Tue Sep 19 12:16:02 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Tue, 19 Sep 2017 12:16:02 +0000 Subject: hg: shenandoah/jdk8u/hotspot: [backport] PhiNode::has_only_data_users() needs to apply to shenandoah barrier only Message-ID: <201709191216.v8JCG28B011255@aojmv0008.oracle.com> Changeset: fb33714d09ea Author: roland Date: 2017-09-19 13:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/fb33714d09ea [backport] PhiNode::has_only_data_users() needs to apply to shenandoah barrier only ! src/share/vm/opto/cfgnode.cpp From zgu at redhat.com Tue Sep 19 14:00:49 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 19 Sep 2017 10:00:49 -0400 Subject: RFR: Fix assert_gc_workers() and missing test case Message-ID: I don't know how I missed this! Test case was missing in final push due to merge. Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/assert_workers_fix/webrev.00/ Test: Reran hotspot_gc_shenandoah fastdebug. -Zhengyu From shade at redhat.com Tue Sep 19 14:24:49 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 19 Sep 2017 16:24:49 +0200 Subject: RFR: FreeSet refactor: bitmaps, cursors, biasing Message-ID: <5eb2d769-72b2-3e54-1834-32113e5359d1@redhat.com> http://cr.openjdk.java.net/~shade/shenandoah/freeset-bitmaps/webrev.01/ This is actually 3-in-1 patch, because there is a fair amount of cohesion between all of them. Brief tour of changes: *) Allocation code moved from ShenandoahHeap to ShenandoahFreeSet. This will soon become the ShenandoahHeapRegionManager, if you see where it goes. The API is cleaned up a bit, and privately used methods are now really private. *) FreeSet now maintains the bitmap instead of collection of regions. This allows maintaining the sorted view of free regions, which is important when asynchronous recycling works. Async recycling may add regions in random order, and humongous allocation would be unhappy about that. The bitmap also allows resuming the allocation at the "earlier" region once it is added, making footprint story easier. *) FreeSet maintains two boundary cursors, "leftmost" and "rightmost", that bound the bitmap. This serves as the optimization for allocation path, because it can look up either boundary and see the free region there. We could, in principle, use the optimized bitmap scans in future to make the allocation in ragged heap even faster. *) Two boundary cursors also allow _biasing_ the allocations to either end. Biasing application allocations help to optimize allocation path even further, because we clean up the beginning of heap most of the time. Testing: hotspot_gc_shenandoah, benchmarks, eyeballing Visualizer LRU running under Visualizer with this change: http://cr.openjdk.java.net/~shade/shenandoah/freeset-bitmaps/lru.mp4 Thanks, -Aleksey From shade at redhat.com Tue Sep 19 14:27:06 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 19 Sep 2017 16:27:06 +0200 Subject: RFR: Fix assert_gc_workers() and missing test case In-Reply-To: References: Message-ID: <102322b2-56d4-0079-d0cd-2afc9e93a355@redhat.com> On 09/19/2017 04:00 PM, Zhengyu Gu wrote: > I don't know how I missed this! Test case was missing in final push due to merge. > > Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/assert_workers_fix/webrev.00/ Okay. -Aleksey From zgu at redhat.com Tue Sep 19 14:30:47 2017 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 19 Sep 2017 14:30:47 +0000 Subject: hg: shenandoah/jdk10/hotspot: Fix assert_gc_workers() and missing test case Message-ID: <201709191430.v8JEUlOa015190@aojmv0008.oracle.com> Changeset: 6763f5187654 Author: zgu Date: 2017-09-19 10:27 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/6763f5187654 Fix assert_gc_workers() and missing test case ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp + test/gc/shenandoah/TestGCThreadGroups.java From chf at redhat.com Tue Sep 19 15:14:03 2017 From: chf at redhat.com (chf at redhat.com) Date: Tue, 19 Sep 2017 15:14:03 +0000 Subject: hg: shenandoah/jdk10/hotspot: Updates to generational/lru partial heuristics Message-ID: <201709191514.v8JFE3j7004535@aojmv0008.oracle.com> Changeset: 99260c18717d Author: chf Date: 2017-09-19 11:07 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/99260c18717d Updates to generational/lru partial heuristics ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp From zgu at redhat.com Tue Sep 19 15:20:46 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 19 Sep 2017 11:20:46 -0400 Subject: RFR: FreeSet refactor: bitmaps, cursors, biasing In-Reply-To: <5eb2d769-72b2-3e54-1834-32113e5359d1@redhat.com> References: <5eb2d769-72b2-3e54-1834-32113e5359d1@redhat.com> Message-ID: Looks good to me. -Zhengyu On 09/19/2017 10:24 AM, Aleksey Shipilev wrote: > http://cr.openjdk.java.net/~shade/shenandoah/freeset-bitmaps/webrev.01/ > > This is actually 3-in-1 patch, because there is a fair amount of cohesion between all of them. Brief > tour of changes: > > *) Allocation code moved from ShenandoahHeap to ShenandoahFreeSet. This will soon become the > ShenandoahHeapRegionManager, if you see where it goes. The API is cleaned up a bit, and privately > used methods are now really private. > > *) FreeSet now maintains the bitmap instead of collection of regions. This allows maintaining the > sorted view of free regions, which is important when asynchronous recycling works. Async recycling > may add regions in random order, and humongous allocation would be unhappy about that. The bitmap > also allows resuming the allocation at the "earlier" region once it is added, making footprint story > easier.Goo > > *) FreeSet maintains two boundary cursors, "leftmost" and "rightmost", that bound the bitmap. This > serves as the optimization for allocation path, because it can look up either boundary and see the > free region there. We could, in principle, use the optimized bitmap scans in future to make the > allocation in ragged heap even faster. > > *) Two boundary cursors also allow _biasing_ the allocations to either end. Biasing application > allocations help to optimize allocation path even further, because we clean up the beginning of heap > most of the time. > > Testing: hotspot_gc_shenandoah, benchmarks, eyeballing Visualizer > > LRU running under Visualizer with this change: > http://cr.openjdk.java.net/~shade/shenandoah/freeset-bitmaps/lru.mp4 > > Thanks, > -Aleksey > From shade at redhat.com Tue Sep 19 16:34:45 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 19 Sep 2017 18:34:45 +0200 Subject: RFR: FreeSet refactor: bitmaps, cursors, biasing In-Reply-To: <5eb2d769-72b2-3e54-1834-32113e5359d1@redhat.com> References: <5eb2d769-72b2-3e54-1834-32113e5359d1@redhat.com> Message-ID: <66b8e7e2-9e80-1f49-c036-8360081f47f2@redhat.com> On 09/19/2017 04:24 PM, Aleksey Shipilev wrote: > http://cr.openjdk.java.net/~shade/shenandoah/freeset-bitmaps/webrev.01/ > > This is actually 3-in-1 patch, because there is a fair amount of cohesion between all of them. Brief > tour of changes: > > *) Allocation code moved from ShenandoahHeap to ShenandoahFreeSet. This will soon become the > ShenandoahHeapRegionManager, if you see where it goes. The API is cleaned up a bit, and privately > used methods are now really private. > > *) FreeSet now maintains the bitmap instead of collection of regions. This allows maintaining the > sorted view of free regions, which is important when asynchronous recycling works. Async recycling > may add regions in random order, and humongous allocation would be unhappy about that. The bitmap > also allows resuming the allocation at the "earlier" region once it is added, making footprint story > easier. > > *) FreeSet maintains two boundary cursors, "leftmost" and "rightmost", that bound the bitmap. This > serves as the optimization for allocation path, because it can look up either boundary and see the > free region there. We could, in principle, use the optimized bitmap scans in future to make the > allocation in ragged heap even faster. > > *) Two boundary cursors also allow _biasing_ the allocations to either end. Biasing application > allocations help to optimize allocation path even further, because we clean up the beginning of heap > most of the time. Turns out, I blew the allocation performance a bit by assuming we can leave the non-full region alone in case we might have the allocation that fit later. This gives an interesting side effect for update-counter code that assumes that allocation further from the boundary is the allocation in "new region", and forces the counter update. This does make allocation slower for non-TLAB cases by order of magnitude, but affects TLAB case as well. Fixed, and retested, and added asserts, and added TODO: http://cr.openjdk.java.net/~shade/shenandoah/freeset-bitmaps/webrev.02/ Thanks, -Aleksey From zgu at redhat.com Tue Sep 19 18:14:05 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 19 Sep 2017 14:14:05 -0400 Subject: RFR: FreeSet refactor: bitmaps, cursors, biasing In-Reply-To: <66b8e7e2-9e80-1f49-c036-8360081f47f2@redhat.com> References: <5eb2d769-72b2-3e54-1834-32113e5359d1@redhat.com> <66b8e7e2-9e80-1f49-c036-8360081f47f2@redhat.com> Message-ID: Okay. -Zhengyu On 09/19/2017 12:34 PM, Aleksey Shipilev wrote: > On 09/19/2017 04:24 PM, Aleksey Shipilev wrote: >> http://cr.openjdk.java.net/~shade/shenandoah/freeset-bitmaps/webrev.01/ >> >> This is actually 3-in-1 patch, because there is a fair amount of cohesion between all of them. Brief >> tour of changes: >> >> *) Allocation code moved from ShenandoahHeap to ShenandoahFreeSet. This will soon become the >> ShenandoahHeapRegionManager, if you see where it goes. The API is cleaned up a bit, and privately >> used methods are now really private. >> >> *) FreeSet now maintains the bitmap instead of collection of regions. This allows maintaining the >> sorted view of free regions, which is important when asynchronous recycling works. Async recycling >> may add regions in random order, and humongous allocation would be unhappy about that. The bitmap >> also allows resuming the allocation at the "earlier" region once it is added, making footprint story >> easier. >> >> *) FreeSet maintains two boundary cursors, "leftmost" and "rightmost", that bound the bitmap. This >> serves as the optimization for allocation path, because it can look up either boundary and see the >> free region there. We could, in principle, use the optimized bitmap scans in future to make the >> allocation in ragged heap even faster. >> >> *) Two boundary cursors also allow _biasing_ the allocations to either end. Biasing application >> allocations help to optimize allocation path even further, because we clean up the beginning of heap >> most of the time. > > Turns out, I blew the allocation performance a bit by assuming we can leave the non-full region > alone in case we might have the allocation that fit later. This gives an interesting side effect for > update-counter code that assumes that allocation further from the boundary is the allocation in "new > region", and forces the counter update. This does make allocation slower for non-TLAB cases by order > of magnitude, but affects TLAB case as well. > > Fixed, and retested, and added asserts, and added TODO: > http://cr.openjdk.java.net/~shade/shenandoah/freeset-bitmaps/webrev.02/ > > Thanks, > -Aleksey > From ashipile at redhat.com Tue Sep 19 18:43:50 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 19 Sep 2017 18:43:50 +0000 Subject: hg: shenandoah/jdk10/hotspot: FreeSet refactor: bitmaps, cursors, biasing Message-ID: <201709191843.v8JIhomB019629@aojmv0008.oracle.com> Changeset: 7db219c70425 Author: shade Date: 2017-09-19 20:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/7db219c70425 FreeSet refactor: bitmaps, cursors, biasing ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp From shade at redhat.com Wed Sep 20 10:10:39 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Sep 2017 12:10:39 +0200 Subject: RFC: TLAB allocation and garbage-first policy Message-ID: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> Hi, We do have a problem on the edge of TLAB allocation machinery and garbage-first collection policy. Current TLAB machinery in Hotspot polls the GC about the next TLAB size with CollectedHeap::unsafe_max_tlab_alloc. The trouble is that call is inherently racy, and is expected to provide the best guess that GC can do under the circumstances. The race unfolds like this: 1. GC looks around and realizes there is a fully-empty region in the allocation list, and happily reports $region_size to VM 2. Another allocation comes and does the smaller-than-region-size allocation in that fully-empty region. 3. Resumes, tries to allocate full TLAB, but the region that was deemed empty at step 1 is fragmented already, so it retires the region from the freeset (it does so to optimize allocation path), and proceeds to allocate at the one past that. End result: we have the fragmented region that gets immediately retired and becomes not available for any further allocations. Granted, the actual issue is the raciness in TLAB machinery. Unfortunately, it would be hard to fix without redoing CollectedHeap API. Now to the fun part about our collection policy. Our collector policy selects the regions by least garbage, where garbage = used - live. So, if you have the fragmented 16M region with used=128K, and live=128K, it is exactly 0K garbage -- the least probable candidate. So the region that become fragmented due to the race in TLAB machinery is also never considered for collection, because it is below the ShenandoahGarbageThreshold! This race further widens when we bias the TLAB and GCLAB allocations to different sides of the heap, and GCLABs take the most hit. You can clearly see the anomaly in Visualizer after 10+ minutes of LRUFragger run with 50 GB LDS on 100 GB heap (...and it drives into Full GC shortly afterwards, because free set got depleted due to fragmentation!): http://cr.openjdk.java.net/~shade/shenandoah/wip-tlab-race/baseline-1.png Therefore, I propose we choose the regions by *live size*, not by *garbage*, so that we can recover by collecting (and evacuating) the regions with low live, not exactly with high garbage. This should help to recuperate from TLAB losses better. For full regions, both metrics yield the same result. For half-full regions, we would have a chance to compact them into mostly-full, leaving more fully-empty regions around. I mused about this on IRC yesterday, and today I see G1 does the same, see CollectionSetChooser::should_add: bool should_add(HeapRegion* hr) { assert(hr->is_marked(), "pre-condition"); assert(!hr->is_young(), "should never consider young regions"); return !hr->is_pinned() && hr->live_bytes() < _region_live_threshold_bytes; // <----- here } ...and probably with the same rationale? Found these bugs: https://bugs.openjdk.java.net/browse/JDK-7132029 https://bugs.openjdk.java.net/browse/JDK-7146242 Prototype fix: virtual bool region_in_collection_set(ShenandoahHeapRegion* r, size_t immediate_garbage) { size_t threshold = ShenandoahHeapRegion::region_size_bytes() * ShenandoahGarbageThreshold / 100; - return r->garbage() > threshold; + if (UseNewCode) { + return (ShenandoahHeapRegion::region_size_bytes() - r->get_live_data_bytes()) > threshold; + } else { + return r->garbage() > threshold; + } } ...makes the issue disappear on the same workload running for 30+ minutes (and no Full GCs!): http://cr.openjdk.java.net/~shade/shenandoah/wip-tlab-race/patched-1.png Thoughts? Thanks, -Aleksey From roman at kennke.org Wed Sep 20 11:04:12 2017 From: roman at kennke.org (Roman Kennke) Date: Wed, 20 Sep 2017 13:04:12 +0200 Subject: RFC: TLAB allocation and garbage-first policy In-Reply-To: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> Message-ID: <84f87bdd-6fb1-864d-a617-4220856c123a@kennke.org> Am 20.09.2017 um 12:10 schrieb Aleksey Shipilev: > Hi, > > We do have a problem on the edge of TLAB allocation machinery and garbage-first collection policy. > Current TLAB machinery in Hotspot polls the GC about the next TLAB size with > CollectedHeap::unsafe_max_tlab_alloc. The trouble is that call is inherently racy, and is expected > to provide the best guess that GC can do under the circumstances. > > The race unfolds like this: > 1. GC looks around and realizes there is a fully-empty region in the allocation list, > and happily reports $region_size to VM > 2. Another allocation comes and does the smaller-than-region-size allocation in that > fully-empty region. > 3. Resumes, tries to allocate full TLAB, but the region that was deemed empty at step 1 > is fragmented already, so it retires the region from the freeset (it does so to optimize allocation > path), and proceeds to allocate at the one past that. > > End result: we have the fragmented region that gets immediately retired and becomes not available > for any further allocations. Granted, the actual issue is the raciness in TLAB machinery. > Unfortunately, it would be hard to fix without redoing CollectedHeap API. > > Now to the fun part about our collection policy. Our collector policy selects the regions by least > garbage, where garbage = used - live. So, if you have the fragmented 16M region with used=128K, and > live=128K, it is exactly 0K garbage -- the least probable candidate. So the region that become > fragmented due to the race in TLAB machinery is also never considered for collection, because it is > below the ShenandoahGarbageThreshold! > > This race further widens when we bias the TLAB and GCLAB allocations to different sides of the heap, > and GCLABs take the most hit. You can clearly see the anomaly in Visualizer after 10+ minutes of > LRUFragger run with 50 GB LDS on 100 GB heap (...and it drives into Full GC shortly afterwards, > because free set got depleted due to fragmentation!): > http://cr.openjdk.java.net/~shade/shenandoah/wip-tlab-race/baseline-1.png > > Therefore, I propose we choose the regions by *live size*, not by *garbage*, so that we can recover > by collecting (and evacuating) the regions with low live, not exactly with high garbage. This should > help to recuperate from TLAB losses better. For full regions, both metrics yield the same result. > For half-full regions, we would have a chance to compact them into mostly-full, leaving more > fully-empty regions around. > > I mused about this on IRC yesterday, and today I see G1 does the same, see > CollectionSetChooser::should_add: > > bool should_add(HeapRegion* hr) { > assert(hr->is_marked(), "pre-condition"); > assert(!hr->is_young(), "should never consider young regions"); > return !hr->is_pinned() && > hr->live_bytes() < _region_live_threshold_bytes; // <----- here > } > > ...and probably with the same rationale? Found these bugs: > https://bugs.openjdk.java.net/browse/JDK-7132029 > https://bugs.openjdk.java.net/browse/JDK-7146242 > > Prototype fix: > > virtual bool region_in_collection_set(ShenandoahHeapRegion* r, size_t immediate_garbage) { > size_t threshold = ShenandoahHeapRegion::region_size_bytes() * ShenandoahGarbageThreshold / 100; > - return r->garbage() > threshold; > + if (UseNewCode) { > + return (ShenandoahHeapRegion::region_size_bytes() - r->get_live_data_bytes()) > threshold; > + } else { > + return r->garbage() > threshold; > + } > } > > ...makes the issue disappear on the same workload running for 30+ minutes (and no Full GCs!): > http://cr.openjdk.java.net/~shade/shenandoah/wip-tlab-race/patched-1.png > > Thoughts? > > Thanks, > -Aleksey > > > Sounds reasonable. From cflood at redhat.com Wed Sep 20 12:09:44 2017 From: cflood at redhat.com (Christine Flood) Date: Wed, 20 Sep 2017 08:09:44 -0400 Subject: RFC: TLAB allocation and garbage-first policy In-Reply-To: <84f87bdd-6fb1-864d-a617-4220856c123a@kennke.org> References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <84f87bdd-6fb1-864d-a617-4220856c123a@kennke.org> Message-ID: Changing our heuristics to compacting mostly empty regions to solve a one-of sparse region due to a race condition doesn't make sense to me. The common case would be compacting a bunch of live data from a bunch of usable regions for no reason. Christine On Wed, Sep 20, 2017 at 7:04 AM, Roman Kennke wrote: > Am 20.09.2017 um 12:10 schrieb Aleksey Shipilev: > >> Hi, >> >> We do have a problem on the edge of TLAB allocation machinery and >> garbage-first collection policy. >> Current TLAB machinery in Hotspot polls the GC about the next TLAB size >> with >> CollectedHeap::unsafe_max_tlab_alloc. The trouble is that call is >> inherently racy, and is expected >> to provide the best guess that GC can do under the circumstances. >> >> The race unfolds like this: >> 1. GC looks around and realizes there is a fully-empty >> region in the allocation list, >> and happily reports $region_size to VM >> 2. Another allocation comes and does the >> smaller-than-region-size allocation in that >> fully-empty region. >> 3. Resumes, tries to allocate full TLAB, but the region that >> was deemed empty at step 1 >> is fragmented already, so it retires the region from the freeset (it does >> so to optimize allocation >> path), and proceeds to allocate at the one past that. >> >> End result: we have the fragmented region that gets immediately retired >> and becomes not available >> for any further allocations. Granted, the actual issue is the raciness in >> TLAB machinery. >> Unfortunately, it would be hard to fix without redoing CollectedHeap API. >> >> Now to the fun part about our collection policy. Our collector policy >> selects the regions by least >> garbage, where garbage = used - live. So, if you have the fragmented 16M >> region with used=128K, and >> live=128K, it is exactly 0K garbage -- the least probable candidate. So >> the region that become >> fragmented due to the race in TLAB machinery is also never considered for >> collection, because it is >> below the ShenandoahGarbageThreshold! >> >> This race further widens when we bias the TLAB and GCLAB allocations to >> different sides of the heap, >> and GCLABs take the most hit. You can clearly see the anomaly in >> Visualizer after 10+ minutes of >> LRUFragger run with 50 GB LDS on 100 GB heap (...and it drives into Full >> GC shortly afterwards, >> because free set got depleted due to fragmentation!): >> http://cr.openjdk.java.net/~shade/shenandoah/wip-tlab-race/ >> baseline-1.png >> >> Therefore, I propose we choose the regions by *live size*, not by >> *garbage*, so that we can recover >> by collecting (and evacuating) the regions with low live, not exactly >> with high garbage. This should >> help to recuperate from TLAB losses better. For full regions, both >> metrics yield the same result. >> For half-full regions, we would have a chance to compact them into >> mostly-full, leaving more >> fully-empty regions around. >> >> I mused about this on IRC yesterday, and today I see G1 does the same, see >> CollectionSetChooser::should_add: >> >> bool should_add(HeapRegion* hr) { >> assert(hr->is_marked(), "pre-condition"); >> assert(!hr->is_young(), "should never consider young regions"); >> return !hr->is_pinned() && >> hr->live_bytes() < _region_live_threshold_bytes; // <----- >> here >> } >> >> ...and probably with the same rationale? Found these bugs: >> https://bugs.openjdk.java.net/browse/JDK-7132029 >> https://bugs.openjdk.java.net/browse/JDK-7146242 >> >> Prototype fix: >> >> virtual bool region_in_collection_set(ShenandoahHeapRegion* r, size_t >> immediate_garbage) { >> size_t threshold = ShenandoahHeapRegion::region_size_bytes() * >> ShenandoahGarbageThreshold / 100; >> - return r->garbage() > threshold; >> + if (UseNewCode) { >> + return (ShenandoahHeapRegion::region_size_bytes() - >> r->get_live_data_bytes()) > threshold; >> + } else { >> + return r->garbage() > threshold; >> + } >> } >> >> ...makes the issue disappear on the same workload running for 30+ minutes >> (and no Full GCs!): >> http://cr.openjdk.java.net/~shade/shenandoah/wip-tlab-race/ >> patched-1.png >> >> Thoughts? >> >> Thanks, >> -Aleksey >> >> >> >> Sounds reasonable. > > From shade at redhat.com Wed Sep 20 12:16:08 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Sep 2017 14:16:08 +0200 Subject: RFC: TLAB allocation and garbage-first policy In-Reply-To: References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <84f87bdd-6fb1-864d-a617-4220856c123a@kennke.org> Message-ID: On 09/20/2017 02:09 PM, Christine Flood wrote: > Changing our heuristics to compacting mostly empty regions to solve a one-of sparse region due to a > race condition doesn't make sense to me. The common case would be compacting a bunch of live data > from a bunch of usable regions for no reason. Problem is, this case is not really one-off (i.e. the race is rather frequent and its effects linger indefinitely), and those regions are not really usable (because regions get retired when allocations fail in them). The whole thing leads to fragmentation that kills the concurrent GC. Quote: "You can clearly see the anomaly in Visualizer after 10+ minutes of LRUFragger run with 50 GB LDS on 100 GB heap (...and it drives into Full GC shortly afterwards, because free set got depleted due to fragmentation!): http://cr.openjdk.java.net/~shade/shenandoah/wip-tlab-race/baseline-1.png" I think our job here is to recuperate from the loss in a pragmatic way, and collecting based on live data seems to be pragmatic. It is also in line with what G1 is doing. It also benefits humongous allocs because it defrags the heap more aggressively. But I would be equally happy to see another way out of this. What would you suggest? -Aleksey From zgu at redhat.com Wed Sep 20 12:18:11 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 20 Sep 2017 08:18:11 -0400 Subject: RFC: TLAB allocation and garbage-first policy In-Reply-To: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> Message-ID: <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> > Now to the fun part about our collection policy. Our collector policy selects the regions by least > garbage, where garbage = used - live. So, if you have the fragmented 16M region with used=128K, and > live=128K, it is exactly 0K garbage -- the least probable candidate. So the region that become > fragmented due to the race in TLAB machinery is also never considered for collection, because it is > below the ShenandoahGarbageThreshold! Should this region be added back to free set after GC and be reused? -Zhengyu > > This race further widens when we bias the TLAB and GCLAB allocations to different sides of the heap, > and GCLABs take the most hit. You can clearly see the anomaly in Visualizer after 10+ minutes of > LRUFragger run with 50 GB LDS on 100 GB heap (...and it drives into Full GC shortly afterwards, > because free set got depleted due to fragmentation!): > http://cr.openjdk.java.net/~shade/shenandoah/wip-tlab-race/baseline-1.png > > Therefore, I propose we choose the regions by *live size*, not by *garbage*, so that we can recover > by collecting (and evacuating) the regions with low live, not exactly with high garbage. This should > help to recuperate from TLAB losses better. For full regions, both metrics yield the same result. > For half-full regions, we would have a chance to compact them into mostly-full, leaving more > fully-empty regions around. > > I mused about this on IRC yesterday, and today I see G1 does the same, see > CollectionSetChooser::should_add: > > bool should_add(HeapRegion* hr) { > assert(hr->is_marked(), "pre-condition"); > assert(!hr->is_young(), "should never consider young regions"); > return !hr->is_pinned() && > hr->live_bytes() < _region_live_threshold_bytes; // <----- here > } > > ...and probably with the same rationale? Found these bugs: > https://bugs.openjdk.java.net/browse/JDK-7132029 > https://bugs.openjdk.java.net/browse/JDK-7146242 > > Prototype fix: > > virtual bool region_in_collection_set(ShenandoahHeapRegion* r, size_t immediate_garbage) { > size_t threshold = ShenandoahHeapRegion::region_size_bytes() * ShenandoahGarbageThreshold / 100; > - return r->garbage() > threshold; > + if (UseNewCode) { > + return (ShenandoahHeapRegion::region_size_bytes() - r->get_live_data_bytes()) > threshold; > + } else { > + return r->garbage() > threshold; > + } > } > > ...makes the issue disappear on the same workload running for 30+ minutes (and no Full GCs!): > http://cr.openjdk.java.net/~shade/shenandoah/wip-tlab-race/patched-1.png > > Thoughts? > > Thanks, > -Aleksey > > From shade at redhat.com Wed Sep 20 12:28:39 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Sep 2017 14:28:39 +0200 Subject: RFC: TLAB allocation and garbage-first policy In-Reply-To: <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> Message-ID: <5fdbde05-0fb7-665d-4682-b01ba9910963@redhat.com> On 09/20/2017 02:18 PM, Zhengyu Gu wrote: >> Now to the fun part about our collection policy. Our collector policy selects the regions by least >> garbage, where garbage = used - live. So, if you have the fragmented 16M region with used=128K, and >> live=128K, it is exactly 0K garbage -- the least probable candidate. So the region that become >> fragmented due to the race in TLAB machinery is also never considered for collection, because it is >> below the ShenandoahGarbageThreshold! > > Should this region be added back to free set after GC and be reused? In theory, yes -- and this is why it does not crash and burn immediately. In practice, it such regions seem to get retired due to the same race: unsafe_tlab_alloc says we can fit the TLAB in region #N, we blink, we try to fit the TLAB in region #N+1, which happens to be half-full, we fail, we retire the region. Compacting to get more fully-empty regions reduces the probability of that happening, because it reduces the number of half-full regions after the cycle. -Aleksey From zgu at redhat.com Wed Sep 20 12:43:16 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 20 Sep 2017 08:43:16 -0400 Subject: RFC: TLAB allocation and garbage-first policy In-Reply-To: <5fdbde05-0fb7-665d-4682-b01ba9910963@redhat.com> References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> <5fdbde05-0fb7-665d-4682-b01ba9910963@redhat.com> Message-ID: >> >> Should this region be added back to free set after GC and be reused? > > In theory, yes -- and this is why it does not crash and burn immediately. In practice, it such > regions seem to get retired due to the same race: unsafe_tlab_alloc says we can fit the TLAB in > region #N, we blink, we try to fit the TLAB in region #N+1, which happens to be half-full, we fail, > we retire the region. > Yes, I see this problem also, but I think it is TLAB issue. I think TLAB allocation should accept a rang of sizes, instead of fixed size. -Zhengyu > Compacting to get more fully-empty regions reduces the probability of that happening, because it > reduces the number of half-full regions after the cycle. > > -Aleksey > From cflood at redhat.com Wed Sep 20 12:44:02 2017 From: cflood at redhat.com (Christine Flood) Date: Wed, 20 Sep 2017 08:44:02 -0400 Subject: RFC: TLAB allocation and garbage-first policy In-Reply-To: <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> Message-ID: I can think of several solutions. One would be to cap the max tlab size as we discussed yesterday. Having a tlab be an entire region has some nice performance characteristics but isn't really necessary, nor is it in the spirit of tlabs. Another potential solution would be to treat these regions specially. When a tlab allocation fails in a region we could fill that particular region with a filler array. Therefore we now have garbage. This differs from your solution in that regular regions that are perfectly happy with normal sized tlab spaces available aren't going to get prematurely compacted. One common measure of GC performance is bytes copied vs bytes reclaimed. I will grant you that in your particular situation your solution looks attractive, but in a myriad of other situations you are actually pessimizing GC performance in at least one metric. Christine On Wed, Sep 20, 2017 at 8:18 AM, Zhengyu Gu wrote: > > Now to the fun part about our collection policy. Our collector policy >> selects the regions by least >> garbage, where garbage = used - live. So, if you have the fragmented 16M >> region with used=128K, and >> live=128K, it is exactly 0K garbage -- the least probable candidate. So >> the region that become >> fragmented due to the race in TLAB machinery is also never considered for >> collection, because it is >> below the ShenandoahGarbageThreshold! >> > > Should this region be added back to free set after GC and be reused? > > -Zhengyu > > > >> This race further widens when we bias the TLAB and GCLAB allocations to >> different sides of the heap, >> and GCLABs take the most hit. You can clearly see the anomaly in >> Visualizer after 10+ minutes of >> LRUFragger run with 50 GB LDS on 100 GB heap (...and it drives into Full >> GC shortly afterwards, >> because free set got depleted due to fragmentation!): >> http://cr.openjdk.java.net/~shade/shenandoah/wip-tlab-race/ >> baseline-1.png >> >> Therefore, I propose we choose the regions by *live size*, not by >> *garbage*, so that we can recover >> by collecting (and evacuating) the regions with low live, not exactly >> with high garbage. This should >> help to recuperate from TLAB losses better. For full regions, both >> metrics yield the same result. >> For half-full regions, we would have a chance to compact them into >> mostly-full, leaving more >> fully-empty regions around. >> >> I mused about this on IRC yesterday, and today I see G1 does the same, see >> CollectionSetChooser::should_add: >> >> bool should_add(HeapRegion* hr) { >> assert(hr->is_marked(), "pre-condition"); >> assert(!hr->is_young(), "should never consider young regions"); >> return !hr->is_pinned() && >> hr->live_bytes() < _region_live_threshold_bytes; // <----- >> here >> } >> >> ...and probably with the same rationale? Found these bugs: >> https://bugs.openjdk.java.net/browse/JDK-7132029 >> https://bugs.openjdk.java.net/browse/JDK-7146242 >> >> Prototype fix: >> >> virtual bool region_in_collection_set(ShenandoahHeapRegion* r, size_t >> immediate_garbage) { >> size_t threshold = ShenandoahHeapRegion::region_size_bytes() * >> ShenandoahGarbageThreshold / 100; >> - return r->garbage() > threshold; >> + if (UseNewCode) { >> + return (ShenandoahHeapRegion::region_size_bytes() - >> r->get_live_data_bytes()) > threshold; >> + } else { >> + return r->garbage() > threshold; >> + } >> } >> >> ...makes the issue disappear on the same workload running for 30+ minutes >> (and no Full GCs!): >> http://cr.openjdk.java.net/~shade/shenandoah/wip-tlab-race/ >> patched-1.png >> >> Thoughts? >> >> Thanks, >> -Aleksey >> >> >> From shade at redhat.com Wed Sep 20 12:45:25 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Sep 2017 14:45:25 +0200 Subject: RFC: TLAB allocation and garbage-first policy In-Reply-To: References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> <5fdbde05-0fb7-665d-4682-b01ba9910963@redhat.com> Message-ID: On 09/20/2017 02:43 PM, Zhengyu Gu wrote: >>> >>> Should this region be added back to free set after GC and be reused? >> >> In theory, yes -- and this is why it does not crash and burn immediately. In practice, it such >> regions seem to get retired due to the same race: unsafe_tlab_alloc says we can fit the TLAB in >> region #N, we blink, we try to fit the TLAB in region #N+1, which happens to be half-full, we fail, >> we retire the region. >> > Yes, I see this problem also, but I think it is TLAB issue. I think TLAB allocation should accept a > rang of sizes, instead of fixed size. No doubts about that: this is the race in TLAB machinery. However, there seem to be no way to fix this in TLAB, because it is a shared code used by all collectors, and changes there significantly increase our upstream exposure. -Aleksey From shade at redhat.com Wed Sep 20 12:58:59 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Sep 2017 14:58:59 +0200 Subject: RFC: TLAB allocation and garbage-first policy In-Reply-To: References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> Message-ID: On 09/20/2017 02:44 PM, Christine Flood wrote: > I can think of several solutions. One would be to cap the max tlab size as we discussed yesterday. > Having a tlab be an entire region has some nice performance characteristics but isn't really > necessary, nor is it in the spirit of tlabs. This seems to work badly for smaller heaps? E.g. we have 512K regions in 4G configuration. Reducing the TLAB size to, say, 1/10-th of region size makes it only 50K, which is too low? We also do not want to hit the slowpath allocation (i.e. TLAB refill here) for every 50K allocated, no? It also seems inconsistent with the previously said goal: (paraphrasing) we try not to make the allocators pay for our sins. Capping the TLABs seems to be doing exactly that? > Another potential solution would be to treat these regions specially. When a tlab allocation fails > in a region we could fill that particular region with a filler array. Therefore we now have > garbage. This differs from your solution in that regular regions that are perfectly happy with > normal sized tlab spaces available aren't going to get prematurely compacted. Aha, sounds interesting. So the only thing that does seem to help is the half-full regions we never tried to allocate in, right? Otherwise it is the same as looking at "live" for cset selection. -Aleksey From shade at redhat.com Wed Sep 20 13:30:54 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Sep 2017 15:30:54 +0200 Subject: RFC: TLAB allocation and garbage-first policy In-Reply-To: References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> Message-ID: On 09/20/2017 02:58 PM, Aleksey Shipilev wrote: > On 09/20/2017 02:44 PM, Christine Flood wrote: >> Another potential solution would be to treat these regions specially. When a tlab allocation fails >> in a region we could fill that particular region with a filler array. Therefore we now have >> garbage. This differs from your solution in that regular regions that are perfectly happy with >> normal sized tlab spaces available aren't going to get prematurely compacted. > > Aha, sounds interesting. So the only thing that does seem to help is the half-full regions we never > tried to allocate in, right? Otherwise it is the same as looking at "live" for cset selection. Dang. Now that I try to implement it, it does not seem to work better, because the filler object has quite a chance to be allocated after TAMS, and thus be treated as implicitly live, and then evac'd. The kernel idea seems to inflate "used", but we can't really do that without the actual allocation (whether with filler or not), because "used" is $top-$bottom, and $top is the object iteration boundary within the region. That is, if we need to inflate "used", we have to move "top", and then we have to have some object in there, and then it can be live. Seems like "pick your poison" situation here: either allow copying some filler objects (that got a chance to be allocated after TAMS), or allow compacting some non-fully-used regions (that were never fully retired because allocation did not touch them). I'd say that since we try to take most of the heap before the cycle starts, most of the regions would get tried to be allocated in, and so the risk of excess work is lower than copying fillers. Which gets me back to "count live during cset construction". -Aleksey From cflood at redhat.com Wed Sep 20 13:53:42 2017 From: cflood at redhat.com (Christine Flood) Date: Wed, 20 Sep 2017 09:53:42 -0400 Subject: RFC: TLAB allocation and garbage-first policy In-Reply-To: References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> Message-ID: On Wed, Sep 20, 2017 at 8:58 AM, Aleksey Shipilev wrote: > On 09/20/2017 02:44 PM, Christine Flood wrote: > > I can think of several solutions. One would be to cap the max tlab size > as we discussed yesterday. > > Having a tlab be an entire region has some nice performance > characteristics but isn't really > > necessary, nor is it in the spirit of tlabs. > > This seems to work badly for smaller heaps? E.g. we have 512K regions in > 4G configuration. Reducing > the TLAB size to, say, 1/10-th of region size makes it only 50K, which is > too low? We also do not > want to hit the slowpath allocation (i.e. TLAB refill here) for every 50K > allocated, no? > The original TLabs were something like 4K if I remember correctly. Yes, there is a balancing act with not making them too small. However what's the point of having TLABS if they are region sized, why not just assign a region/thread? Perhaps there's a middle ground of say 1/4 of a region which will leave you in a better situation than you are now. It also seems inconsistent with the previously said goal: (paraphrasing) we > try not to make the > allocators pay for our sins. Capping the TLABs seems to be doing exactly > that? > > > Another potential solution would be to treat these regions specially. > When a tlab allocation fails > > in a region we could fill that particular region with a filler array. > Therefore we now have > > garbage. This differs from your solution in that regular regions that > are perfectly happy with > > normal sized tlab spaces available aren't going to get prematurely > compacted. > > Aha, sounds interesting. So the only thing that does seem to help is the > half-full regions we never > tried to allocate in, right? Otherwise it is the same as looking at "live" > for cset selection. > > What this does is not confuse our metrics for expediency. We agreed earlier that in a single region case copying the live data from one region to another doesn't gain us anything. I would argue that if I had to choose between compacting 10 fragmented regions or 10 compacted but not large enough for a tlab regions we would be better off compacting the fragmented regions because that would leave us with more contiguous free space. Your proposed metric doesn't distinguish between the two. I suppose there is a place for what you want. If all I have left are compacted but not quite spacious enough regions I would prefer to add them to the cset instead of falling back on a full gc. Perhaps there's a heuristic that satisfies both constraints. -Aleksey > > From shade at redhat.com Wed Sep 20 14:49:56 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Sep 2017 16:49:56 +0200 Subject: RFC: TLAB allocation and garbage-first policy In-Reply-To: References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> Message-ID: <7b8d2176-de47-7229-b9e0-6bc44c5b31a9@redhat.com> On 09/20/2017 03:53 PM, Christine Flood wrote: > On Wed, Sep 20, 2017 at 8:58 AM, Aleksey Shipilev > wrote: > The original TLabs were something like 4K if I remember correctly. Yes, there is a balancing act > with not making them too small. However what's the point of having TLABS if they are region sized, > why not just assign a region/thread? For the same reason adaptive TLAB sizing exists: do not waste space. In this mechanics, you can't have more threads than regions, even if most of the threads are dormant. > Perhaps there's a middle ground of say 1/4 of a region which will leave you in a better situation than you are now. Maybe, let's make it our fallback plan: if everything else fails, we can trim down the TLABs. > > Another potential solution would be to treat these regions specially. When a tlab allocation fails > > in a region we could fill that particular region with a filler array. Therefore we now have > > garbage. This differs from your solution in that regular regions that are perfectly happy with > > normal sized tlab spaces available aren't going to get prematurely compacted. > > Aha, sounds interesting. So the only thing that does seem to help is the half-full regions we never > tried to allocate in, right? Otherwise it is the same as looking at "live" for cset selection. > > What this does is not confuse our metrics for expediency. We agreed earlier that in a single region > case copying the live data from one region to another doesn't gain us anything. I would argue that > if I had to choose between compacting 10 fragmented regions or 10 compacted but not large enough for > a tlab regions we would be better off compacting the fragmented regions because that would leave us > with more contiguous free space. Your proposed metric doesn't distinguish between the two. > > I suppose there is a place for what you want. If all I have left are compacted but not quite > spacious enough regions I would prefer to add them to the cset instead of falling back on a full > gc. Perhaps there's a heuristic that satisfies both constraints. The example of the single fragmented region, while valid in itself, loses sight of bigger picture, I think. It seems to me that it *only* matters when collection set contains that one fragmented region. If it contains more than one fragmented region, then it starts to make sense to compact them together and free up one of regions. If cset contains additional full regions, then the impact of "wasteful" copy for that single fragmented region is very low. With that in sight, how frequent it is to have a single fragmented region in the collection set, compared to other cases? I would rather have the static code that deals with 99.99% of the cases, and never walks into bad feedback loop, than having another heuristics for 0.01% of the cases and fails with unforeseen feedbacks. Doing the heuristics feels like what you describe as, " I will grant you that in your particular situation your solution looks attractive, but in a myriad of other situations you are actually pessimizing GC performance in at least one metric". Thanks, -Aleksey From cflood at redhat.com Wed Sep 20 16:18:31 2017 From: cflood at redhat.com (Christine Flood) Date: Wed, 20 Sep 2017 12:18:31 -0400 Subject: Fwd: RFC: TLAB allocation and garbage-first policy In-Reply-To: References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> <7b8d2176-de47-7229-b9e0-6bc44c5b31a9@redhat.com> Message-ID: ---------- Forwarded message ---------- From: Christine Flood Date: Wed, Sep 20, 2017 at 12:00 PM Subject: Re: RFC: TLAB allocation and garbage-first policy To: Aleksey Shipilev On Wed, Sep 20, 2017 at 10:49 AM, Aleksey Shipilev wrote: > On 09/20/2017 03:53 PM, Christine Flood wrote: > > On Wed, Sep 20, 2017 at 8:58 AM, Aleksey Shipilev > wrote: > > The original TLabs were something like 4K if I remember correctly. Yes, > there is a balancing act > > with not making them too small. However what's the point of having > TLABS if they are region sized, > > why not just assign a region/thread? > > For the same reason adaptive TLAB sizing exists: do not waste space. In > this mechanics, you can't > have more threads than regions, even if most of the threads are dormant. > > > Perhaps there's a middle ground of say 1/4 of a region which will leave > you in a better situation than you are now. > > Maybe, let's make it our fallback plan: if everything else fails, we can > trim down the TLABs. > > > > > Another potential solution would be to treat these regions > specially. When a tlab allocation fails > > > in a region we could fill that particular region with a filler > array. Therefore we now have > > > garbage. This differs from your solution in that regular regions > that are perfectly happy with > > > normal sized tlab spaces available aren't going to get prematurely > compacted. > > > > Aha, sounds interesting. So the only thing that does seem to help is > the half-full regions we never > > tried to allocate in, right? Otherwise it is the same as looking at > "live" for cset selection. > > > > What this does is not confuse our metrics for expediency. We agreed > earlier that in a single region > > case copying the live data from one region to another doesn't gain us > anything. I would argue that > > if I had to choose between compacting 10 fragmented regions or 10 > compacted but not large enough for > > a tlab regions we would be better off compacting the fragmented regions > because that would leave us > > with more contiguous free space. Your proposed metric doesn't > distinguish between the two. > > > > I suppose there is a place for what you want. If all I have left are > compacted but not quite > > spacious enough regions I would prefer to add them to the cset instead > of falling back on a full > > gc. Perhaps there's a heuristic that satisfies both constraints. > > The example of the single fragmented region, while valid in itself, loses > sight of bigger picture, I > think. It seems to me that it *only* matters when collection set contains > that one fragmented > region. If it contains more than one fragmented region, then it starts to > make sense to compact them > together and free up one of regions. If cset contains additional full > regions, then the impact of > "wasteful" copy for that single fragmented region is very low. > > With that in sight, how frequent it is to have a single fragmented region > in the collection set, > compared to other cases? I would rather have the static code that deals > with 99.99% of the cases, > and never walks into bad feedback loop, than having another heuristics for > 0.01% of the cases and > fails with unforeseen feedbacks. Doing the heuristics feels like what you > describe as, " I will > grant you that in your particular situation your solution looks > attractive, but in a myriad of other > situations you are actually pessimizing GC performance in at least one > metric". > How frequent is it that we end up with 10% full regions which can't fit a tlab? You are proposing changing a metric which will no longer distinguish between regions which are 100% full with 10% live data and regions which are 10% full with 10% live data. I would argue that those two situations should be treated differently most of the time. In fact in the situations where we don't hit this tlab bogosity race condition there is no reason to copy that 10% full 10% live data. I suspect your proposed metric change would result in most current allocation regions being included in the collection set. This results not just in unnecessary copying work, but presumably more triggered write barriers because these most recently allocated objects are presumably also more likely to be accessed in the near future. Christine From shade at redhat.com Wed Sep 20 16:31:57 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Sep 2017 18:31:57 +0200 Subject: Fwd: RFC: TLAB allocation and garbage-first policy In-Reply-To: References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> <7b8d2176-de47-7229-b9e0-6bc44c5b31a9@redhat.com> Message-ID: On 09/20/2017 06:18 PM, Christine Flood wrote: > How frequent is it that we end up with 10% full regions which can't fit a > tlab? Frequent enough to fragment the freeset and drive LRUFragger into Full GC, alas. > You are proposing changing a metric which will no longer distinguish > between regions which are 100% full with 10% live data and regions which > are 10% full with 10% live data. I would argue that those two situations > should be treated differently most of the time. In fact in the situations > where we don't hit this tlab bogosity race condition there is no reason to > copy that 10% full 10% live data. Yes, but the race does happen, and thus we have to choose between several evils. For a collector that optimizes raw copying keeping the region with 10%-full/10%-live is of course beneficial. For a collector that has to deal with fragmentation too, this becomes much grayer area. My argument was not about that copying having no cost, it was about that copying having the affordable cost in the grand scheme of things. And the benefits with having less fragmented heap outweigh that cost. Your argument seems to imply that G1 does it wrong when it considers "live" for cset selection, right? This seems to be even more important for G1, because it has to copy during the pause. > I suspect your proposed metric change would result in most current > allocation regions being included in the collection set. This results not > just in unnecessary copying work, but presumably more triggered write > barriers because these most recently allocated objects are presumably also > more likely to be accessed in the near future. Ok, that's compelling. But the filler object solution also falls victim to this: it will also inflate garbage in recently allocated and recently retired region, and it will get considered in the collection set. All we are left with is trimming the TLABs. Thanks, -Aleksey From cflood at redhat.com Wed Sep 20 16:37:54 2017 From: cflood at redhat.com (Christine Flood) Date: Wed, 20 Sep 2017 12:37:54 -0400 Subject: Fwd: RFC: TLAB allocation and garbage-first policy In-Reply-To: References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> <7b8d2176-de47-7229-b9e0-6bc44c5b31a9@redhat.com> Message-ID: G1 will trigger a young generation gc when it's designated young regions are full. We trigger a GC when we get to a certain allocation threshold which doesn't really imply anything about how full our current allocation regions are. Again there is nothing preventing us from writing a heuristic that triggers when we fill up a certain number of regions, but that isn't what we currently do. Christine On Wed, Sep 20, 2017 at 12:31 PM, Aleksey Shipilev wrote: > On 09/20/2017 06:18 PM, Christine Flood wrote: > > How frequent is it that we end up with 10% full regions which can't fit a > > tlab? > > Frequent enough to fragment the freeset and drive LRUFragger into Full GC, > alas. > > > You are proposing changing a metric which will no longer distinguish > > between regions which are 100% full with 10% live data and regions which > > are 10% full with 10% live data. I would argue that those two situations > > should be treated differently most of the time. In fact in the > situations > > where we don't hit this tlab bogosity race condition there is no reason > to > > copy that 10% full 10% live data. > > Yes, but the race does happen, and thus we have to choose between several > evils. For a collector > that optimizes raw copying keeping the region with 10%-full/10%-live is of > course beneficial. For a > collector that has to deal with fragmentation too, this becomes much > grayer area. My argument was > not about that copying having no cost, it was about that copying having > the affordable cost in the > grand scheme of things. And the benefits with having less fragmented heap > outweigh that cost. > > Your argument seems to imply that G1 does it wrong when it considers > "live" for cset selection, > right? This seems to be even more important for G1, because it has to copy > during the pause. > > > I suspect your proposed metric change would result in most current > > allocation regions being included in the collection set. This results > not > > just in unnecessary copying work, but presumably more triggered write > > barriers because these most recently allocated objects are presumably > also > > more likely to be accessed in the near future. > > Ok, that's compelling. But the filler object solution also falls victim to > this: it will also > inflate garbage in recently allocated and recently retired region, and it > will get considered in the > collection set. > > All we are left with is trimming the TLABs. > > Thanks, > -Aleksey > > From shade at redhat.com Wed Sep 20 16:48:57 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Sep 2017 18:48:57 +0200 Subject: Fwd: RFC: TLAB allocation and garbage-first policy In-Reply-To: References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> <7b8d2176-de47-7229-b9e0-6bc44c5b31a9@redhat.com> Message-ID: On 09/20/2017 06:37 PM, Christine Flood wrote: > G1 will trigger a young generation gc when it's designated young regions are full. I was talking about mixed collections though, see G1MixedGCLiveThresholdPercent and CollectionSetChooser::should_add. > We trigger a GC when we get to a certain allocation threshold which doesn't really imply anything about how full our current allocation regions are. That is not entirely true. Our allocation code walks through freeset linearly, which means that what we have left behind as "used" in the freeset includes only fully-allocated and racy-fragmented-retired regions... > Again there is nothing preventing us from writing a heuristic that triggers when we fill up a > certain number of regions, but that isn't what we currently do. ...so the heuristics that account for ShenandoahAllocationThreshold (which are most of them), already do that. So the difference against G1 is still murky for me. I am experimenting with TLAB trimming. -Aleksey From rkennke at redhat.com Wed Sep 20 17:45:45 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 20 Sep 2017 19:45:45 +0200 Subject: Fwd: RFC: TLAB allocation and garbage-first policy In-Reply-To: References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> <7b8d2176-de47-7229-b9e0-6bc44c5b31a9@redhat.com> Message-ID: <6dcef184-ac71-d9af-0b65-bb94b0a570ee@redhat.com> Does Aleksey's proposed change lead to regressions in other workloads? If it improves some workloads, and doesn't regress others, I'm for it. Can the proposed change be done in a new/other experimental heuristic? Roman > On 09/20/2017 06:37 PM, Christine Flood wrote: >> G1 will trigger a young generation gc when it's designated young regions are full. > I was talking about mixed collections though, see G1MixedGCLiveThresholdPercent and > CollectionSetChooser::should_add. > >> We trigger a GC when we get to a certain allocation threshold which doesn't really imply anything about how full our current allocation regions are. > That is not entirely true. Our allocation code walks through freeset linearly, which means that what > we have left behind as "used" in the freeset includes only fully-allocated and > racy-fragmented-retired regions... > >> Again there is nothing preventing us from writing a heuristic that triggers when we fill up a >> certain number of regions, but that isn't what we currently do. > ...so the heuristics that account for ShenandoahAllocationThreshold (which are most of them), > already do that. > > So the difference against G1 is still murky for me. I am experimenting with TLAB trimming. > > -Aleksey > From shade at redhat.com Wed Sep 20 19:17:16 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Sep 2017 21:17:16 +0200 Subject: RFR: Trim the TLAB sizes to avoid wasteful retirement under TLAB races Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/tlab-race-trim/webrev.01/ This implements TLAB trimming to avoid wasteful retirement. The rationale is given in the comment right in the code. It does not seem to make allocation significantly more costly. To make it less overheady, changed the counter update code to be called on new region issuance, not on TLAB issuance. Testing: hotspot_gc_shenandoah, allocation benchmarks Thanks, -Aleksey From shade at redhat.com Wed Sep 20 19:18:30 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 Sep 2017 21:18:30 +0200 Subject: Fwd: RFC: TLAB allocation and garbage-first policy In-Reply-To: References: <76e92c92-d374-f49b-9b76-3d77e1a0ce46@redhat.com> <3ab489e8-f8ef-0b7c-70da-24bb580e46b1@redhat.com> <7b8d2176-de47-7229-b9e0-6bc44c5b31a9@redhat.com> Message-ID: On 09/20/2017 06:48 PM, Aleksey Shipilev wrote: > I am experimenting with TLAB trimming. This seems to work well to avoid fragmentation in LRUFragger: http://mail.openjdk.java.net/pipermail/shenandoah-dev/2017-September/003707.html Thanks, -Aleksey From zgu at redhat.com Wed Sep 20 21:27:44 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 20 Sep 2017 17:27:44 -0400 Subject: RFR: Dynamic worker refactoring Message-ID: <8bad3ede-76a9-12b2-afd8-29ec5ef02476@redhat.com> This patch refactoring dynamic GC worker code out of ShenandoahCollectorPolicy, which is overcrowd. My tests never show any benefits of dynamic workers so far, and our customized code does not seem to outperform shared implementation, so lets revert back to shared implementation. Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/dwg_refactor/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu From shade at redhat.com Thu Sep 21 07:03:35 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Sep 2017 09:03:35 +0200 Subject: RFR: Dynamic worker refactoring In-Reply-To: <8bad3ede-76a9-12b2-afd8-29ec5ef02476@redhat.com> References: <8bad3ede-76a9-12b2-afd8-29ec5ef02476@redhat.com> Message-ID: <45c62db2-9576-22c9-80b4-2ef0b8f70025@redhat.com> On 09/20/2017 11:27 PM, Zhengyu Gu wrote: > This patch refactoring dynamic GC worker code out of ShenandoahCollectorPolicy, which is overcrowd. > > My tests never show any benefits of dynamic workers so far, and our customized code does not seem to > outperform shared implementation, so lets revert back to shared implementation. > > Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/dwg_refactor/webrev.00/ Looks very nice. *) Looking at shenandoahWorkerPolicy.hpp, it would seem the calc_worker stuff for update-refs is missing? Should be *_for_conc_update_refs(), *_for_final_update_refs()? Init update-refs does not require workers, IIRC. *) Stylistic: maybe _prev_workers_for_marking is too excessive for the name? Suggestion: _prev_marking. *) Stylistic: indenting for arguments seems better readable like this: _prev_marking = AdaptiveSizePolicy::calc_active_workers(ParallelGCThreads, active_workers, Threads::number_of_non_daemon_threads()); *) Stylistic: ternary statements should probably get farther indenting, like this (or maybe after shortening the variable names, they are fine with single line?): uint active_workers = (_prev_workers_for_conc_marking == 0) ? ConcGCThreads : _prev_workers_for_conc_marking; *) Typo: "calculate" 85 // Calcuate workers for Stop-the-world partial GC Thanks, -Aleksey From shade at redhat.com Thu Sep 21 07:31:25 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Sep 2017 09:31:25 +0200 Subject: RFR: Trim the TLAB sizes to avoid wasteful retirement under TLAB races In-Reply-To: References: Message-ID: <8f5de139-4db3-c23d-423f-fb9c43db897d@redhat.com> On 09/20/2017 09:17 PM, Aleksey Shipilev wrote: > http://cr.openjdk.java.net/~shade/shenandoah/tlab-race-trim/webrev.01/ > > This implements TLAB trimming to avoid wasteful retirement. The rationale is given in the comment > right in the code. It does not seem to make allocation significantly more costly. To make it less > overheady, changed the counter update code to be called on new region issuance, not on TLAB issuance. Added more discussion: http://cr.openjdk.java.net/~shade/shenandoah/tlab-race-trim/webrev.02/ -Aleksey From rkennke at redhat.com Thu Sep 21 10:15:20 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 Sep 2017 12:15:20 +0200 Subject: RFR: Trim the TLAB sizes to avoid wasteful retirement under TLAB races In-Reply-To: <8f5de139-4db3-c23d-423f-fb9c43db897d@redhat.com> References: <8f5de139-4db3-c23d-423f-fb9c43db897d@redhat.com> Message-ID: <572486cd-cff2-42d4-da59-30c26eefaaae@redhat.com> Am 21.09.2017 um 09:31 schrieb Aleksey Shipilev: > On 09/20/2017 09:17 PM, Aleksey Shipilev wrote: >> http://cr.openjdk.java.net/~shade/shenandoah/tlab-race-trim/webrev.01/ >> >> This implements TLAB trimming to avoid wasteful retirement. The rationale is given in the comment >> right in the code. It does not seem to make allocation significantly more costly. To make it less >> overheady, changed the counter update code to be called on new region issuance, not on TLAB issuance. > Added more discussion: > http://cr.openjdk.java.net/~shade/shenandoah/tlab-race-trim/webrev.02/ > > -Aleksey > The number 8 is hardwired. Does this make sense? Should we allow this to be configured, if only for our own experimentation? Otherwise looks good to me. Roman From shade at redhat.com Thu Sep 21 10:19:33 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Sep 2017 12:19:33 +0200 Subject: RFR: Trim the TLAB sizes to avoid wasteful retirement under TLAB races In-Reply-To: <572486cd-cff2-42d4-da59-30c26eefaaae@redhat.com> References: <8f5de139-4db3-c23d-423f-fb9c43db897d@redhat.com> <572486cd-cff2-42d4-da59-30c26eefaaae@redhat.com> Message-ID: On 09/21/2017 12:15 PM, Roman Kennke wrote: > Am 21.09.2017 um 09:31 schrieb Aleksey Shipilev: >> On 09/20/2017 09:17 PM, Aleksey Shipilev wrote: >>> http://cr.openjdk.java.net/~shade/shenandoah/tlab-race-trim/webrev.01/ >>> >>> This implements TLAB trimming to avoid wasteful retirement. The rationale is given in the comment >>> right in the code. It does not seem to make allocation significantly more costly. To make it less >>> overheady, changed the counter update code to be called on new region issuance, not on TLAB >>> issuance. >> Added more discussion: >> http://cr.openjdk.java.net/~shade/shenandoah/tlab-race-trim/webrev.02/ >> >> -Aleksey >> > The number 8 is hardwired. Does this make sense? Should we allow this to be configured, if only for > our own experimentation? Well, it could be experimental -- which requires winding up argument checking logic and tests -- but I would really like to move on already :) We can turn it experimental if there is interest later, but I don't see any interest right now. -Aleksey From rkennke at redhat.com Thu Sep 21 10:37:05 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 Sep 2017 12:37:05 +0200 Subject: RFR: Trim the TLAB sizes to avoid wasteful retirement under TLAB races In-Reply-To: References: <8f5de139-4db3-c23d-423f-fb9c43db897d@redhat.com> <572486cd-cff2-42d4-da59-30c26eefaaae@redhat.com> Message-ID: <493568d5-cd1a-284c-344e-78d678535a77@redhat.com> Am 21.09.2017 um 12:19 schrieb Aleksey Shipilev: > On 09/21/2017 12:15 PM, Roman Kennke wrote: >> Am 21.09.2017 um 09:31 schrieb Aleksey Shipilev: >>> On 09/20/2017 09:17 PM, Aleksey Shipilev wrote: >>>> http://cr.openjdk.java.net/~shade/shenandoah/tlab-race-trim/webrev.01/ >>>> >>>> This implements TLAB trimming to avoid wasteful retirement. The rationale is given in the comment >>>> right in the code. It does not seem to make allocation significantly more costly. To make it less >>>> overheady, changed the counter update code to be called on new region issuance, not on TLAB >>>> issuance. >>> Added more discussion: >>> http://cr.openjdk.java.net/~shade/shenandoah/tlab-race-trim/webrev.02/ >>> >>> -Aleksey >>> >> The number 8 is hardwired. Does this make sense? Should we allow this to be configured, if only for >> our own experimentation? > Well, it could be experimental -- which requires winding up argument checking logic and tests -- but > I would really like to move on already :) We can turn it experimental if there is interest later, > but I don't see any interest right now. > > -Aleksey > Ok then From shade at redhat.com Thu Sep 21 11:42:42 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Sep 2017 13:42:42 +0200 Subject: RFR: Adaptive collection set selection in adaptive policy Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/heuristics-adaptive-cset/webrev.01/ This includes both the actual change to adaptive heuristics, and cleanups than make it less painful. Brief tour of changes: *) RegionGarbage -> RegionData renames, and using ShenandoahHeapRegion* directly. This helps to avoid heap region lookups in heuristics; *) Coarsening the cset selection method into the single call. This helps to avoid virtual call on every region, which makes it more optimizeable (important in leu of "/ 100" on hot path!). Coarse method makes advanced heuristics easier to write. *) Adaptive heuristics fixes two heuristics deficiencies than may select too small or too large collection set. See the comments in the source for discussion. These changes make LRUFragger survive on 85 GB LDS on 100 GB heap without Full GCs, which was never possible before. Example Visualizer drawings with early-ur=on and early-ur=adaptive: http://cr.openjdk.java.net/~shade/shenandoah/heuristics-adaptive-cset/85-on-100-URon.png http://cr.openjdk.java.net/~shade/shenandoah/heuristics-adaptive-cset/85-on-100-URadaptive.png (yes, we add more stuff to collection set, but the heap is overloaded, and we manage to avoid Full GCs with that) Testing: hotspot_gc_shenandoah Thanks, -Aleksey From rwestrel at redhat.com Thu Sep 21 12:31:08 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 21 Sep 2017 14:31:08 +0200 Subject: Add some missing UseShenandoahGC checks to 8u Message-ID: http://cr.openjdk.java.net/~roland/shenandoah/8u_useshenandoahgc/webrev.00/ This adds some missing UseShenandoahGC checks so the behaviour of C2 when shenandoah is disabled is less likely to differ from upstream 8u. Roland. From shade at redhat.com Thu Sep 21 12:45:34 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Sep 2017 14:45:34 +0200 Subject: Add some missing UseShenandoahGC checks to 8u In-Reply-To: References: Message-ID: <994ad036-7360-fdde-9876-567054b2c23f@redhat.com> On 09/21/2017 02:31 PM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/shenandoah/8u_useshenandoahgc/webrev.00/ > > This adds some missing UseShenandoahGC checks so the behaviour of C2 > when shenandoah is disabled is less likely to differ from upstream 8u. *) loopnode.cpp does not look right. With !UseShenandoahGC this predicate is always false? 3608 if (new_ctrl != least) { *) Not sure if guards around is_g1_wb_pre_call do the right thing against upstream. It seems that we have added some of them for Shenandoah only? Need to see the patch against the upstream later. Thanks, -Aleksey From rwestrel at redhat.com Thu Sep 21 12:52:42 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 21 Sep 2017 14:52:42 +0200 Subject: Add some missing UseShenandoahGC checks to 8u In-Reply-To: <994ad036-7360-fdde-9876-567054b2c23f@redhat.com> References: <994ad036-7360-fdde-9876-567054b2c23f@redhat.com> Message-ID: > *) loopnode.cpp does not look right. With !UseShenandoahGC this predicate is always false? > > 3608 if (new_ctrl != least) { upstream code for this is: if (ctrl_out && ctrl_out->is_CountedLoop() && least == ctrl_out->in(LoopNode::EntryControl)) { Node* least_dom = idom(least); if (get_loop(least_dom)->is_member(get_loop(least))) { least = least_dom; } } so to stick to upstream behaviour we only want the else line 3610 to have a chance to succeed. > *) Not sure if guards around is_g1_wb_pre_call do the right thing > against upstream. It seems that we have added some of them for > Shenandoah only? Need to see the patch against the upstream later. Yes, the checks for is_g1_wb_pre_call() is new code that doesn't exist upstream and that shouldn't trigger without Shenandoah but to be on the safe side, I added the tests for UseShenandoahGC. Roland. From shade at redhat.com Thu Sep 21 12:59:03 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Sep 2017 14:59:03 +0200 Subject: Add some missing UseShenandoahGC checks to 8u In-Reply-To: References: <994ad036-7360-fdde-9876-567054b2c23f@redhat.com> Message-ID: <31f01ffe-8bb1-32e6-5fb4-7733ddbed63c@redhat.com> On 09/21/2017 02:52 PM, Roland Westrelin wrote: >> *) loopnode.cpp does not look right. With !UseShenandoahGC this predicate is always false? >> >> 3608 if (new_ctrl != least) { > > upstream code for this is: > > if (ctrl_out && ctrl_out->is_CountedLoop() && > least == ctrl_out->in(LoopNode::EntryControl)) { > Node* least_dom = idom(least); > if (get_loop(least_dom)->is_member(get_loop(least))) { > least = least_dom; > } > } > > so to stick to upstream behaviour we only want the else line 3610 to > have a chance to succeed. I see! I wonder if it's cleaner/safer to revert to upstream and conditionalize the entire block on UseShenandoahGC then, to make it obvious the upstream code stays the same, instead of trying to play games with locals... I.e. so that the original upstream code was the same "if" branch: https://builds.shipilev.net/patch-openjdk-shenandoah-jdk8/2017-09-19-v38-vs-20d83f8419c4/src/share/vm/opto/loopnode.cpp.sdiff.html -Aleksey From rkennke at redhat.com Thu Sep 21 13:17:50 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 Sep 2017 15:17:50 +0200 Subject: RFR: Adaptive collection set selection in adaptive policy In-Reply-To: References: Message-ID: <136a7f0b-30a9-16d3-dbb4-375200cc7641@redhat.com> Am 21.09.2017 um 13:42 schrieb Aleksey Shipilev: > http://cr.openjdk.java.net/~shade/shenandoah/heuristics-adaptive-cset/webrev.01/ > > This includes both the actual change to adaptive heuristics, and cleanups than make it less painful. > Brief tour of changes: > > *) RegionGarbage -> RegionData renames, and using ShenandoahHeapRegion* directly. This helps to > avoid heap region lookups in heuristics; > > *) Coarsening the cset selection method into the single call. This helps to avoid virtual call on > every region, which makes it more optimizeable (important in leu of "/ 100" on hot path!). Coarse > method makes advanced heuristics easier to write. > > *) Adaptive heuristics fixes two heuristics deficiencies than may select too small or too large > collection set. See the comments in the source for discussion. > > These changes make LRUFragger survive on 85 GB LDS on 100 GB heap without Full GCs, which was never > possible before. Example Visualizer drawings with early-ur=on and early-ur=adaptive: > http://cr.openjdk.java.net/~shade/shenandoah/heuristics-adaptive-cset/85-on-100-URon.png > http://cr.openjdk.java.net/~shade/shenandoah/heuristics-adaptive-cset/85-on-100-URadaptive.png > (yes, we add more stuff to collection set, but the heap is overloaded, and we manage to avoid Full > GCs with that) > > Testing: hotspot_gc_shenandoah > > Thanks, > -Aleksey > Impressive result! Code changes look good to me. From rkennke at redhat.com Thu Sep 21 13:18:22 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 Sep 2017 15:18:22 +0200 Subject: Add some missing UseShenandoahGC checks to 8u In-Reply-To: References: Message-ID: Am 21.09.2017 um 14:31 schrieb Roland Westrelin: > http://cr.openjdk.java.net/~roland/shenandoah/8u_useshenandoahgc/webrev.00/ > > This adds some missing UseShenandoahGC checks so the behaviour of C2 > when shenandoah is disabled is less likely to differ from upstream 8u. > > Roland. Why not 9 and 10? From zgu at redhat.com Thu Sep 21 14:10:16 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 21 Sep 2017 10:10:16 -0400 Subject: RFR: Dynamic worker refactoring In-Reply-To: <45c62db2-9576-22c9-80b4-2ef0b8f70025@redhat.com> References: <8bad3ede-76a9-12b2-afd8-29ec5ef02476@redhat.com> <45c62db2-9576-22c9-80b4-2ef0b8f70025@redhat.com> Message-ID: On 09/21/2017 03:03 AM, Aleksey Shipilev wrote: > On 09/20/2017 11:27 PM, Zhengyu Gu wrote: >> This patch refactoring dynamic GC worker code out of ShenandoahCollectorPolicy, which is overcrowd. >> >> My tests never show any benefits of dynamic workers so far, and our customized code does not seem to >> outperform shared implementation, so lets revert back to shared implementation. >> >> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/dwg_refactor/webrev.00/ > > Looks very nice. > > *) Looking at shenandoahWorkerPolicy.hpp, it would seem the calc_worker stuff for update-refs is > missing? Should be *_for_conc_update_refs(), *_for_final_update_refs()? Init update-refs does not > require workers, IIRC. > Yep, thanks for pointing out. > *) Stylistic: maybe _prev_workers_for_marking is too excessive for the name? Suggestion: _prev_marking. > shorten all variables. > *) Stylistic: indenting for arguments seems better readable like this: > > _prev_marking = AdaptiveSizePolicy::calc_active_workers(ParallelGCThreads, > active_workers, > Threads::number_of_non_daemon_threads()); > > *) Stylistic: ternary statements should probably get farther indenting, like this (or maybe after > shortening the variable names, they are fine with single line?): > > uint active_workers = (_prev_workers_for_conc_marking == 0) ? > ConcGCThreads : _prev_workers_for_conc_marking; > Fixed. > *) Typo: "calculate" > > 85 // Calcuate workers for Stop-the-world partial GC > Fixed. Updated webrev: http://cr.openjdk.java.net/~zgu/shenandoah/dwg_refactor/webrev.01/ Thanks, -Zhengyu > Thanks, > -Aleksey > From shade at redhat.com Thu Sep 21 14:16:47 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Sep 2017 16:16:47 +0200 Subject: RFR: Dynamic worker refactoring In-Reply-To: References: <8bad3ede-76a9-12b2-afd8-29ec5ef02476@redhat.com> <45c62db2-9576-22c9-80b4-2ef0b8f70025@redhat.com> Message-ID: <422c159c-ec8d-6d8e-2778-72ad7b4a03ce@redhat.com> On 09/21/2017 04:10 PM, Zhengyu Gu wrote: > Updated webrev: http://cr.openjdk.java.net/~zgu/shenandoah/dwg_refactor/webrev.01/ I'd call these two "calc_workers_for_(conc|final)_update_refs": 60 // Calculate workers for concurrent reference update 61 static uint calc_workers_for_conc_update_ref(); 62 63 // Calculate workers for parallel reference update 64 static uint calc_workers_for_par_update_ref(); Also, indenting makes it ragged again :( // Calculate workers for parallel fullgc uint ShenandoahWorkerPolicy::calc_workers_for_fullgc() { uint active_workers = (_prev_fullgc == 0) ? ParallelGCThreads : _prev_fullgc; _prev_fullgc = AdaptiveSizePolicy::calc_active_workers(ParallelGCThreads, active_workers, Threads::number_of_non_daemon_threads()); return _prev_fullgc; } // Calculate workers for Stop-the-world partial GC uint ShenandoahWorkerPolicy::calc_workers_for_stw_partial() { uint active_workers = (_prev_stw_partial == 0) ? ParallelGCThreads : _prev_stw_partial; _prev_stw_partial = AdaptiveSizePolicy::calc_active_workers(ParallelGCThreads, active_workers, Threads::number_of_non_daemon_threads()); return _prev_stw_partial; } Better: // Calculate workers for parallel fullgc uint ShenandoahWorkerPolicy::calc_workers_for_fullgc() { uint active_workers = (_prev_fullgc == 0) ? ParallelGCThreads : _prev_fullgc; _prev_fullgc = AdaptiveSizePolicy::calc_active_workers(ParallelGCThreads, active_workers, Threads::number_of_non_daemon_threads()); return _prev_fullgc; } // Calculate workers for Stop-the-world partial GC uint ShenandoahWorkerPolicy::calc_workers_for_stw_partial() { uint active_workers = (_prev_stw_partial == 0) ? ParallelGCThreads : _prev_stw_partial; _prev_stw_partial = AdaptiveSizePolicy::calc_active_workers(ParallelGCThreads, active_workers, Threads::number_of_non_daemon_threads()); return _prev_stw_partial; } Otherwise good, no need to re-review if you decide to rename the methods and fix the indenting above. Thanks, -Aleksey From ashipile at redhat.com Thu Sep 21 15:03:22 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 21 Sep 2017 15:03:22 +0000 Subject: hg: shenandoah/jdk10/hotspot: 2 new changesets Message-ID: <201709211503.v8LF3MIe011073@aojmv0008.oracle.com> Changeset: dbcec9f0f279 Author: shade Date: 2017-09-21 16:32 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/dbcec9f0f279 Trim the TLAB sizes to avoid wasteful retirement under TLAB races ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! test/gc/shenandoah/options/TestExplicitGC.java Changeset: 00a0cfc2856a Author: shade Date: 2017-09-21 16:32 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/00a0cfc2856a Adaptive collection set selection in adaptive policy ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp From zgu at redhat.com Thu Sep 21 15:43:41 2017 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 21 Sep 2017 15:43:41 +0000 Subject: hg: shenandoah/jdk10/hotspot: Dynamic worker refactoring Message-ID: <201709211543.v8LFhful029863@aojmv0008.oracle.com> Changeset: 4063afb93980 Author: zgu Date: 2017-09-21 11:33 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/4063afb93980 Dynamic worker refactoring ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp + src/share/vm/gc/shenandoah/shenandoahWorkerPolicy.cpp + src/share/vm/gc/shenandoah/shenandoahWorkerPolicy.hpp ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.cpp From rwestrel at redhat.com Thu Sep 21 16:04:05 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 21 Sep 2017 18:04:05 +0200 Subject: Add some missing UseShenandoahGC checks to 8u In-Reply-To: <31f01ffe-8bb1-32e6-5fb4-7733ddbed63c@redhat.com> References: <994ad036-7360-fdde-9876-567054b2c23f@redhat.com> <31f01ffe-8bb1-32e6-5fb4-7733ddbed63c@redhat.com> Message-ID: > I see! I wonder if it's cleaner/safer to revert to upstream and > conditionalize the entire block on UseShenandoahGC then, to make it > obvious the upstream code stays the same, instead of trying to play > games with locals... I.e. so that the original upstream code was the > same "if" branch: This? http://cr.openjdk.java.net/~roland/shenandoah/8u_useshenandoahgc/webrev.01/ Roland. From rwestrel at redhat.com Thu Sep 21 16:10:29 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 21 Sep 2017 18:10:29 +0200 Subject: Add some missing UseShenandoahGC checks to 8u In-Reply-To: References: Message-ID: > Why not 9 and 10? Sure. But it seemed to me it was easier and more urgent to start with 8u. So, for 9, do we agree that big and invasive changes like strip mining that require some refactoring and so would be too risky to ship anyway, should be removed? And, for 10, do we agree that there's no need to make non shenandoah specific changes that are expected to land upstream conditional under UseShenandoahGC? Roland. From shade at redhat.com Thu Sep 21 16:17:50 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Sep 2017 18:17:50 +0200 Subject: Add some missing UseShenandoahGC checks to 8u In-Reply-To: References: <994ad036-7360-fdde-9876-567054b2c23f@redhat.com> <31f01ffe-8bb1-32e6-5fb4-7733ddbed63c@redhat.com> Message-ID: <2db1c23a-08dc-f2f1-7b2f-5531482abc43@redhat.com> On 09/21/2017 06:04 PM, Roland Westrelin wrote: > >> I see! I wonder if it's cleaner/safer to revert to upstream and >> conditionalize the entire block on UseShenandoahGC then, to make it >> obvious the upstream code stays the same, instead of trying to play >> games with locals... I.e. so that the original upstream code was the >> same "if" branch: > > This? > > http://cr.openjdk.java.net/~roland/shenandoah/8u_useshenandoahgc/webrev.01/ Yes, looks much better to me! Thanks, -Aleksey From rkennke at redhat.com Thu Sep 21 16:31:28 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 Sep 2017 18:31:28 +0200 Subject: Add some missing UseShenandoahGC checks to 8u In-Reply-To: References: Message-ID: Am 21.09.2017 um 18:10 schrieb Roland Westrelin: >> Why not 9 and 10? > Sure. But it seemed to me it was easier and more urgent to start with > 8u. Fine. > So, for 9, do we agree that big and invasive changes like strip mining > that require some refactoring and so would be too risky to ship anyway, > should be removed? This sounds reasonable to me. > And, for 10, do we agree that there's no need to make non shenandoah > specific changes that are expected to land upstream conditional under > UseShenandoahGC? Sure. Thanks! Roman From shade at redhat.com Thu Sep 21 16:36:10 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Sep 2017 18:36:10 +0200 Subject: Add some missing UseShenandoahGC checks to 8u In-Reply-To: References: Message-ID: On 09/21/2017 06:31 PM, Roman Kennke wrote: > Am 21.09.2017 um 18:10 schrieb Roland Westrelin: >> And, for 10, do we agree that there's no need to make non shenandoah >> specific changes that are expected to land upstream conditional under >> UseShenandoahGC? > Sure. Except that during backporting, we would need to guard them. So it seems easier to guard them straight in shenandoah/jdk10, test that guards work in shenandoah/jdk10, and backport the changes verbatim. Thanks, -Aleksey From shade at redhat.com Thu Sep 21 16:40:01 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Sep 2017 18:40:01 +0200 Subject: RFR: Make heap counters update completely asynchronous Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/concthread-periodic/webrev.01/ This uses the periodic tasks facility provided by VM to update the counters asynchronously. Allocation and GC paths are triggering the update, but do not perform the update themselves. This allows to simplify allocation path, capture GCLAB allocations without risking deadlocks, etc. Testing: hotspot_gc_shenandoah, allocation benchmarks Thanks, -Aleksey From rkennke at redhat.com Thu Sep 21 16:44:53 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 Sep 2017 18:44:53 +0200 Subject: RFR: Make heap counters update completely asynchronous In-Reply-To: References: Message-ID: <3da43285-2ab9-84b6-4839-a2cc5be96047@redhat.com> Am 21.09.2017 um 18:40 schrieb Aleksey Shipilev: > http://cr.openjdk.java.net/~shade/shenandoah/concthread-periodic/webrev.01/ > > This uses the periodic tasks facility provided by VM to update the counters asynchronously. > Allocation and GC paths are triggering the update, but do not perform the update themselves. This > allows to simplify allocation path, capture GCLAB allocations without risking deadlocks, etc. > > Testing: hotspot_gc_shenandoah, allocation benchmarks > > Thanks, > -Aleksey > I like it. Do we really want/need to remove stuff from metaspaceCounters.cpp|hpp ? Roman From shade at redhat.com Thu Sep 21 16:51:42 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Sep 2017 18:51:42 +0200 Subject: RFR: Make heap counters update completely asynchronous In-Reply-To: <3da43285-2ab9-84b6-4839-a2cc5be96047@redhat.com> References: <3da43285-2ab9-84b6-4839-a2cc5be96047@redhat.com> Message-ID: <0f437f35-3a2d-d21e-07cd-5cff1021426e@redhat.com> On 09/21/2017 06:44 PM, Roman Kennke wrote: > Am 21.09.2017 um 18:40 schrieb Aleksey Shipilev: >> http://cr.openjdk.java.net/~shade/shenandoah/concthread-periodic/webrev.01/ >> >> This uses the periodic tasks facility provided by VM to update the counters asynchronously. >> Allocation and GC paths are triggering the update, but do not perform the update themselves. This >> allows to simplify allocation path, capture GCLAB allocations without risking deadlocks, etc. >> >> Testing: hotspot_gc_shenandoah, allocation benchmarks >> >> Thanks, >> -Aleksey >> > I like it. > > Do we really want/need to remove stuff from metaspaceCounters.cpp|hpp ? These were our additions, along with TODO to clean that mess up. Upstream does not have it. -Aleksey From rkennke at redhat.com Thu Sep 21 16:54:13 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 Sep 2017 18:54:13 +0200 Subject: RFR: Make heap counters update completely asynchronous In-Reply-To: <0f437f35-3a2d-d21e-07cd-5cff1021426e@redhat.com> References: <3da43285-2ab9-84b6-4839-a2cc5be96047@redhat.com> <0f437f35-3a2d-d21e-07cd-5cff1021426e@redhat.com> Message-ID: Ah. Alright then! Am 21. September 2017 18:51:42 MESZ schrieb Aleksey Shipilev : >On 09/21/2017 06:44 PM, Roman Kennke wrote: >> Am 21.09.2017 um 18:40 schrieb Aleksey Shipilev: >>> >http://cr.openjdk.java.net/~shade/shenandoah/concthread-periodic/webrev.01/ >>> >>> This uses the periodic tasks facility provided by VM to update the >counters asynchronously. >>> Allocation and GC paths are triggering the update, but do not >perform the update themselves. This >>> allows to simplify allocation path, capture GCLAB allocations >without risking deadlocks, etc. >>> >>> Testing: hotspot_gc_shenandoah, allocation benchmarks >>> >>> Thanks, >>> -Aleksey >>> >> I like it. >> >> Do we really want/need to remove stuff from metaspaceCounters.cpp|hpp >? > >These were our additions, along with TODO to clean that mess up. >Upstream does not have it. > >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From shade at redhat.com Thu Sep 21 17:04:12 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Sep 2017 19:04:12 +0200 Subject: RFR: Make heap counters update completely asynchronous In-Reply-To: References: Message-ID: <91190d7a-a2af-bdf4-8e90-4bba704b55be@redhat.com> On 09/21/2017 06:40 PM, Aleksey Shipilev wrote: > http://cr.openjdk.java.net/~shade/shenandoah/concthread-periodic/webrev.01/ > > This uses the periodic tasks facility provided by VM to update the counters asynchronously. > Allocation and GC paths are triggering the update, but do not perform the update themselves. This > allows to simplify allocation path, capture GCLAB allocations without risking deadlocks, etc. Actually, let it be more resilient for the case WatcherThread crashes: there is some protection against that, but I think the failure would not be reliably reported. Capture that case in ShenandoahConcurrentThread itself after GC cycle. http://cr.openjdk.java.net/~shade/shenandoah/concthread-periodic/webrev.02/ -Aleksey From rkennke at redhat.com Thu Sep 21 17:48:26 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 Sep 2017 19:48:26 +0200 Subject: RFR: Make heap counters update completely asynchronous In-Reply-To: <91190d7a-a2af-bdf4-8e90-4bba704b55be@redhat.com> References: <91190d7a-a2af-bdf4-8e90-4bba704b55be@redhat.com> Message-ID: <55f3849f-35e0-c434-73a4-12e47802eacb@redhat.com> Am 21.09.2017 um 19:04 schrieb Aleksey Shipilev: > On 09/21/2017 06:40 PM, Aleksey Shipilev wrote: >> http://cr.openjdk.java.net/~shade/shenandoah/concthread-periodic/webrev.01/ >> >> This uses the periodic tasks facility provided by VM to update the counters asynchronously. >> Allocation and GC paths are triggering the update, but do not perform the update themselves. This >> allows to simplify allocation path, capture GCLAB allocations without risking deadlocks, etc. > Actually, let it be more resilient for the case WatcherThread crashes: there is some protection > against that, but I think the failure would not be reliably reported. Capture that case in > ShenandoahConcurrentThread itself after GC cycle. > > http://cr.openjdk.java.net/~shade/shenandoah/concthread-periodic/webrev.02/ > > -Aleksey > yes From ashipile at redhat.com Thu Sep 21 17:53:49 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 21 Sep 2017 17:53:49 +0000 Subject: hg: shenandoah/jdk10/hotspot: Make heap counters update completely asynchronous Message-ID: <201709211753.v8LHrn1r027976@aojmv0008.oracle.com> Changeset: bd0d6f6643a3 Author: shade Date: 2017-09-21 19:24 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/bd0d6f6643a3 Make heap counters update completely asynchronous ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp From ashipile at redhat.com Fri Sep 22 08:12:37 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 22 Sep 2017 08:12:37 +0000 Subject: hg: shenandoah/jdk9/hotspot: 13 new changesets Message-ID: <201709220812.v8M8CbUk006580@aojmv0008.oracle.com> Changeset: 50f3efd99417 Author: shade Date: 2017-09-22 08:30 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/50f3efd99417 [backport] Fix, improve and refactor matrix barrier on AAarch64 ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/templateTable_aarch64.cpp Changeset: 2e85abb9f8f5 Author: shade Date: 2017-09-22 08:31 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/2e85abb9f8f5 [backport] Verify regions status ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.hpp Changeset: ad284a76897b Author: shade Date: 2017-09-22 08:32 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/ad284a76897b [backport] Asynchronous region recycling ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapLock.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp Changeset: 430d177b0c96 Author: shade Date: 2017-09-22 08:32 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/430d177b0c96 [backport] Heap region sampling should publish region states ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegionCounters.hpp Changeset: a5284cf42445 Author: shade Date: 2017-09-22 08:34 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/a5284cf42445 [backport] Fixup roots after partial GC failed ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp Changeset: 716ae0df33fd Author: shade Date: 2017-09-22 08:35 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/716ae0df33fd [backport] Store checks should run most of the time ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.inline.hpp Changeset: 0e47bf9e46fd Author: shade Date: 2017-09-22 08:36 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/0e47bf9e46fd [backport] Fix assert_gc_workers() and missing test case ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc/shenandoah/shenandoahWorkGroup.cpp ! src/share/vm/gc/shenandoah/shenandoahWorkGroup.hpp + test/gc/shenandoah/TestGCThreadGroups.java Changeset: 2e764f565728 Author: shade Date: 2017-09-22 08:38 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/2e764f565728 [backport] Updates to generational/lru partial heuristics ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp Changeset: 261a9fad621f Author: shade Date: 2017-09-22 09:02 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/261a9fad621f [backport] FreeSet refactor: bitmaps, cursors, biasing ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp Changeset: 00aecc44f437 Author: shade Date: 2017-09-22 08:40 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/00aecc44f437 [backport] Trim the TLAB sizes to avoid wasteful retirement under TLAB races ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc/shenandoah/shenandoahHeapRegion.hpp ! test/gc/shenandoah/options/TestExplicitGC.java Changeset: 66031706f910 Author: shade Date: 2017-09-22 08:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/66031706f910 [backport] Adaptive collection set selection in adaptive policy ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp Changeset: 0a4ddcd109c8 Author: shade Date: 2017-09-22 08:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/0a4ddcd109c8 [backport] Dynamic worker refactoring ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.cpp Changeset: ff45c6e9dd2a Author: shade Date: 2017-09-22 08:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/ff45c6e9dd2a [backport] Make heap counters update completely asynchronous ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.hpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp From rwestrel at redhat.com Fri Sep 22 08:43:08 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Fri, 22 Sep 2017 08:43:08 +0000 Subject: hg: shenandoah/jdk8u/hotspot: add missing UseShenandoahGC checks to C2 Message-ID: <201709220843.v8M8h8Kf018218@aojmv0008.oracle.com> Changeset: 939032ac627d Author: roland Date: 2017-09-21 17:56 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/939032ac627d add missing UseShenandoahGC checks to C2 ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/shenandoahSupport.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/type.cpp From ashipile at redhat.com Fri Sep 22 08:44:35 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Fri, 22 Sep 2017 08:44:35 +0000 Subject: hg: shenandoah/jdk9/hotspot: Add missing files for [backport] Dynamic worker refactoring Message-ID: <201709220844.v8M8iZ0G018764@aojmv0008.oracle.com> Changeset: 61282f92ee2f Author: shade Date: 2017-09-22 10:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/61282f92ee2f Add missing files for [backport] Dynamic worker refactoring + src/share/vm/gc/shenandoah/shenandoahWorkerPolicy.cpp + src/share/vm/gc/shenandoah/shenandoahWorkerPolicy.hpp From zgu at redhat.com Fri Sep 22 14:43:23 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 22 Sep 2017 10:43:23 -0400 Subject: RFR: unsafe oop comparison Message-ID: <8ee469d7-0a9a-7421-e3e8-2281cba90910@redhat.com> Crash with -XX:+VerifyStrictOopOperations -XX:+PrintAssembly in debug build. Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/unsafe_eq/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu From shade at redhat.com Fri Sep 22 14:48:03 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 22 Sep 2017 16:48:03 +0200 Subject: RFR: unsafe oop comparison In-Reply-To: <8ee469d7-0a9a-7421-e3e8-2281cba90910@redhat.com> References: <8ee469d7-0a9a-7421-e3e8-2281cba90910@redhat.com> Message-ID: On 09/22/2017 04:43 PM, Zhengyu Gu wrote: > Crash with -XX:+VerifyStrictOopOperations -XX:+PrintAssembly in debug build. > > Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/unsafe_eq/webrev.00/ Ouch, bad typo: 2384 if (oopDesc::unsafe_equals(0, (oop)Universe::non_oop_word())) { ^^^--- zero! -Aleksey From zgu at redhat.com Fri Sep 22 14:54:50 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 22 Sep 2017 10:54:50 -0400 Subject: RFR: unsafe oop comparison In-Reply-To: References: <8ee469d7-0a9a-7421-e3e8-2281cba90910@redhat.com> Message-ID: Ouch, my eyes are really bad now :-( http://cr.openjdk.java.net/~zgu/shenandoah/unsafe_eq/webrev.01/ -Zhengyu On 09/22/2017 10:48 AM, Aleksey Shipilev wrote: > On 09/22/2017 04:43 PM, Zhengyu Gu wrote: >> Crash with -XX:+VerifyStrictOopOperations -XX:+PrintAssembly in debug build. >> >> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/unsafe_eq/webrev.00/ > > Ouch, bad typo: > > 2384 if (oopDesc::unsafe_equals(0, (oop)Universe::non_oop_word())) { > ^^^--- zero! > > -Aleksey > From shade at redhat.com Fri Sep 22 14:55:48 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 22 Sep 2017 16:55:48 +0200 Subject: RFR: unsafe oop comparison In-Reply-To: References: <8ee469d7-0a9a-7421-e3e8-2281cba90910@redhat.com> Message-ID: <348b16d1-aef8-bacb-a710-a4bfcda67b99@redhat.com> On 09/22/2017 04:54 PM, Zhengyu Gu wrote: > http://cr.openjdk.java.net/~zgu/shenandoah/unsafe_eq/webrev.01/ Looks good. -Aleksey From zgu at redhat.com Fri Sep 22 15:01:01 2017 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 22 Sep 2017 15:01:01 +0000 Subject: hg: shenandoah/jdk10/hotspot: Fixed unsafe oop comparison Message-ID: <201709221501.v8MF11hm024871@aojmv0008.oracle.com> Changeset: b739cd242718 Author: zgu Date: 2017-09-22 10:56 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/b739cd242718 Fixed unsafe oop comparison ! src/share/vm/code/nmethod.cpp From zgu at redhat.com Sat Sep 23 00:59:40 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 22 Sep 2017 20:59:40 -0400 Subject: RFR: Refactoring GC phase and heap allocation tracking out of policy Message-ID: Refactoring GC phase timing tracking and heap allocation tracking out of ShenandoahCollectorPolicy. Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/prof_refactor/webrev.00/index.html Test: hotspot_gc_shenandoah (fastdebug and release) Manually verified -Xlog:gc+stats output. Thanks, -Zhenngyu From shade at redhat.com Sat Sep 23 10:35:19 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 23 Sep 2017 12:35:19 +0200 Subject: RFR: Adaptive accounts trashed cset twice Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/heuristics-adaptive-twice-cset/webrev.01/ Recent improvement in adaptive heuristics was incomplete due to a simple overlook: we account the cset from the previous run twice. We do it "normally" with trashing the cset, and accounting it in trash/free. We do it second time via _bytes_in_cset. _bytes_in_cset is needed for polling potential free before actual trashing happens in should_start_conc_mark, but not in the actual cset construction. This fix makes LRUFragger survive with even further LDSes, when current (bad) code overshoots free space and runs into OOME-during-evac. This is not a regression per se, because on non-overloaded heap this matters much less, if at all. Testing: hotspot_gc_shenandoah, benchmarks Thanks, -Aleksey From shade at redhat.com Sat Sep 23 10:50:43 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 23 Sep 2017 12:50:43 +0200 Subject: RFR: Refactoring GC phase and heap allocation tracking out of policy In-Reply-To: References: Message-ID: On 09/23/2017 02:59 AM, Zhengyu Gu wrote: > Refactoring GC phase timing tracking and heap allocation tracking out of ShenandoahCollectorPolicy. > > > Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/prof_refactor/webrev.00/index.html I like it! Would be interesting to try and conditionalize timing gathering on gc+stats. It seems wasteful to poll timers when we don't consume the data. Does not have to be in this patch though, but maybe the change should have that work in mind. Few nits: *) ShenandoahGCPhaseTimings -> ShenandoahPhaseTimings? *) ShenandoahHeap::gc_phase_timings() -> ShenandoahHeap::phase_timings()? *) ShenandoahGCPhaseTimings::TimingPhase -> ShenandoahPhaseTimings::Phase? *) Do we need the forward declaration in shenandoahCollectorPolicy.hpp? outputStream was used before in this class... 41 class outputStream; *) outputStream must have cr() methods for this? 1293 ls.print_cr(""); 1294 ls.print_cr(""); Thanks, -Aleksey From rkennke at redhat.com Sat Sep 23 10:56:13 2017 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 23 Sep 2017 12:56:13 +0200 Subject: RFR: Adaptive accounts trashed cset twice In-Reply-To: References: Message-ID: <5B6518BC-AB07-41BD-865F-4C74C4042D61@redhat.com> Looks good Am 23. September 2017 12:35:19 MESZ schrieb Aleksey Shipilev : >http://cr.openjdk.java.net/~shade/shenandoah/heuristics-adaptive-twice-cset/webrev.01/ > >Recent improvement in adaptive heuristics was incomplete due to a >simple overlook: we account the >cset from the previous run twice. We do it "normally" with trashing the >cset, and accounting it in >trash/free. We do it second time via _bytes_in_cset. _bytes_in_cset is >needed for polling potential >free before actual trashing happens in should_start_conc_mark, but not >in the actual cset construction. > >This fix makes LRUFragger survive with even further LDSes, when current >(bad) code overshoots free >space and runs into OOME-during-evac. This is not a regression per se, >because on non-overloaded >heap this matters much less, if at all. > >Testing: hotspot_gc_shenandoah, benchmarks > >Thanks, >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From ashipile at redhat.com Sat Sep 23 14:25:11 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Sat, 23 Sep 2017 14:25:11 +0000 Subject: hg: shenandoah/jdk10/hotspot: Adaptive heuristics accounts trashed cset twice Message-ID: <201709231425.v8NEPBF8016983@aojmv0008.oracle.com> Changeset: fb6b4660d4bb Author: shade Date: 2017-09-23 16:21 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/fb6b4660d4bb Adaptive heuristics accounts trashed cset twice ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp From ashipile at redhat.com Sat Sep 23 16:03:03 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Sat, 23 Sep 2017 16:03:03 +0000 Subject: hg: shenandoah/jdk9/hotspot: 2 new changesets Message-ID: <201709231603.v8NG35UA022153@aojmv0008.oracle.com> Changeset: 0d2fd006897a Author: shade Date: 2017-09-23 16:29 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/0d2fd006897a [backport] Fixed unsafe oop comparison ! src/share/vm/code/nmethod.cpp Changeset: 5d90fa060f19 Author: shade Date: 2017-09-23 16:29 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/5d90fa060f19 [backport] Adaptive heuristics accounts trashed cset twice ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp From rwestrel at redhat.com Mon Sep 25 09:33:48 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 25 Sep 2017 11:33:48 +0200 Subject: RFR(XS): one more missing UseShenandoahGC in 8u Message-ID: http://cr.openjdk.java.net/~roland/shenandoah/8u_useshenandoahgc2/webrev.00/ From shade at redhat.com Mon Sep 25 10:00:11 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Sep 2017 12:00:11 +0200 Subject: RFR(XS): one more missing UseShenandoahGC in 8u In-Reply-To: References: Message-ID: <36198082-2956-3436-c86a-85092a4fd814@redhat.com> On 09/25/2017 11:33 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/shenandoah/8u_useshenandoahgc2/webrev.00/ This looks good. Upstream has only s->is_Load() part of condition [1], and that's what we get with UseShenandoahGC after this patch. Thanks, -Aleksey [1] https://builds.shipilev.net/patch-openjdk-shenandoah-jdk8/2017-09-22-v39-vs-20d83f8419c4/src/share/vm/opto/loopnode.cpp.sdiff.html From aph at redhat.com Mon Sep 25 10:01:44 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 25 Sep 2017 11:01:44 +0100 Subject: RFR: Fix, improve and refactor matrix barrier on AAarch64 In-Reply-To: <2be8f1fc-ff13-867a-e8d7-ba03ced758b2@redhat.com> References: <663e9c13-6139-4781-43c0-cd20b259310c@redhat.com> <9523f308-a01f-bb3b-0182-fc15e706e476@redhat.com> <1fb68f54-1c70-6601-5c76-17abc249de63@redhat.com> <2be8f1fc-ff13-867a-e8d7-ba03ced758b2@redhat.com> Message-ID: <60d5dfd6-fc29-5d87-70dc-1e674100113e@redhat.com> On 14/09/17 16:20, Aleksey Shipilev wrote: > On 09/14/2017 05:19 PM, Roman Kennke wrote: >>> >>>> http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.01/ >>> Good, except for rscratch1 change. >> >> Ok, I made it a compromise: kept the method signature the same (i.e. 2 tmp args), and declare tmp3 >> at the beginning of the code block to be rscratch1. >> >> http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.02/ This is confusing code. Giving rscratch1 a name like "tmp3" doesn't help anyone, and it adds risk because many macros implicitly clobber rscratch1. Something like this (untested) is clearer: // Compute matrix index mov(rscratch1, matrix->stride_jint()); // Address is _matrix[to * stride + from] madd(tmp, tmp, rscratch1, tmp2); mov(rscratch1, matrix->magic_offset()); Address loc(tmp, rscratch1); ldrb(tmp2, loc); cbnzw(tmp2, done); mov(tmp2, 1); strb(tmp2, loc); bind(done); -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Mon Sep 25 10:54:27 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Mon, 25 Sep 2017 10:54:27 +0000 Subject: hg: shenandoah/jdk8u/hotspot: missing UseShenandoahGC check to C2 Message-ID: <201709251054.v8PAsRtB008072@aojmv0008.oracle.com> Changeset: d3237f84460f Author: roland Date: 2017-09-25 11:30 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/d3237f84460f missing UseShenandoahGC check to C2 ! src/share/vm/opto/loopnode.cpp From rwestrel at redhat.com Mon Sep 25 12:13:54 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 25 Sep 2017 14:13:54 +0200 Subject: FTR: fix for TCK crash Message-ID: I will push the following fix to 10, 9 and 8u to fix the crash with the TCK that we've been seing: http://cr.openjdk.java.net/~roland/shenandoah/tckfix/webrev.00/ Roland. From shade at redhat.com Mon Sep 25 12:19:33 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Sep 2017 14:19:33 +0200 Subject: FTR: fix for TCK crash In-Reply-To: References: Message-ID: On 09/25/2017 02:13 PM, Roland Westrelin wrote: > > I will push the following fix to 10, 9 and 8u to fix the crash with the > TCK that we've been seing: > > http://cr.openjdk.java.net/~roland/shenandoah/tckfix/webrev.00/ Looks good. So is_top() misses the some transformations that are captured by phase->type? Seems to be safe since it is under "if (input->Opcode() == Op_ShenandoahWBMemProj)" branch. Thanks, -Aleksey From rwestrel at redhat.com Mon Sep 25 12:30:38 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 25 Sep 2017 14:30:38 +0200 Subject: FTR: fix for TCK crash In-Reply-To: References: Message-ID: > So is_top() misses the some transformations that are captured by > phase->type? is_top() checks whether the node is the unique top node (which has type TOP). When a node is found to have type TOP, it should be replaced with the top node but there's a corner case here, where the node is not top but has type TOP and is not replaced by the top node (I think because the code being optimized is dead). Roland. From shade at redhat.com Mon Sep 25 12:33:21 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Sep 2017 14:33:21 +0200 Subject: FTR: fix for TCK crash In-Reply-To: References: Message-ID: <0903b64e-385a-e563-3051-3ff0f5635b57@redhat.com> On 09/25/2017 02:30 PM, Roland Westrelin wrote: >> So is_top() misses the some transformations that are captured by >> phase->type? > > is_top() checks whether the node is the unique top node (which has type > TOP). When a node is found to have type TOP, it should be replaced with > the top node but there's a corner case here, where the node is not top > but has type TOP and is not replaced by the top node (I think because > the code being optimized is dead). Got it. Please make a useful commit message out of this explanation! Thanks, -Aleksey From shade at redhat.com Mon Sep 25 13:25:29 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Sep 2017 15:25:29 +0200 Subject: RFR: Concurrent cleanup after partial GC gets accounted in gross pause Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/stats-partial-gross/webrev.01/ Trivial: the scope for ShenandoahGCPhase is off Testing: eyeballing -Xlog:gc+stats Thanks, -Aleksey From zgu at redhat.com Mon Sep 25 13:32:35 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 25 Sep 2017 09:32:35 -0400 Subject: RFR: Concurrent cleanup after partial GC gets accounted in gross pause In-Reply-To: References: Message-ID: Yes. -Zhengyu On 09/25/2017 09:25 AM, Aleksey Shipilev wrote: > http://cr.openjdk.java.net/~shade/shenandoah/stats-partial-gross/webrev.01/ > > Trivial: the scope for ShenandoahGCPhase is off > > Testing: eyeballing -Xlog:gc+stats > > Thanks, > -Aleksey > From ashipile at redhat.com Mon Sep 25 13:46:38 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Mon, 25 Sep 2017 13:46:38 +0000 Subject: hg: shenandoah/jdk10/hotspot: Concurrent cleanup after partial GC gets accounted in gross pause Message-ID: <201709251346.v8PDkdQU009910@aojmv0008.oracle.com> Changeset: b641be834041 Author: shade Date: 2017-09-25 15:43 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/b641be834041 Concurrent cleanup after partial GC gets accounted in gross pause ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp From rwestrel at redhat.com Mon Sep 25 14:20:52 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 25 Sep 2017 16:20:52 +0200 Subject: FTR: fix for TCK crash In-Reply-To: <0903b64e-385a-e563-3051-3ff0f5635b57@redhat.com> References: <0903b64e-385a-e563-3051-3ff0f5635b57@redhat.com> Message-ID: > Got it. Please make a useful commit message out of this explanation! I'll add a comment instead. Roland. From zgu at redhat.com Mon Sep 25 15:15:41 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 25 Sep 2017 11:15:41 -0400 Subject: RFR: Refactoring GC phase and heap allocation tracking out of policy In-Reply-To: References: Message-ID: <2299f097-c27b-1e6e-7e94-925f532b9cb3@redhat.com> On 09/23/2017 06:50 AM, Aleksey Shipilev wrote: > On 09/23/2017 02:59 AM, Zhengyu Gu wrote: >> Refactoring GC phase timing tracking and heap allocation tracking out of ShenandoahCollectorPolicy. >> >> >> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/prof_refactor/webrev.00/index.html > > I like it! > > Would be interesting to try and conditionalize timing gathering on gc+stats. It seems wasteful to > poll timers when we don't consume the data. Does not have to be in this patch though, but maybe the > change should have that work in mind. Our heuristics need timing feed also. > > Few nits: > > *) ShenandoahGCPhaseTimings -> ShenandoahPhaseTimings? > > *) ShenandoahHeap::gc_phase_timings() -> ShenandoahHeap::phase_timings()? > > *) ShenandoahGCPhaseTimings::TimingPhase -> ShenandoahPhaseTimings::Phase? > Okay. > *) Do we need the forward declaration in shenandoahCollectorPolicy.hpp? outputStream was used > before in this class... > > 41 class outputStream; Well, I think we should avoid indirect dependencies ... > > *) outputStream must have cr() methods for this? > > 1293 ls.print_cr(""); > 1294 ls.print_cr(""); > Fixed. http://cr.openjdk.java.net/~zgu/shenandoah/prof_refactor/webrev.01/ Reran all tests. Thanks, -Zhengyu > > Thanks, > -Aleksey > From shade at redhat.com Mon Sep 25 16:32:05 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Sep 2017 18:32:05 +0200 Subject: RFR: Refactoring GC phase and heap allocation tracking out of policy In-Reply-To: <2299f097-c27b-1e6e-7e94-925f532b9cb3@redhat.com> References: <2299f097-c27b-1e6e-7e94-925f532b9cb3@redhat.com> Message-ID: <582d881b-932f-dce2-05bb-90046d8ddc03@redhat.com> On 09/25/2017 05:15 PM, Zhengyu Gu wrote: > On 09/23/2017 06:50 AM, Aleksey Shipilev wrote: >> On 09/23/2017 02:59 AM, Zhengyu Gu wrote: >>> Refactoring GC phase timing tracking and heap allocation tracking out of ShenandoahCollectorPolicy. >>> >>> >>> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/prof_refactor/webrev.00/index.html >> >> I like it! >> >> Would be interesting to try and conditionalize timing gathering on gc+stats. It seems wasteful to >> poll timers when we don't consume the data. Does not have to be in this patch though, but maybe the >> change should have that work in mind. > > Our heuristics need timing feed also. Yes, but we can split it out. > http://cr.openjdk.java.net/~zgu/shenandoah/prof_refactor/webrev.01/ Looks good to me. You will collide with my committed change in ShenandoahConcurrentThread::do_partial_cycle, sorry. Under our new rules, this has to wait for anyone else to chime in. -Aleksey From rkennke at redhat.com Mon Sep 25 16:47:13 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 25 Sep 2017 18:47:13 +0200 Subject: RFR: Refactoring GC phase and heap allocation tracking out of policy In-Reply-To: <582d881b-932f-dce2-05bb-90046d8ddc03@redhat.com> References: <2299f097-c27b-1e6e-7e94-925f532b9cb3@redhat.com> <582d881b-932f-dce2-05bb-90046d8ddc03@redhat.com> Message-ID: Am 25.09.2017 um 18:32 schrieb Aleksey Shipilev: > On 09/25/2017 05:15 PM, Zhengyu Gu wrote: >> On 09/23/2017 06:50 AM, Aleksey Shipilev wrote: >>> On 09/23/2017 02:59 AM, Zhengyu Gu wrote: >>>> Refactoring GC phase timing tracking and heap allocation tracking out of ShenandoahCollectorPolicy. >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/prof_refactor/webrev.00/index.html >>> I like it! >>> >>> Would be interesting to try and conditionalize timing gathering on gc+stats. It seems wasteful to >>> poll timers when we don't consume the data. Does not have to be in this patch though, but maybe the >>> change should have that work in mind. >> Our heuristics need timing feed also. > Yes, but we can split it out. > >> http://cr.openjdk.java.net/~zgu/shenandoah/prof_refactor/webrev.01/ > Looks good to me. You will collide with my committed change in > ShenandoahConcurrentThread::do_partial_cycle, sorry. > > Under our new rules, this has to wait for anyone else to chime in. I like it and code looks good. Roman From cflood at redhat.com Mon Sep 25 16:47:45 2017 From: cflood at redhat.com (Christine Flood) Date: Mon, 25 Sep 2017 12:47:45 -0400 Subject: RFR: Refactoring GC phase and heap allocation tracking out of policy In-Reply-To: <2299f097-c27b-1e6e-7e94-925f532b9cb3@redhat.com> References: <2299f097-c27b-1e6e-7e94-925f532b9cb3@redhat.com> Message-ID: This is good stuff. Fine by me. Thank You, Christine On Mon, Sep 25, 2017 at 11:15 AM, Zhengyu Gu wrote: > > > On 09/23/2017 06:50 AM, Aleksey Shipilev wrote: > >> On 09/23/2017 02:59 AM, Zhengyu Gu wrote: >> >>> Refactoring GC phase timing tracking and heap allocation tracking out of >>> ShenandoahCollectorPolicy. >>> >>> >>> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/prof_refactor/web >>> rev.00/index.html >>> >> >> I like it! >> >> Would be interesting to try and conditionalize timing gathering on >> gc+stats. It seems wasteful to >> poll timers when we don't consume the data. Does not have to be in this >> patch though, but maybe the >> change should have that work in mind. >> > > Our heuristics need timing feed also. > > >> Few nits: >> >> *) ShenandoahGCPhaseTimings -> ShenandoahPhaseTimings? >> >> *) ShenandoahHeap::gc_phase_timings() -> ShenandoahHeap::phase_timings( >> )? >> >> *) ShenandoahGCPhaseTimings::TimingPhase -> >> ShenandoahPhaseTimings::Phase? >> >> Okay. > > *) Do we need the forward declaration in shenandoahCollectorPolicy.hpp? >> outputStream was used >> before in this class... >> >> 41 class outputStream; >> > > Well, I think we should avoid indirect dependencies ... > > >> *) outputStream must have cr() methods for this? >> >> 1293 ls.print_cr(""); >> 1294 ls.print_cr(""); >> >> Fixed. > > http://cr.openjdk.java.net/~zgu/shenandoah/prof_refactor/webrev.01/ > > Reran all tests. > > Thanks, > > -Zhengyu > > > >> Thanks, >> -Aleksey >> >> From zgu at redhat.com Mon Sep 25 16:57:52 2017 From: zgu at redhat.com (zgu at redhat.com) Date: Mon, 25 Sep 2017 16:57:52 +0000 Subject: hg: shenandoah/jdk10/hotspot: Refactoring GC phase and heap allocation tracking out of policy Message-ID: <201709251657.v8PGvr26023337@aojmv0008.oracle.com> Changeset: 00b9cd9ff0f0 Author: zgu Date: 2017-09-25 12:54 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/00b9cd9ff0f0 Refactoring GC phase and heap allocation tracking out of policy ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp ! src/share/vm/gc/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.cpp From rkennke at redhat.com Mon Sep 25 16:59:33 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 25 Sep 2017 18:59:33 +0200 Subject: RFR: Refactor conc-mark-in-progress/satb-active flags to use gc-phase-in-progress In-Reply-To: References: Message-ID: <4b5ea38b-6eea-44a6-f2f0-300c749daaf2@redhat.com> Am 17.09.2017 um 14:11 schrieb Roman Kennke: > > his builds on top of the remove-reduce-storeval-barrier-optimization > patch. > > It refactors our conc-mark-in-progress flag together with the > satb-in-progress-flag into our new gc-phase-in-progress bitfield. > > Notable stuff: > > - The patch removes a 2nd check for satb-in-progress in C1. I'll > propose this upstream asap. > - The G1/Shenandoah pre-barriers are refactored such that the > satb-active (G1) and bitfield-concmark-checks (Sheanndoah) are now > separated, while keeping the rest of the inlined SATB-queue-pushing > code shared. > - I noticed the store-checks code is wrong in both x86 and aarch64. We > want to check the storeval-oops only when update-refs is in progress, > but do the check statically, we need to do the check at runtime though > because we might update refs during separate phase or during > conc-mark. This should be fixed, but separately (and probably benefits > from folding update-refs-in-progress into the bitfield too) > - It involves quite a bit of refactoring in C2. I am fairly confident > that it is correct. Would be good to have Roland take a look too. We > should also check with Roland whether or not this is sufficient to > allow commoning loads and checks of the bitfield, or if we need extra > optimization passes for this. > > Test: hotspot_gc_shenandoah both x86 and aarch64 > > http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.01/ > > > > Roman > Little update (incorporating Shade's store-check fix): http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.02/ Roman From cflood at redhat.com Mon Sep 25 23:06:45 2017 From: cflood at redhat.com (Christine Flood) Date: Mon, 25 Sep 2017 19:06:45 -0400 Subject: RFR: Refactor conc-mark-in-progress/satb-active flags to use gc-phase-in-progress In-Reply-To: <4b5ea38b-6eea-44a6-f2f0-300c749daaf2@redhat.com> References: <4b5ea38b-6eea-44a6-f2f0-300c749daaf2@redhat.com> Message-ID: I suspect this comment is wrong. } else if (UseShenandoahGC && ShenandoahKeepAliveBarrier) {4014 enter(); // g1_write may call runtime4015 shenandoah_write_barrier_pre(noreg,4016 val /* pre_val */,4017 thread /* thread */,4018 tmp,4019 true /* tosca_live */,4020 true /* expand_call */); 4021 leave(); 4022 } 4023 } I don't understand all of the changes inside of graphKit but I think the refactoring makes sense and doesn't violate the "do no harm to non-shenandoah" prime directive. Including shenandoahHeap.hpp in ifnode.cpp is yucky. Can we maybe clean this up and just have ShenandoahSupport (only slightly less yucky)? It looks like all we need is the CONC_MARK constant. Christine On Mon, Sep 25, 2017 at 12:59 PM, Roman Kennke wrote: > Am 17.09.2017 um 14:11 schrieb Roman Kennke: > >> >> his builds on top of the remove-reduce-storeval-barrier-optimization >> patch. >> >> It refactors our conc-mark-in-progress flag together with the >> satb-in-progress-flag into our new gc-phase-in-progress bitfield. >> >> Notable stuff: >> >> - The patch removes a 2nd check for satb-in-progress in C1. I'll propose >> this upstream asap. >> - The G1/Shenandoah pre-barriers are refactored such that the satb-active >> (G1) and bitfield-concmark-checks (Sheanndoah) are now separated, while >> keeping the rest of the inlined SATB-queue-pushing code shared. >> - I noticed the store-checks code is wrong in both x86 and aarch64. We >> want to check the storeval-oops only when update-refs is in progress, but >> do the check statically, we need to do the check at runtime though because >> we might update refs during separate phase or during conc-mark. This should >> be fixed, but separately (and probably benefits from folding >> update-refs-in-progress into the bitfield too) >> - It involves quite a bit of refactoring in C2. I am fairly confident >> that it is correct. Would be good to have Roland take a look too. We should >> also check with Roland whether or not this is sufficient to allow commoning >> loads and checks of the bitfield, or if we need extra optimization passes >> for this. >> >> Test: hotspot_gc_shenandoah both x86 and aarch64 >> >> http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.01/ < >> http://cr.openjdk.java.net/%7Erkennke/satb-concmark-flag/webrev.01/> >> >> >> Roman >> >> Little update (incorporating Shade's store-check fix): > > http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.02/ < > http://cr.openjdk.java.net/%7Erkennke/satb-concmark-flag/webrev.02/> > > Roman > > From ashipile at redhat.com Tue Sep 26 07:40:22 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 26 Sep 2017 07:40:22 +0000 Subject: hg: shenandoah/jdk10/hotspot: Missing files for "Refactoring GC phase and heap allocation tracking out of policy" Message-ID: <201709260740.v8Q7eNxP025388@aojmv0008.oracle.com> Changeset: b3f75cbabed5 Author: shade Date: 2017-09-26 09:37 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/b3f75cbabed5 Missing files for "Refactoring GC phase and heap allocation tracking out of policy" + src/share/vm/gc/shenandoah/shenandoahAllocTracker.cpp + src/share/vm/gc/shenandoah/shenandoahAllocTracker.hpp + src/share/vm/gc/shenandoah/shenandoahPhaseTimings.cpp + src/share/vm/gc/shenandoah/shenandoahPhaseTimings.hpp From shade at redhat.com Tue Sep 26 08:50:13 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 Sep 2017 10:50:13 +0200 Subject: RFR: Refactor worker timings into ShenandoahPhaseTimings Message-ID: <1b1d8202-c03e-8c71-eef6-2faa477a4421@redhat.com> http://cr.openjdk.java.net/~shade/shenandoah/stats-worker-times/webrev.01/ Noticed we now have shenandoahPhaseTimings.(hpp|cpp) and shenandoahPhaseTimes.{cpp|hpp}. The latter does the per-worker accounting, and merges it back to total counters. Moved that into our recently added file, and did a few renames to capture those bits are indeed about workers. Does not change the output: http://cr.openjdk.java.net/~shade/shenandoah/stats-worker-times/before.txt http://cr.openjdk.java.net/~shade/shenandoah/stats-worker-times/after.txt Testing: hotspot_gc_shenandoah, eyeballing gc+stats Thanks, -Aleksey From rkennke at redhat.com Tue Sep 26 09:10:32 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 26 Sep 2017 11:10:32 +0200 Subject: RFR: Refactor worker timings into ShenandoahPhaseTimings In-Reply-To: <1b1d8202-c03e-8c71-eef6-2faa477a4421@redhat.com> References: <1b1d8202-c03e-8c71-eef6-2faa477a4421@redhat.com> Message-ID: This looks useful and good to me. Roman Am 26. September 2017 10:50:13 MESZ schrieb Aleksey Shipilev : >http://cr.openjdk.java.net/~shade/shenandoah/stats-worker-times/webrev.01/ > >Noticed we now have shenandoahPhaseTimings.(hpp|cpp) and >shenandoahPhaseTimes.{cpp|hpp}. The latter >does the per-worker accounting, and merges it back to total counters. >Moved that into our recently >added file, and did a few renames to capture those bits are indeed >about workers. > >Does not change the output: >http://cr.openjdk.java.net/~shade/shenandoah/stats-worker-times/before.txt >http://cr.openjdk.java.net/~shade/shenandoah/stats-worker-times/after.txt > >Testing: hotspot_gc_shenandoah, eyeballing gc+stats > >Thanks, >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From cflood at redhat.com Tue Sep 26 11:52:10 2017 From: cflood at redhat.com (Christine Flood) Date: Tue, 26 Sep 2017 07:52:10 -0400 Subject: RFR: Refactor worker timings into ShenandoahPhaseTimings In-Reply-To: References: <1b1d8202-c03e-8c71-eef6-2faa477a4421@redhat.com> Message-ID: I would classify this as a one-peer-reviewer level patch for future reference, but it's fine by me anyway. On Tue, Sep 26, 2017 at 5:10 AM, Roman Kennke wrote: > This looks useful and good to me. > > Roman > > > Am 26. September 2017 10:50:13 MESZ schrieb Aleksey Shipilev < > shade at redhat.com>: > >http://cr.openjdk.java.net/~shade/shenandoah/stats-worker- > times/webrev.01/ > > > >Noticed we now have shenandoahPhaseTimings.(hpp|cpp) and > >shenandoahPhaseTimes.{cpp|hpp}. The latter > >does the per-worker accounting, and merges it back to total counters. > >Moved that into our recently > >added file, and did a few renames to capture those bits are indeed > >about workers. > > > >Does not change the output: > >http://cr.openjdk.java.net/~shade/shenandoah/stats-worker- > times/before.txt > >http://cr.openjdk.java.net/~shade/shenandoah/stats-worker-times/after.txt > > > >Testing: hotspot_gc_shenandoah, eyeballing gc+stats > > > >Thanks, > >-Aleksey > > -- > Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. > From ashipile at redhat.com Tue Sep 26 16:19:36 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Tue, 26 Sep 2017 16:19:36 +0000 Subject: hg: shenandoah/jdk10/hotspot: Refactor worker timings into ShenandoahPhaseTimings Message-ID: <201709261619.v8QGJa6A004131@aojmv0008.oracle.com> Changeset: d36390fde275 Author: shade Date: 2017-09-26 10:53 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/d36390fde275 Refactor worker timings into ShenandoahPhaseTimings ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp - src/share/vm/gc/shenandoah/shenandoahPhaseTimes.cpp - src/share/vm/gc/shenandoah/shenandoahPhaseTimes.hpp ! src/share/vm/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc/shenandoah/shenandoahRootProcessor.cpp From shade at redhat.com Wed Sep 27 08:55:45 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Sep 2017 10:55:45 +0200 Subject: RFR: Bulk backport to sh/jdk9 Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk9-20170927/webrev.01/ Testing: hotspot_gc_shenandoah Thanks, -Aleksey From rkennke at redhat.com Wed Sep 27 09:46:58 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 Sep 2017 11:46:58 +0200 Subject: RFR: Bulk backport to sh/jdk9 In-Reply-To: References: Message-ID: OK. Would be useful to list the changesets that you backport. :-) Roman Am 27. September 2017 10:55:45 MESZ schrieb Aleksey Shipilev : >http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk9-20170927/webrev.01/ > >Testing: hotspot_gc_shenandoah > >Thanks, >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From shade at redhat.com Wed Sep 27 11:15:35 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Sep 2017 13:15:35 +0200 Subject: Problematic backport to 8u: "Ensure tasks use correct number of workers" Message-ID: <7b87d328-a7ad-f9b7-ee04-e69a9b865f34@redhat.com> Tried to backport recent sh/jdk10 patch to sh/jdk8u, and got weird failures: ~/trunks/shenandoah-jdk8/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java -XX:+UseShenandoahGC -XX:ConcGCThreads=2 -XX:ParallelGCThreads=4 -XX:+UnlockDiagnosticVMOptions -Xmx16m -XX:ShenandoahGCHeuristics=aggressive -Dtarget=100 TestGCThreadGroups # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/workgroup.hpp:335 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/shade/trunks/shenandoah-jdk8/hotspot/src/share/vm/utilities/workgroup.hpp:335), pid=49844, tid=0x00007f8d3988d700 # assert(UseDynamicNumberOfGCThreads || _active_workers == _total_workers) failed: Unless dynamic should use total workers It seems the internals of workgroup.hpp are quite different. The patch in question is: http://cr.openjdk.java.net/~shade/shenandoah/shenandoah-8u-dynamic-workers.patch Zhengyu, can you take a look how to adapt this to 8u properly? I'll skip this from backports for time being. Thanks, -Aleksey From rkennke at redhat.com Wed Sep 27 14:21:00 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 Sep 2017 16:21:00 +0200 Subject: RFR: Make Shenandoah SATB mutex ranks consistent with G1 Message-ID: Apparently, upstream changed the ranks of the SATB mutexes from special to access. We missed to do the same. Fix: http://cr.openjdk.java.net/~rkennke/satbmutex/webrev.00/ To be honest, the real fix would be to not declare those mutexes globally, but put it under satbQueue.cpp where they are actually used. But this would have to be done upstream. Ok to push? Roman From rwestrel at redhat.com Wed Sep 27 14:25:43 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Wed, 27 Sep 2017 14:25:43 +0000 Subject: hg: shenandoah/jdk10/hotspot: fix TCK crash with shenandoah Message-ID: <201709271425.v8REPiow019122@aojmv0008.oracle.com> Changeset: c81868f7b73f Author: roland Date: 2017-09-27 15:52 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/c81868f7b73f fix TCK crash with shenandoah ! src/share/vm/opto/shenandoahSupport.cpp From shade at redhat.com Wed Sep 27 14:25:08 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Sep 2017 16:25:08 +0200 Subject: RFR: Make Shenandoah SATB mutex ranks consistent with G1 In-Reply-To: References: Message-ID: <72df22f1-423a-e20f-dcb7-879c3b854f76@redhat.com> On 09/27/2017 04:21 PM, Roman Kennke wrote: > Apparently, upstream changed the ranks of the SATB mutexes from special to access. We missed to do > the same. Fix: > > http://cr.openjdk.java.net/~rkennke/satbmutex/webrev.00/ Looks good and consistent with G1 to me. -Aleksey From cflood at redhat.com Wed Sep 27 14:41:31 2017 From: cflood at redhat.com (Christine Flood) Date: Wed, 27 Sep 2017 10:41:31 -0400 Subject: RFR: Make Shenandoah SATB mutex ranks consistent with G1 In-Reply-To: References: Message-ID: To the best of my knowledge, this looks fine. Christine On Wed, Sep 27, 2017 at 10:21 AM, Roman Kennke wrote: > Apparently, upstream changed the ranks of the SATB mutexes from special to > access. We missed to do the same. Fix: > > http://cr.openjdk.java.net/~rkennke/satbmutex/webrev.00/ < > http://cr.openjdk.java.net/%7Erkennke/satbmutex/webrev.00/> > > To be honest, the real fix would be to not declare those mutexes globally, > but put it under satbQueue.cpp where they are actually used. But this would > have to be done upstream. > > Ok to push? > > Roman > > From roman at kennke.org Wed Sep 27 14:44:53 2017 From: roman at kennke.org (roman at kennke.org) Date: Wed, 27 Sep 2017 14:44:53 +0000 Subject: hg: shenandoah/jdk10/hotspot: Make Shenandoah SATB mutex ranks consistent with G1. Message-ID: <201709271444.v8REirfn027904@aojmv0008.oracle.com> Changeset: dca8cd877e02 Author: rkennke Date: 2017-09-27 16:35 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/dca8cd877e02 Make Shenandoah SATB mutex ranks consistent with G1. ! src/share/vm/runtime/mutexLocker.cpp From shade at redhat.com Wed Sep 27 14:43:11 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Sep 2017 16:43:11 +0200 Subject: RFR: Refactor conc-mark-in-progress/satb-active flags to use gc-phase-in-progress In-Reply-To: <4b5ea38b-6eea-44a6-f2f0-300c749daaf2@redhat.com> References: <4b5ea38b-6eea-44a6-f2f0-300c749daaf2@redhat.com> Message-ID: On 09/25/2017 06:59 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.02/ So I am not happy with refactoring G1 codepaths: this will pose problems with merging from upstream, problems with backports, problems with testing, etc. Copy-paste Shenandoah paths out (that would probably disentangle Shenandoah going via g1_* stubs too?), and then we wait for GC interface to arrive to remove that copy-paste. Thanks, -Aleksey From rwestrel at redhat.com Wed Sep 27 15:18:36 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 27 Sep 2017 17:18:36 +0200 Subject: FYI: rework previous fix Message-ID: I intend to push the following change: http://cr.openjdk.java.net/~roland/shenandoah/outofloop_wb_correctphi/webrev.00/ It undoes a fix that I pushed some time ago. That fix is the one that caused us trouble on 8u recently (high memory consumption when not using shenandoah). Looking at that fix again, I think an alternate fix would be robuster. I couldn't reproduce the failure that lead to the fix so I couldn't verify the alternate fix but all testing I've done shown no new problem. Roland. From shade at redhat.com Wed Sep 27 15:25:34 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Sep 2017 17:25:34 +0200 Subject: FYI: rework previous fix In-Reply-To: References: Message-ID: <2a93a33e-7610-4fe0-6e95-41f20f674486@redhat.com> On 09/27/2017 05:18 PM, Roland Westrelin wrote: > I intend to push the following change: > > http://cr.openjdk.java.net/~roland/shenandoah/outofloop_wb_correctphi/webrev.00/ This seems to revert our differences around has_only_data_users() against upstream in favor of this one-liner, right? 878 } else if (in->Opcode() == Op_CMoveP || in->Opcode() == Op_CMoveN) { Looks good to me. Make sure you have descriptive commit message! Thanks, -Aleksey From rwestrel at redhat.com Wed Sep 27 15:45:27 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 27 Sep 2017 17:45:27 +0200 Subject: FYI: rework previous fix In-Reply-To: <2a93a33e-7610-4fe0-6e95-41f20f674486@redhat.com> References: <2a93a33e-7610-4fe0-6e95-41f20f674486@redhat.com> Message-ID: > This seems to revert our differences around has_only_data_users() > against upstream in favor of this one-liner, right? Not quite. This below is new: @@ -2520,12 +2495,6 @@ Node* n_loop_head = n_loop->_head; if (n_loop_head->is_Loop()) { - int alias = phase->C->get_alias_index(adr_type()); - Node* mem = find_mem_phi(n_loop_head, alias, phase->C); - if (mem == NULL) { - mem = in(Memory); - } - LoopNode* loop = n_loop_head->as_Loop(); if (n_loop_head->is_CountedLoop() && n_loop_head->as_CountedLoop()->is_main_loop()) { LoopNode* res = try_move_before_pre_loop(n_loop_head->in(LoopNode::EntryControl), val_ctrl, phase); > 878 } else if (in->Opcode() == Op_CMoveP || in->Opcode() == Op_CMoveN) { That's a fix for the verification pass so it's unrelated. > Make sure you have descriptive commit message! Won't history all be lost when things are upstreamed so we should rather put comments? Here is the explanation: When a WB is moved out of loop, we must hook its memory edges out of the loop and that's done by finding the memory Phi for that memory slice at the loop head. The bug is that the WB can be connected to a Phi that is later optimized out and then the WB is no longer connected correctly to the memory graph. That happens when the loop has a memory Phi for bottom memory and a memory Phi for the WB memory slice. The Phi on the WB memory slice may only have data uses. If the data uses go away, then the Phi goes away as well. The current code finds the Phi by looking at all Phis for the loop and picking the most specific one so it could pick the wrong phi. The previous fix was to locate phis with only data uses and move uses off that phi to the bottom phi. The fix now, is to not find the phi at the loop by looking at all loop phis but instead to start from the WB in the loop, follow memory edges until the loop and use the phi that is there which I believe is safe. Roland. From shade at redhat.com Wed Sep 27 15:52:33 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Sep 2017 17:52:33 +0200 Subject: FYI: rework previous fix In-Reply-To: References: <2a93a33e-7610-4fe0-6e95-41f20f674486@redhat.com> Message-ID: <8a52d115-d9b0-36f3-08b4-b086d42021d9@redhat.com> On 09/27/2017 05:45 PM, Roland Westrelin wrote: >> This seems to revert our differences around has_only_data_users() >> against upstream in favor of this one-liner, right? > > Not quite. This below is new: > > - int alias = phase->C->get_alias_index(adr_type()); > - Node* mem = find_mem_phi(n_loop_head, alias, phase->C); > - if (mem == NULL) { > - mem = in(Memory); > - } > - Okay then. The actual fix is still within the Shenandoah-specific code, and so we are good. >> Make sure you have descriptive commit message! > > Won't history all be lost when things are upstreamed so we should rather > put comments? It would be lost, right. But I'm mostly concerned with tracking the changes flowing between our repositories at this point. Having a commit message "Revert unsuccessful fix for WB hoisting, replace it with <...>" makes it stand out. Thanks, -Aleksey From shade at redhat.com Wed Sep 27 17:11:20 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Sep 2017 19:11:20 +0200 Subject: RFR: Bulk backport to sh/jdk8u Message-ID: <79e4d76c-e9bf-2de6-a459-d9727f59a2a6@redhat.com> http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20170927/webrev.01/ Includes: rev 10119 : [backport] Verify regions status rev 10120 : [backport] Asynchronous region recycling rev 10121 : [backport] Heap region sampling should publish region states rev 10122 : [backport] Store checks should run most of the time rev 10123 : [backport] FreeSet refactor: bitmaps, cursors, biasing rev 10124 : [backport] Trim the TLAB sizes to avoid wasteful retirement under TLAB races rev 10125 : [backport] Adaptive collection set selection in adaptive policy rev 10126 : [backport] Make heap counters update completely asynchronous rev 10127 : [backport] Adaptive heuristics accounts trashed cset twice Testing: hotspot_gc_shenandoah (There are some interesting test timeouts that are present even with current 8u, trying to resolve them separately) Thanks, -Aleksey From aph at redhat.com Wed Sep 27 17:33:02 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Sep 2017 18:33:02 +0100 Subject: RFR: Bulk backport to sh/jdk8u In-Reply-To: <79e4d76c-e9bf-2de6-a459-d9727f59a2a6@redhat.com> References: <79e4d76c-e9bf-2de6-a459-d9727f59a2a6@redhat.com> Message-ID: <13605f61-8d07-74ad-74ab-456ca028d6ab@redhat.com> 5111 // During evacuation and evacuation only, we can have the stores of cset-values 5112 // to non-cset destinations. Everything else is covered by storeval barriers. 5113 mov(tmp1, ShenandoahHeap::evacuation_in_progress_addr()); 5114 ldrw(tmp1, Address(tmp1)); 5115 cbnzw(tmp1, done); Looks reasonable, but in jdk8 is evacuation_in_progress not a field in the thread? -- 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 Wed Sep 27 18:15:02 2017 From: roman at kennke.org (roman at kennke.org) Date: Wed, 27 Sep 2017 18:15:02 +0000 Subject: hg: shenandoah/jdk10/hotspot: Remove obsolete and unused reduce-storeval-barrier optimization code. Message-ID: <201709271815.v8RIF2U8018140@aojmv0008.oracle.com> Changeset: 09bb36a01778 Author: rkennke Date: 2017-09-16 11:36 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/09bb36a01778 Remove obsolete and unused reduce-storeval-barrier optimization code. ! src/share/vm/gc/shenandoah/shenandoah_globals.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/library_call.cpp From shade at redhat.com Wed Sep 27 19:09:39 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Sep 2017 21:09:39 +0200 Subject: RFR: Bulk backport to sh/jdk8u In-Reply-To: <13605f61-8d07-74ad-74ab-456ca028d6ab@redhat.com> References: <79e4d76c-e9bf-2de6-a459-d9727f59a2a6@redhat.com> <13605f61-8d07-74ad-74ab-456ca028d6ab@redhat.com> Message-ID: <58a84f27-fef8-9a6f-32dd-e9bb69064ebf@redhat.com> On 09/27/2017 07:33 PM, Andrew Haley wrote: > 5111 // During evacuation and evacuation only, we can have the stores of cset-values > 5112 // to non-cset destinations. Everything else is covered by storeval barriers. > 5113 mov(tmp1, ShenandoahHeap::evacuation_in_progress_addr()); > 5114 ldrw(tmp1, Address(tmp1)); > 5115 cbnzw(tmp1, done); > > Looks reasonable, but in jdk8 is evacuation_in_progress not a field in the > thread? Yes, we can poll it off TLS, like the write barrier does. But for the checking/debugging code like this, it makes more sense to test the closest source of truth: the global heap variable, instead of going via optimized TLS flag. If TLS flag setter fails, then prior WB/storeval silently fails, and then this checking code will capture the inconsistency. IIRC, we did experience TLS setting failure once, this is when we beefed up on store checks! We may consider rehashing changing all of these later, all at once, though unlikely for the reasons above. Thanks, -Aleksey From aph at redhat.com Thu Sep 28 09:05:06 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 Sep 2017 10:05:06 +0100 Subject: RFR: Bulk backport to sh/jdk8u In-Reply-To: <58a84f27-fef8-9a6f-32dd-e9bb69064ebf@redhat.com> References: <79e4d76c-e9bf-2de6-a459-d9727f59a2a6@redhat.com> <13605f61-8d07-74ad-74ab-456ca028d6ab@redhat.com> <58a84f27-fef8-9a6f-32dd-e9bb69064ebf@redhat.com> Message-ID: On 27/09/17 20:09, Aleksey Shipilev wrote: > On 09/27/2017 07:33 PM, Andrew Haley wrote: >> 5111 // During evacuation and evacuation only, we can have the stores of cset-values >> 5112 // to non-cset destinations. Everything else is covered by storeval barriers. >> 5113 mov(tmp1, ShenandoahHeap::evacuation_in_progress_addr()); >> 5114 ldrw(tmp1, Address(tmp1)); >> 5115 cbnzw(tmp1, done); >> >> Looks reasonable, but in jdk8 is evacuation_in_progress not a field in the >> thread? > > Yes, we can poll it off TLS, like the write barrier does. But for the checking/debugging code like > this, it makes more sense to test the closest source of truth: the global heap variable, instead of > going via optimized TLS flag. If TLS flag setter fails, then prior WB/storeval silently fails, and > then this checking code will capture the inconsistency. IIRC, we did experience TLS setting failure > once, this is when we beefed up on store checks! OK, but such subtle reasoning demands a comment in the code. -- 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 Thu Sep 28 09:38:22 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 28 Sep 2017 11:38:22 +0200 Subject: RFR: Refactor conc-mark-in-progress/satb-active flags to use gc-phase-in-progress In-Reply-To: References: <4b5ea38b-6eea-44a6-f2f0-300c749daaf2@redhat.com> Message-ID: <4cff1fb0-c7fa-0d7b-55d8-18aac6619efc@redhat.com> Am 27.09.2017 um 16:43 schrieb Aleksey Shipilev: > On 09/25/2017 06:59 PM, Roman Kennke wrote: >> http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.02/ > So I am not happy with refactoring G1 codepaths: this will pose problems with merging from upstream, > problems with backports, problems with testing, etc. Copy-paste Shenandoah paths out (that would > probably disentangle Shenandoah going via g1_* stubs too?), and then we wait for GC interface to > arrive to remove that copy-paste. Ok, I see your point. I changed the barrier code as you suggested and leave G1 barriers alone. Tested again on x86 and aarch64: hotspot_gc_shenandoah http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.03/ Ok now? From aph at redhat.com Thu Sep 28 10:07:44 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 Sep 2017 11:07:44 +0100 Subject: RFR: Refactor conc-mark-in-progress/satb-active flags to use gc-phase-in-progress In-Reply-To: <4cff1fb0-c7fa-0d7b-55d8-18aac6619efc@redhat.com> References: <4b5ea38b-6eea-44a6-f2f0-300c749daaf2@redhat.com> <4cff1fb0-c7fa-0d7b-55d8-18aac6619efc@redhat.com> Message-ID: <10900e12-9cac-d1a8-e5a1-19eb40e7ba5a@redhat.com> On 28/09/17 10:38, Roman Kennke wrote: > Am 27.09.2017 um 16:43 schrieb Aleksey Shipilev: >> On 09/25/2017 06:59 PM, Roman Kennke wrote: >>> http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.02/ >> So I am not happy with refactoring G1 codepaths: this will pose problems with merging from upstream, >> problems with backports, problems with testing, etc. Copy-paste Shenandoah paths out (that would >> probably disentangle Shenandoah going via g1_* stubs too?), and then we wait for GC interface to >> arrive to remove that copy-paste. > Ok, I see your point. I changed the barrier code as you suggested and > leave G1 barriers alone. > > Tested again on x86 and aarch64: hotspot_gc_shenandoah > > http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.03/ > > > Ok now? Assert this: + // (The index field is typed as size_t.) + add(tmp, tmp, rscratch1); // tmp := tmp + *buffer_adr + + // Record the previous value + str(pre_val, Address(tmp, 0)); Should be str(pre_val, Address(tmp, rscratch1); This comment is wrong: + } else if (UseShenandoahGC && ShenandoahKeepAliveBarrier) { + enter(); // g1_write may call runtime -- 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 Thu Sep 28 10:34:42 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 28 Sep 2017 12:34:42 +0200 Subject: RFR: Improve AArch64 matrix barrier (was: Re: RFR: Fix, improve and refactor matrix barrier on AAarch64) In-Reply-To: <60d5dfd6-fc29-5d87-70dc-1e674100113e@redhat.com> References: <663e9c13-6139-4781-43c0-cd20b259310c@redhat.com> <9523f308-a01f-bb3b-0182-fc15e706e476@redhat.com> <1fb68f54-1c70-6601-5c76-17abc249de63@redhat.com> <2be8f1fc-ff13-867a-e8d7-ba03ced758b2@redhat.com> <60d5dfd6-fc29-5d87-70dc-1e674100113e@redhat.com> Message-ID: <5d65d320-bf45-f317-d136-0eb87ebe6154@redhat.com> Am 25.09.2017 um 12:01 schrieb Andrew Haley: > On 14/09/17 16:20, Aleksey Shipilev wrote: >> On 09/14/2017 05:19 PM, Roman Kennke wrote: >>>>> http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.01/ >>>> Good, except for rscratch1 change. >>> Ok, I made it a compromise: kept the method signature the same (i.e. 2 tmp args), and declare tmp3 >>> at the beginning of the code block to be rscratch1. >>> >>> http://cr.openjdk.java.net/~rkennke/fix-matrix-barrier-aarch64/webrev.02/ > This is confusing code. Giving rscratch1 a name like "tmp3" doesn't > help anyone, and it adds risk because many macros implicitly clobber > rscratch1. Something like this (untested) is clearer: > > // Compute matrix index > > mov(rscratch1, matrix->stride_jint()); > // Address is _matrix[to * stride + from] > madd(tmp, tmp, rscratch1, tmp2); > mov(rscratch1, matrix->magic_offset()); > Address loc(tmp, rscratch1); > > ldrb(tmp2, loc); > cbnzw(tmp2, done); > mov(tmp2, 1); > strb(tmp2, loc); > bind(done); Yes, this is indeed better. Tested on aarch64 using hotspot_gc_shenandoah jtreg tests: http://cr.openjdk.java.net/~rkennke/fix-aarch64-matrix-barrier/webrev.00/ Ok to push? Roman From shade at redhat.com Thu Sep 28 14:45:34 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 Sep 2017 16:45:34 +0200 Subject: RFR: Bulk backport to sh/jdk8u In-Reply-To: References: <79e4d76c-e9bf-2de6-a459-d9727f59a2a6@redhat.com> <13605f61-8d07-74ad-74ab-456ca028d6ab@redhat.com> <58a84f27-fef8-9a6f-32dd-e9bb69064ebf@redhat.com> Message-ID: On 09/28/2017 11:05 AM, Andrew Haley wrote: > On 27/09/17 20:09, Aleksey Shipilev wrote: >> On 09/27/2017 07:33 PM, Andrew Haley wrote: >>> 5111 // During evacuation and evacuation only, we can have the stores of cset-values >>> 5112 // to non-cset destinations. Everything else is covered by storeval barriers. >>> 5113 mov(tmp1, ShenandoahHeap::evacuation_in_progress_addr()); >>> 5114 ldrw(tmp1, Address(tmp1)); >>> 5115 cbnzw(tmp1, done); >>> >>> Looks reasonable, but in jdk8 is evacuation_in_progress not a field in the >>> thread? >> >> Yes, we can poll it off TLS, like the write barrier does. But for the checking/debugging code like >> this, it makes more sense to test the closest source of truth: the global heap variable, instead of >> going via optimized TLS flag. If TLS flag setter fails, then prior WB/storeval silently fails, and >> then this checking code will capture the inconsistency. IIRC, we did experience TLS setting failure >> once, this is when we beefed up on store checks! > > OK, but such subtle reasoning demands a comment in the code. Noted for later, we would need to rehash all the checking code to capture this. -Aleksey From ashipile at redhat.com Thu Sep 28 14:55:21 2017 From: ashipile at redhat.com (ashipile at redhat.com) Date: Thu, 28 Sep 2017 14:55:21 +0000 Subject: hg: shenandoah/jdk9/hotspot: 3 new changesets Message-ID: <201709281455.v8SEtLKG008828@aojmv0008.oracle.com> Changeset: 7e7bd1aef661 Author: shade Date: 2017-09-25 15:43 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/7e7bd1aef661 [backport] Concurrent cleanup after partial GC gets accounted in gross pause ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp Changeset: 89cd7ddd13ed Author: zgu Date: 2017-09-25 12:54 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/89cd7ddd13ed [backport] Refactoring GC phase and heap allocation tracking out of policy + src/share/vm/gc/shenandoah/shenandoahAllocTracker.cpp + src/share/vm/gc/shenandoah/shenandoahAllocTracker.hpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc/shenandoah/shenandoahConcurrentThread.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc/shenandoah/shenandoahPartialGC.cpp + src/share/vm/gc/shenandoah/shenandoahPhaseTimings.cpp + src/share/vm/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc/shenandoah/vm_operations_shenandoah.cpp Changeset: ea93a97cb3f5 Author: shade Date: 2017-09-26 10:53 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/ea93a97cb3f5 [backport] Refactor worker timings into ShenandoahPhaseTimings ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc/shenandoah/shenandoahCollectorPolicy.hpp - src/share/vm/gc/shenandoah/shenandoahPhaseTimes.cpp - src/share/vm/gc/shenandoah/shenandoahPhaseTimes.hpp ! src/share/vm/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc/shenandoah/shenandoahRootProcessor.cpp From rwestrel at redhat.com Thu Sep 28 15:27:49 2017 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Thu, 28 Sep 2017 15:27:49 +0000 Subject: hg: shenandoah/jdk10/hotspot: When Shenandoah WB is moved out of loop, connect it to correct loop memory Phi (back out and revisit previous fix) Message-ID: <201709281527.v8SFRn2W021791@aojmv0008.oracle.com> Changeset: 927e9eafe4f0 Author: roland Date: 2017-09-27 16:55 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/927e9eafe4f0 When Shenandoah WB is moved out of loop, connect it to correct loop memory Phi (back out and revisit previous fix) ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/shenandoahSupport.cpp From rwestrel at redhat.com Fri Sep 29 09:39:49 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 29 Sep 2017 11:39:49 +0200 Subject: RFR: remove loop strip mining and profiled loop predication from 9 Message-ID: http://cr.openjdk.java.net/~roland/shenandoah/dropstripmining_9/webrev.00/ From rkennke at redhat.com Fri Sep 29 09:49:33 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 29 Sep 2017 11:49:33 +0200 Subject: RFR: remove loop strip mining and profiled loop predication from 9 In-Reply-To: References: Message-ID: <76750166-e4e0-3fbf-7f85-ad8519ef0dc5@redhat.com> Am 29.09.2017 um 11:39 schrieb Roland Westrelin: > http://cr.openjdk.java.net/~roland/shenandoah/dropstripmining_9/webrev.00/ > Wow this is a big one...! I assume you have run at least hotspot_gc_shenandoah or preferably some c2 tests? Other than that I think it's good. Roman From aph at redhat.com Fri Sep 29 13:44:08 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 29 Sep 2017 14:44:08 +0100 Subject: RFR: Improve AArch64 matrix barrier In-Reply-To: <5d65d320-bf45-f317-d136-0eb87ebe6154@redhat.com> References: <663e9c13-6139-4781-43c0-cd20b259310c@redhat.com> <9523f308-a01f-bb3b-0182-fc15e706e476@redhat.com> <1fb68f54-1c70-6601-5c76-17abc249de63@redhat.com> <2be8f1fc-ff13-867a-e8d7-ba03ced758b2@redhat.com> <60d5dfd6-fc29-5d87-70dc-1e674100113e@redhat.com> <5d65d320-bf45-f317-d136-0eb87ebe6154@redhat.com> Message-ID: <09f347bc-9206-83c9-0803-312d849a49f9@redhat.com> On 28/09/17 11:34, Roman Kennke wrote: > Yes, this is indeed better. Tested on aarch64 using > hotspot_gc_shenandoah jtreg tests: > http://cr.openjdk.java.net/~rkennke/fix-aarch64-matrix-barrier/webrev.00/ > > > Ok to push? OK, thanks. -- 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 Fri Sep 29 13:51:36 2017 From: roman at kennke.org (roman at kennke.org) Date: Fri, 29 Sep 2017 13:51:36 +0000 Subject: hg: shenandoah/jdk10/hotspot: Improve AArch64 matrix barrier. Message-ID: <201709291351.v8TDpauQ023181@aojmv0008.oracle.com> Changeset: 533d1c8a56d2 Author: rkennke Date: 2017-09-29 13:46 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk10/hotspot/rev/533d1c8a56d2 Improve AArch64 matrix barrier. ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp From rkennke at redhat.com Fri Sep 29 14:59:41 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 29 Sep 2017 16:59:41 +0200 Subject: RFR: Refactor conc-mark-in-progress/satb-active flags to use gc-phase-in-progress In-Reply-To: <10900e12-9cac-d1a8-e5a1-19eb40e7ba5a@redhat.com> References: <4b5ea38b-6eea-44a6-f2f0-300c749daaf2@redhat.com> <4cff1fb0-c7fa-0d7b-55d8-18aac6619efc@redhat.com> <10900e12-9cac-d1a8-e5a1-19eb40e7ba5a@redhat.com> Message-ID: <3d0b4b5d-e76f-693a-94a6-344485e9c3a2@redhat.com> Am 28.09.2017 um 12:07 schrieb Andrew Haley: > On 28/09/17 10:38, Roman Kennke wrote: >> Am 27.09.2017 um 16:43 schrieb Aleksey Shipilev: >>> On 09/25/2017 06:59 PM, Roman Kennke wrote: >>>> http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.02/ >>> So I am not happy with refactoring G1 codepaths: this will pose problems with merging from upstream, >>> problems with backports, problems with testing, etc. Copy-paste Shenandoah paths out (that would >>> probably disentangle Shenandoah going via g1_* stubs too?), and then we wait for GC interface to >>> arrive to remove that copy-paste. >> Ok, I see your point. I changed the barrier code as you suggested and >> leave G1 barriers alone. >> >> Tested again on x86 and aarch64: hotspot_gc_shenandoah >> >> http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.03/ >> >> >> Ok now? > Assert this: > > + // (The index field is typed as size_t.) > > + add(tmp, tmp, rscratch1); // tmp := tmp + *buffer_adr > + > + // Record the previous value > + str(pre_val, Address(tmp, 0)); > > Should be > > str(pre_val, Address(tmp, rscratch1); > > This comment is wrong: > > + } else if (UseShenandoahGC && ShenandoahKeepAliveBarrier) { > + enter(); // g1_write may call runtime > Right, this looks better. This code is copy+pasted from upstream G1 barrier code. Do you think it's worth opening a bug upstream? http://cr.openjdk.java.net/~rkennke/satb-concmark-flag/webrev.04/ Tested again on aarch64: hotspot_gc_shenandoah Roman