From shade at redhat.com Mon Apr 1 09:51:03 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 1 Apr 2019 11:51:03 +0200 Subject: RFR (XS) 8221735: Shenandoah fails ctw/modules/jdk_management_agent.java with Traversal Message-ID: <9f118a36-d8f2-22e7-aec4-a9f3e6887f11@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8221735 Fix: diff -r e0603b4537c3 src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp --- a/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Mon Apr 01 10:04:22 2019 +0200 +++ b/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Mon Apr 01 11:49:36 2019 +0200 @@ -3398,10 +3398,11 @@ } int ShenandoahEnqueueBarrierNode::needed(Node* n) { if (n == NULL || n->is_Allocate() || + n->Opcode() == Op_ShenandoahEnqueueBarrier || n->bottom_type() == TypePtr::NULL_PTR || (n->bottom_type()->make_oopptr() != NULL && n->bottom_type()->make_oopptr()->const_oop() != NULL)) { return NotNeeded; } if (n->is_Phi() || Testing: hotspot_gc_shenandoah, ctw tests for both jdk/jdk and sh/jdk -- Thanks, -Aleksey From rkennke at redhat.com Mon Apr 1 11:25:16 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 1 Apr 2019 13:25:16 +0200 Subject: RFR (XS) 8221735: Shenandoah fails ctw/modules/jdk_management_agent.java with Traversal In-Reply-To: <9f118a36-d8f2-22e7-aec4-a9f3e6887f11@redhat.com> References: <9f118a36-d8f2-22e7-aec4-a9f3e6887f11@redhat.com> Message-ID: Yes, good! Thanks! Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221735 > > Fix: > > diff -r e0603b4537c3 src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp > --- a/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Mon Apr 01 10:04:22 2019 +0200 > +++ b/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Mon Apr 01 11:49:36 2019 +0200 > @@ -3398,10 +3398,11 @@ > } > > int ShenandoahEnqueueBarrierNode::needed(Node* n) { > if (n == NULL || > n->is_Allocate() || > + n->Opcode() == Op_ShenandoahEnqueueBarrier || > n->bottom_type() == TypePtr::NULL_PTR || > (n->bottom_type()->make_oopptr() != NULL && n->bottom_type()->make_oopptr()->const_oop() != > NULL)) { > return NotNeeded; > } > if (n->is_Phi() || > > > Testing: hotspot_gc_shenandoah, ctw tests for both jdk/jdk and sh/jdk > From rwestrel at redhat.com Mon Apr 1 11:32:49 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 01 Apr 2019 13:32:49 +0200 Subject: RFR (XS) 8221735: Shenandoah fails ctw/modules/jdk_management_agent.java with Traversal In-Reply-To: <9f118a36-d8f2-22e7-aec4-a9f3e6887f11@redhat.com> References: <9f118a36-d8f2-22e7-aec4-a9f3e6887f11@redhat.com> Message-ID: <87o95qq7tq.fsf@redhat.com> Looks good to me. Roland. From zgu at redhat.com Mon Apr 1 13:26:21 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 1 Apr 2019 09:26:21 -0400 Subject: RFR: 8220602: Shenandoah-SA: Enable best-effort implementation of heap walk In-Reply-To: References: Message-ID: <7eb10ba1-e586-e7f1-aeef-500ced0edeff@redhat.com> Hi, May I get review from serviceability? as it has minor changes in shared code (CollectedHeap.java and ObjectHeap.java) Thanks, -Zhengyu On 3/14/19 11:37 AM, Zhengyu Gu wrote: > Please review this patch that provides best-effort implementation of > live regions iteration for Shenandoah GC. > > There are minor changes in shared code, to adjust oop offset from base > of allocation cell. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220602 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8220602/webrev.00/index.html > > > Test: > ? hotspot_gc_shenandoah > ? hotspot_serviceability > ? vmTestbase/nsk/jdb > ? manual test: jhsdb hsdb > ? on Linux x64 > > ? Passed submit test. > > > Thanks, > > -Zhengyu From rkennke at redhat.com Mon Apr 1 13:41:09 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 1 Apr 2019 15:41:09 +0200 Subject: RFR: JDK-8221751: Shenandoah: Improve SATB enqueueing Message-ID: <2be2148c-24eb-986a-8621-3e45e93a30fa@redhat.com> In some paths, we currently check GC state 3 times before enqueueing an oop in SATB buffer: 1. conc-mark in progress (global or local), 2. SATB active (global) 3. SATB active (local). This should be streamlined to only do one check, and consistently check conc-mark-in-progress only. This can be taken even further for arraycopy pre-barriers and arraycopy-loops, where the check can be done once for the whole operation. In arraycopy barriers code, we can also 'inline' the current thread and marking context objects, instead of fetching them for every array element. Bug: https://bugs.openjdk.java.net/browse/JDK-8221751 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8221751/webrev.00/ Testing: hotspot_gc_shenandoah ok Good? Roman From rkennke at redhat.com Mon Apr 1 13:49:00 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 1 Apr 2019 15:49:00 +0200 Subject: RFR: JDK-8221750: Shenandoah: Enable ThreadLocalHandshake by default Message-ID: <3b683274-bdd7-f965-b603-90271c7d4c6c@redhat.com> Back when ThreadLocalHandshake has been introduced, we needed to disable it in Shenandoah, because it caused a problem in the serial benchmark, together with traversal mode, which would cause the application to hang. This has never been explained. However, the problem no longer seems to exist, and we shall enable TLHS by default. This also seems to improve latency. Bug: https://bugs.openjdk.java.net/browse/JDK-8221750 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8221750/webrev.00/ Testing: The patch has been baked in shenandoah/jdk for a while and undergone our rigourous CI testing. I've also run hotspot_gc_shenandoah locally again. ok? Roman From shade at redhat.com Mon Apr 1 13:54:11 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 1 Apr 2019 15:54:11 +0200 Subject: RFR: JDK-8221750: Shenandoah: Enable ThreadLocalHandshake by default In-Reply-To: <3b683274-bdd7-f965-b603-90271c7d4c6c@redhat.com> References: <3b683274-bdd7-f965-b603-90271c7d4c6c@redhat.com> Message-ID: On 4/1/19 3:49 PM, Roman Kennke wrote: > Back when ThreadLocalHandshake has been introduced, we needed to disable it in Shenandoah, because > it caused a problem in the serial benchmark, together with traversal mode, which would cause the > application to hang. This has never been explained. However, the problem no longer seems to exist, > and we shall enable TLHS by default. This also seems to improve latency. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221750 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8221750/webrev.00/ Looks good. -Aleksey From simone.bordet at gmail.com Mon Apr 1 15:12:07 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 1 Apr 2019 17:12:07 +0200 Subject: Weak Ref Processing Message-ID: Hi, I'm preparing for a conference session about Shenandoah (and ZGC), and I would like to confirm how Shenandoah does Weak (et al.) Reference Processing. As far as I understand, weak reference processing is still a STW operation during the final mark phase, so GC parallel but not GC concurrent. Is that correct? Is there any plan to make it concurrent, if not already? Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From shade at redhat.com Mon Apr 1 15:23:26 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 1 Apr 2019 17:23:26 +0200 Subject: Weak Ref Processing In-Reply-To: References: Message-ID: On 4/1/19 5:12 PM, Simone Bordet wrote: > I'm preparing for a conference session about Shenandoah (and ZGC), and > I would like to confirm how Shenandoah does Weak (et al.) Reference > Processing. > > As far as I understand, weak reference processing is still a STW > operation during the final mark phase, so GC parallel but not GC > concurrent. Is that correct? Depends on what "processing" means. The performance model for weakrefs is a bit complicated. Discovery (figuring out the references that exist in heap) is still done concurrently during concurrent mark. Precleaning (purging the references that have definitely alive referents) is done concurrently after mark. Processing (figuring out what to do with references that have dead referents, for example, clearing them or marking through the reachable referent) is done in final-mark STW pause. Enqueueuing (putting references on associated ReferenceQueue, if any), is done in final-mark STW pause as well. So, the pause time depends on the weak references _churn_. For references+referents that stay alive there is little to no overhead (because precleaning takes care of them). For references that die along with referents, the cost is zero (because discovery never finds them). For references that have always clear referents (i.e. everything except finalizable), the processing cost does not involve marking through the suddenly reachable subgraph, so the cost is also low, but not as low as you might want, hence the desire to have concurrent reference processing. Reference processing is performed by multiple parallel workers. When in pause, it is guided by ParallelGCThreads. In concurrent mode, by ConcGCThreads, and mostly piggybacking on the actual GC threads that do the marking. > Is there any plan to make it concurrent, if not already? Roman had a prototype, I would let him talk about it. -Aleksey From rkennke at redhat.com Mon Apr 1 15:34:34 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 1 Apr 2019 17:34:34 +0200 Subject: Weak Ref Processing In-Reply-To: References: Message-ID: >> I'm preparing for a conference session about Shenandoah (and ZGC), and >> I would like to confirm how Shenandoah does Weak (et al.) Reference >> Processing. >> >> As far as I understand, weak reference processing is still a STW >> operation during the final mark phase, so GC parallel but not GC >> concurrent. Is that correct? > > Depends on what "processing" means. The performance model for weakrefs is a bit complicated. > > Discovery (figuring out the references that exist in heap) is still done concurrently during > concurrent mark. Precleaning (purging the references that have definitely alive referents) is done > concurrently after mark. Processing (figuring out what to do with references that have dead > referents, for example, clearing them or marking through the reachable referent) is done in > final-mark STW pause. Enqueueuing (putting references on associated ReferenceQueue, if any), is done > in final-mark STW pause as well. > > So, the pause time depends on the weak references _churn_. For references+referents that stay alive > there is little to no overhead (because precleaning takes care of them). For references that die > along with referents, the cost is zero (because discovery never finds them). For references that > have always clear referents (i.e. everything except finalizable), the processing cost does not > involve marking through the suddenly reachable subgraph, so the cost is also low, but not as low as > you might want, hence the desire to have concurrent reference processing. > > Reference processing is performed by multiple parallel workers. When in pause, it is guided by > ParallelGCThreads. In concurrent mode, by ConcGCThreads, and mostly piggybacking on the actual GC > threads that do the marking. Summary is that for most normal-behaving applications, the extra cost for ref-processing is very few ms. To make it a little more precise: the only way we can hit until-then-undiscovered reachable subgraphs is via finalizers. If your application doesn't make funny use of it, you should be good. However, this new 'finalizable' subgraph is theoretically unbounded, and marking through that newly discovered subgraphs behind finalizers can, theoretically, involve marking through a significant part of the heap and cost time. In practice, we've never seen that happen (most applications nowadays seem to be well-behaved ;-) ) >> Is there any plan to make it concurrent, if not already? > > Roman had a prototype, I would let him talk about it. Yeah, we have a plan, and I have some code that already implements part of it, but no ETA when it will be ready. I keep getting side-tracked with $STUFF. ;-) Roman From simone.bordet at gmail.com Mon Apr 1 16:19:38 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 1 Apr 2019 18:19:38 +0200 Subject: Weak Ref Processing In-Reply-To: References: Message-ID: Hi, On Mon, Apr 1, 2019 at 5:34 PM Roman Kennke wrote: > > >> I'm preparing for a conference session about Shenandoah (and ZGC), and > >> I would like to confirm how Shenandoah does Weak (et al.) Reference > >> Processing. > >> > >> As far as I understand, weak reference processing is still a STW > >> operation during the final mark phase, so GC parallel but not GC > >> concurrent. Is that correct? > > > > Depends on what "processing" means. The performance model for weakrefs is a bit complicated. > > > > Discovery (figuring out the references that exist in heap) is still done concurrently during > > concurrent mark. Precleaning (purging the references that have definitely alive referents) is done > > concurrently after mark. Processing (figuring out what to do with references that have dead > > referents, for example, clearing them or marking through the reachable referent) is done in > > final-mark STW pause. Enqueueuing (putting references on associated ReferenceQueue, if any), is done > > in final-mark STW pause as well. > > > > So, the pause time depends on the weak references _churn_. For references+referents that stay alive > > there is little to no overhead (because precleaning takes care of them). For references that die > > along with referents, the cost is zero (because discovery never finds them). For references that > > have always clear referents (i.e. everything except finalizable), the processing cost does not > > involve marking through the suddenly reachable subgraph, so the cost is also low, but not as low as > > you might want, hence the desire to have concurrent reference processing. > > > > Reference processing is performed by multiple parallel workers. When in pause, it is guided by > > ParallelGCThreads. In concurrent mode, by ConcGCThreads, and mostly piggybacking on the actual GC > > threads that do the marking. > > Summary is that for most normal-behaving applications, the extra cost > for ref-processing is very few ms. > > To make it a little more precise: the only way we can hit > until-then-undiscovered reachable subgraphs is via finalizers. If your > application doesn't make funny use of it, you should be good. However, > this new 'finalizable' subgraph is theoretically unbounded, and marking > through that newly discovered subgraphs behind finalizers can, > theoretically, involve marking through a significant part of the heap > and cost time. In practice, we've never seen that happen (most > applications nowadays seem to be well-behaved ;-) ) Thanks for your answers! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From michal.frajt at luxonit.com Mon Apr 1 16:39:03 2019 From: michal.frajt at luxonit.com (Ing. Michal Frajt (Luxonit s.r.o.)) Date: Mon, 1 Apr 2019 18:39:03 +0200 Subject: Weak Ref Processing Message-ID: <022801d4e8a9$6fa86150$4ef923f0$@luxonit.com> > because precleaning takes care of them The precleaning running in the concurrent cycle (Traversal Mode) takes in our case significant portion of the concurrent cycle. Not sure, but the source code indicates to me that the precleaning is done with 1 worker only (not using all ConcGCThreads threads available). Something to be improved? > Enqueueuing (putting references on associated ReferenceQueue, if any), is done in final-mark STW pause as well. Enqueueuing 150k weak references has already significant impact to the final-mark STW pause in our case. It can easily jump from 5ms to 30ms range just because of the enqueueuing need. We are even considering to create an application solution for 'slowly' clearing strong references to split enqueueuing over several cycles. Generally I would prefer to promote a bit more in the presentation the Traversal mode healthy impact to handling references. The deadly embracing references problem due to the SATB marking is simply not there. All works like in the first generation of garbage collectors (serial, parallel, CMS). For us it is a core requirement and we have huge interest in non-SATB markers like Traversal mode implements in Shenandoah. I think Roman names it 'partial incremental update' marker. The capability of Shenandoah to offer different markers in general is something to be mentioned as well. Michal Date: Mon, 1 Apr 2019 17:23:26 +0200 From: Aleksey Shipilev > To: Simone Bordet >, shenandoah-dev at openjdk.java.net Subject: Re: Weak Ref Processing Message-ID: > Content-Type: text/plain; charset=utf-8 On 4/1/19 5:12 PM, Simone Bordet wrote: > I'm preparing for a conference session about Shenandoah (and ZGC), and > I would like to confirm how Shenandoah does Weak (et al.) Reference > Processing. > > As far as I understand, weak reference processing is still a STW > operation during the final mark phase, so GC parallel but not GC > concurrent. Is that correct? Depends on what "processing" means. The performance model for weakrefs is a bit complicated. Discovery (figuring out the references that exist in heap) is still done concurrently during concurrent mark. Precleaning (purging the references that have definitely alive referents) is done concurrently after mark. Processing (figuring out what to do with references that have dead referents, for example, clearing them or marking through the reachable referent) is done in final-mark STW pause. Enqueueuing (putting references on associated ReferenceQueue, if any), is done in final-mark STW pause as well. So, the pause time depends on the weak references _churn_. For references+referents that stay alive there is little to no overhead (because precleaning takes care of them). For references that die along with referents, the cost is zero (because discovery never finds them). For references that have always clear referents (i.e. everything except finalizable), the processing cost does not involve marking through the suddenly reachable subgraph, so the cost is also low, but not as low as you might want, hence the desire to have concurrent reference processing. Reference processing is performed by multiple parallel workers. When in pause, it is guided by ParallelGCThreads. In concurrent mode, by ConcGCThreads, and mostly piggybacking on the actual GC threads that do the marking. > Is there any plan to make it concurrent, if not already? Roman had a prototype, I would let him talk about it. -Aleksey From rkennke at redhat.com Mon Apr 1 19:59:10 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 1 Apr 2019 21:59:10 +0200 Subject: Weak Ref Processing In-Reply-To: <022801d4e8a9$6fa86150$4ef923f0$@luxonit.com> References: <022801d4e8a9$6fa86150$4ef923f0$@luxonit.com> Message-ID: >> because precleaning takes care of them > > The precleaning running in the concurrent cycle (Traversal Mode) takes in > our case significant portion of the concurrent cycle. Not sure, > > but the source code indicates to me that the precleaning is done with 1 > worker only (not using all ConcGCThreads threads available). > > Something to be improved? yes, maybe. we're looking into it. It's possible that the relevant code is not actually multithread-safe. Not sure what the reason was to make it 1-threaded. >> Enqueueuing (putting references on associated ReferenceQueue, if any), is > done in final-mark STW pause as well. > > Enqueueuing 150k weak references has already significant impact to the > final-mark STW pause in our case. It can easily jump from 5ms to 30ms range > > just because of the enqueueuing need. We are even considering to create an > application solution for 'slowly' clearing strong references to split > > enqueueuing over several cycles. Yeah. Concurrent reference processing would solve that because it moves the enqueueing into the subsequent concurrent phase. I know how to do that in Shenandoah, I 'only' need to get around to it (just like all the other dozen or so loose ends ;-) ). Cheers, Roman From rkennke at redhat.com Mon Apr 1 20:01:35 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 1 Apr 2019 22:01:35 +0200 Subject: RFR: Pre LRB cleanup Message-ID: <1f672c2d-1efa-6db8-563c-86212f5bbbc5@redhat.com> I swept through: https://builds.shipilev.net/patch-openjdk-shenandoah-jdk/index.html and found two minor things that we should clean up: http://cr.openjdk.java.net/~rkennke/pre-lrb-cleanup/webrev.00/ The rest looks ok to me. There are some discrepancies that are there because of mismatched sh/jdk vs. jdk/jdk, which will get resolve on next upstream merge I suppose. Testing: hotspot_gc_shenandoah Ok to push? Roman From shade at redhat.com Mon Apr 1 20:05:29 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 1 Apr 2019 22:05:29 +0200 Subject: RFR: Pre LRB cleanup In-Reply-To: <1f672c2d-1efa-6db8-563c-86212f5bbbc5@redhat.com> References: <1f672c2d-1efa-6db8-563c-86212f5bbbc5@redhat.com> Message-ID: <75907cf3-d7c4-8f97-d2d3-93851dd55356@redhat.com> On 4/1/19 10:01 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/pre-lrb-cleanup/webrev.00/ OK. I'll look through sh/jdk webrev some time too. -Aleksey From rkennke at redhat.com Mon Apr 1 20:19:35 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Mon, 01 Apr 2019 20:19:35 +0000 Subject: hg: shenandoah/jdk: Pre LRB cleanup Message-ID: <201904012019.x31KJZwp017570@aojmv0008.oracle.com> Changeset: 33417535a0a0 Author: rkennke Date: 2019-04-01 22:16 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/33417535a0a0 Pre LRB cleanup ! src/hotspot/share/opto/block.hpp ! src/hotspot/share/opto/library_call.cpp From shade at redhat.com Mon Apr 1 20:27:23 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 1 Apr 2019 22:27:23 +0200 Subject: Weak Ref Processing In-Reply-To: References: <022801d4e8a9$6fa86150$4ef923f0$@luxonit.com> Message-ID: <5342976b-ac24-f08e-59bc-590031303e56@redhat.com> On 4/1/19 9:59 PM, Roman Kennke wrote: >>> because precleaning takes care of them >> >> The precleaning running in the concurrent cycle (Traversal Mode) takes in >> our case significant portion of the concurrent cycle. Not sure, >> >> but the source code indicates to me that the precleaning is done with 1 >> worker only (not using all ConcGCThreads threads available). >> >> Something to be improved? > > yes, maybe. we're looking into it. It's possible that the relevant code is not actually > multithread-safe. Not sure what the reason was to make it 1-threaded. Shenandoah calls into shared code for precleaning. That code is single-threaded. We have a todo item to improve (parallelize) it. I should have noted that pre-cleaning (well, skipping discovery) is also done during discovery in mark. Post-mark precleaning handles the cases where referent got marked _after_ the reference was discovered. I remember profiling some applications and seeing the overwhelming majority of weakrefs was ignored on discovery. -Aleksey From shade at redhat.com Tue Apr 2 08:50:23 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 2 Apr 2019 10:50:23 +0200 Subject: RFR: JDK-8221751: Shenandoah: Improve SATB enqueueing In-Reply-To: <2be2148c-24eb-986a-8621-3e45e93a30fa@redhat.com> References: <2be2148c-24eb-986a-8621-3e45e93a30fa@redhat.com> Message-ID: On 4/1/19 3:41 PM, Roman Kennke wrote: > In some paths, we currently check GC state 3 times before enqueueing an oop in SATB buffer: 1. > conc-mark in progress (global or local), 2. SATB active (global) 3. SATB active (local). This should > be streamlined to only do one check, and consistently check conc-mark-in-progress only. > > This can be taken even further for arraycopy pre-barriers and arraycopy-loops, where the check can > be done once for the whole operation. In arraycopy barriers code, we can also 'inline' the current > thread and marking context objects, instead of fetching them for every array element. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221751 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8221751/webrev.00/ Looks okay. *) In ShenandoahBarrierSet::write_ref_array_pre_work, shouldn't all new code go under the _heap->is_concurrent_mark_in_progress branch? *) Indenting nit in shenandoahRuntime.cpp. 52 shenandoah_assert_correct(NULL, orig); 53 // store the original value that was in the field reference 54 assert(ShenandoahThreadLocalData::satb_mark_queue(thread).is_active(), "Shouldn't be here otherwise"); 55 ShenandoahThreadLocalData::satb_mark_queue(thread).enqueue_known_active(orig); -- Thanks, -Aleksey From shade at redhat.com Tue Apr 2 10:06:33 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 2 Apr 2019 12:06:33 +0200 Subject: RFR: LRB cleanups: update comments, formatting, etc Message-ID: <4fff0f94-f1c5-099a-9ce8-79bb2cdd3dbc@redhat.com> Eyeballed current sh/jdk and here's my set of cleanups: http://cr.openjdk.java.net/~shade/shenandoah/lrb-cleanup-1/webrev.01/ Testing: hotspot_gc_shenandoah on Linux x86_64 -- Thanks, -Aleksey From rkennke at redhat.com Tue Apr 2 10:38:56 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 2 Apr 2019 12:38:56 +0200 Subject: RFR: JDK-8221751: Shenandoah: Improve SATB enqueueing In-Reply-To: References: <2be2148c-24eb-986a-8621-3e45e93a30fa@redhat.com> Message-ID: <09d420ca-aff8-f294-7a12-9b18553e7613@redhat.com> >> In some paths, we currently check GC state 3 times before enqueueing an oop in SATB buffer: 1. >> conc-mark in progress (global or local), 2. SATB active (global) 3. SATB active (local). This should >> be streamlined to only do one check, and consistently check conc-mark-in-progress only. >> >> This can be taken even further for arraycopy pre-barriers and arraycopy-loops, where the check can >> be done once for the whole operation. In arraycopy barriers code, we can also 'inline' the current >> thread and marking context objects, instead of fetching them for every array element. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8221751 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8221751/webrev.00/ > > Looks okay. > > *) In ShenandoahBarrierSet::write_ref_array_pre_work, shouldn't all new code go under the > _heap->is_concurrent_mark_in_progress branch? In-fact, we don't even have to check this flag, because it's already checked in the arraycopy_prologue-code generated by shenandoahBarrierSetAssembler_XXX.cpp. *And* we can also avoid pointlessly checking ShenandoahSATBBarrier, if we do the check at codegen-time in the stub generator too. I suppose this might be helpful if/because that code is often called with small/tiny arrays (actual workload). > *) Indenting nit in shenandoahRuntime.cpp. > > 52 shenandoah_assert_correct(NULL, orig); > 53 // store the original value that was in the field reference > 54 assert(ShenandoahThreadLocalData::satb_mark_queue(thread).is_active(), "Shouldn't be here > otherwise"); > 55 ShenandoahThreadLocalData::satb_mark_queue(thread).enqueue_known_active(orig); Fixed. New webrev: http://cr.openjdk.java.net/~rkennke/JDK-8221751/webrev.01/ hotspot_gc_shenandoah is still good. Roman From rkennke at redhat.com Tue Apr 2 10:51:04 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 2 Apr 2019 12:51:04 +0200 Subject: RFR: LRB cleanups: update comments, formatting, etc In-Reply-To: <4fff0f94-f1c5-099a-9ce8-79bb2cdd3dbc@redhat.com> References: <4fff0f94-f1c5-099a-9ce8-79bb2cdd3dbc@redhat.com> Message-ID: <7112af93-b4f8-de5a-e6c6-255f9ea5f4f5@redhat.com> Looks good, thanks! Roman > Eyeballed current sh/jdk and here's my set of cleanups: > http://cr.openjdk.java.net/~shade/shenandoah/lrb-cleanup-1/webrev.01/ > > Testing: hotspot_gc_shenandoah on Linux x86_64 > From shade at redhat.com Tue Apr 2 11:23:11 2019 From: shade at redhat.com (shade at redhat.com) Date: Tue, 02 Apr 2019 11:23:11 +0000 Subject: hg: shenandoah/jdk: LRB cleanups: update comments, formatting, etc Message-ID: <201904021123.x32BNBlW015408@aojmv0008.oracle.com> Changeset: 092d783d359e Author: shade Date: 2019-04-02 13:22 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/092d783d359e LRB cleanups: update comments, formatting, etc ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/gc/shenandoah/shenandoahEvacOOMHandler.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp From shade at redhat.com Tue Apr 2 11:41:00 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 2 Apr 2019 13:41:00 +0200 Subject: RFC/RFR: Cherry-pick 8221735: Shenandoah fails ctw/modules/jdk_management_agent.java with Traversal Message-ID: Let's cherry pick the fix for CTW failure in sh/jdk: https://bugs.openjdk.java.net/browse/JDK-8221735 http://hg.openjdk.java.net/jdk/jdk/rev/dfaa9daab43c It would take a while until it gets to sh/jdk with merges. -- diff -r 092d783d359e src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp --- a/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Tue Apr 02 13:22:56 2019 +0200 +++ b/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Tue Apr 02 13:25:17 2019 +0200 @@ -2097,10 +2097,11 @@ } int ShenandoahEnqueueBarrierNode::needed(Node* n) { if (n == NULL || n->is_Allocate() || + n->Opcode() == Op_ShenandoahEnqueueBarrier || n->bottom_type() == TypePtr::NULL_PTR || (n->bottom_type()->make_oopptr() != NULL && n->bottom_type()->make_oopptr()->const_oop() != NULL)) { return NotNeeded; } if (n->is_Phi() || Testing: hotspot_gc_shenandoah, CTW tests Thanks, -Aleksey From rkennke at redhat.com Tue Apr 2 11:43:03 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 2 Apr 2019 13:43:03 +0200 Subject: RFC/RFR: Cherry-pick 8221735: Shenandoah fails ctw/modules/jdk_management_agent.java with Traversal In-Reply-To: References: Message-ID: OK > Let's cherry pick the fix for CTW failure in sh/jdk: > https://bugs.openjdk.java.net/browse/JDK-8221735 > http://hg.openjdk.java.net/jdk/jdk/rev/dfaa9daab43c > > It would take a while until it gets to sh/jdk with merges. > > -- diff -r 092d783d359e src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp > --- a/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Tue Apr 02 13:22:56 2019 +0200 > +++ b/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Tue Apr 02 13:25:17 2019 +0200 > @@ -2097,10 +2097,11 @@ > } > > int ShenandoahEnqueueBarrierNode::needed(Node* n) { > if (n == NULL || > n->is_Allocate() || > + n->Opcode() == Op_ShenandoahEnqueueBarrier || > n->bottom_type() == TypePtr::NULL_PTR || > (n->bottom_type()->make_oopptr() != NULL && n->bottom_type()->make_oopptr()->const_oop() != > NULL)) { > return NotNeeded; > } > if (n->is_Phi() || > > Testing: hotspot_gc_shenandoah, CTW tests > > Thanks, > -Aleksey > > From shade at redhat.com Tue Apr 2 11:46:47 2019 From: shade at redhat.com (shade at redhat.com) Date: Tue, 02 Apr 2019 11:46:47 +0000 Subject: hg: shenandoah/jdk: Cherry-pick: 8221735: Shenandoah fails ctw/modules/jdk_management_agent.java with Traversal Message-ID: <201904021146.x32BkltP002049@aojmv0008.oracle.com> Changeset: c5a159a6b36d Author: shade Date: 2019-04-01 13:33 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/c5a159a6b36d Cherry-pick: 8221735: Shenandoah fails ctw/modules/jdk_management_agent.java with Traversal ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp From rkennke at redhat.com Tue Apr 2 15:07:13 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 2 Apr 2019 17:07:13 +0200 Subject: RFR: JDK-8221751: Shenandoah: Improve SATB enqueueing In-Reply-To: References: <2be2148c-24eb-986a-8621-3e45e93a30fa@redhat.com> Message-ID: >> In some paths, we currently check GC state 3 times before enqueueing an oop in SATB buffer: 1. >> conc-mark in progress (global or local), 2. SATB active (global) 3. SATB active (local). This should >> be streamlined to only do one check, and consistently check conc-mark-in-progress only. >> >> This can be taken even further for arraycopy pre-barriers and arraycopy-loops, where the check can >> be done once for the whole operation. In arraycopy barriers code, we can also 'inline' the current >> thread and marking context objects, instead of fetching them for every array element. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8221751 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8221751/webrev.00/ > > Looks okay. > > *) In ShenandoahBarrierSet::write_ref_array_pre_work, shouldn't all new code go under the > _heap->is_concurrent_mark_in_progress branch? > > > *) Indenting nit in shenandoahRuntime.cpp. > > 52 shenandoah_assert_correct(NULL, orig); > 53 // store the original value that was in the field reference > 54 assert(ShenandoahThreadLocalData::satb_mark_queue(thread).is_active(), "Shouldn't be here > otherwise"); > 55 ShenandoahThreadLocalData::satb_mark_queue(thread).enqueue_known_active(orig); > I noticed that AArch64 assembly stubs don't check marking-in-progess at all, and x86 asm stub checks the SATB-active and not the gc-state like we do everywhere else. I added the aarch64 check, and changed x86 to check gc-state. I also added checks for count==0, in which case we don't even need to call out at all. (And it is surprisingly common too.) http://cr.openjdk.java.net/~rkennke/JDK-8221751/webrev.02/ Testing: Passes hotspot_gc_shenandoah both x86 and aarch64 Ok? Roman From aph at redhat.com Tue Apr 2 15:22:37 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 2 Apr 2019 16:22:37 +0100 Subject: RFR: JDK-8221751: Shenandoah: Improve SATB enqueueing In-Reply-To: References: <2be2148c-24eb-986a-8621-3e45e93a30fa@redhat.com> Message-ID: On 4/2/19 4:07 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/JDK-8221751/webrev.02/ > > Testing: Passes hotspot_gc_shenandoah both x86 and aarch64 > > Ok? 54 __ cmp(count, zr); 55 __ br(Assembler::EQ, done); should be cbz(count, done); and this 60 __ mov(rscratch2, ShenandoahHeap::MARKING); 61 __ tst(rscratch1, rscratch2); 62 __ br(Assembler::EQ, done); should be 62 __ tbz(rscratch1, ShenandoahHeap::MARKING_BITPOS, done); -- 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 Tue Apr 2 15:41:53 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 2 Apr 2019 17:41:53 +0200 Subject: RFR: JDK-8221751: Shenandoah: Improve SATB enqueueing In-Reply-To: References: <2be2148c-24eb-986a-8621-3e45e93a30fa@redhat.com> Message-ID: <62f720bf-6b6f-395c-5579-1e8dff2d6c35@redhat.com> >> http://cr.openjdk.java.net/~rkennke/JDK-8221751/webrev.02/ >> >> Testing: Passes hotspot_gc_shenandoah both x86 and aarch64 >> >> Ok? > > 54 __ cmp(count, zr); > 55 __ br(Assembler::EQ, done); > > should be > > cbz(count, done); > > and this > > 60 __ mov(rscratch2, ShenandoahHeap::MARKING); > 61 __ tst(rscratch1, rscratch2); > 62 __ br(Assembler::EQ, done); > > should be > > 62 __ tbz(rscratch1, ShenandoahHeap::MARKING_BITPOS, done); > Very nice! http://cr.openjdk.java.net/~rkennke/JDK-8221751/webrev.03/ Is there also a short version of this check: __ mov(rscratch2, ShenandoahHeap::MARKING | ShenandoahHeap::TRAVERSAL); __ tst(rscratch1, rscratch2); __ br(Assembler::EQ, done); because I need this too in a couple of places. Roman From shade at redhat.com Tue Apr 2 15:57:50 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 2 Apr 2019 17:57:50 +0200 Subject: RFR: JDK-8221751: Shenandoah: Improve SATB enqueueing In-Reply-To: <62f720bf-6b6f-395c-5579-1e8dff2d6c35@redhat.com> References: <2be2148c-24eb-986a-8621-3e45e93a30fa@redhat.com> <62f720bf-6b6f-395c-5579-1e8dff2d6c35@redhat.com> Message-ID: <4ce77e69-9bc8-8eb5-2b9f-bb2feaa88279@redhat.com> On 4/2/19 5:41 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/JDK-8221751/webrev.03/ Okay with me. -Aleksey From aph at redhat.com Tue Apr 2 16:56:41 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 2 Apr 2019 17:56:41 +0100 Subject: RFR: JDK-8221751: Shenandoah: Improve SATB enqueueing In-Reply-To: <62f720bf-6b6f-395c-5579-1e8dff2d6c35@redhat.com> References: <2be2148c-24eb-986a-8621-3e45e93a30fa@redhat.com> <62f720bf-6b6f-395c-5579-1e8dff2d6c35@redhat.com> Message-ID: On 4/2/19 4:41 PM, Roman Kennke wrote: > s there also a short version of this check: > > __ mov(rscratch2, ShenandoahHeap::MARKING | ShenandoahHeap::TRAVERSAL); > __ tst(rscratch1, rscratch2); > __ br(Assembler::EQ, done); > > because I need this too in a couple of places. Not really, no. There is no short immediate form of ShenandoahHeap::MARKING | ShenandoahHeap::TRAVERSAL. Of course you could do it with two tbz instructions and that would be shorter, but ewww. You could change it to __ tst(rscratch1, ShenandoahHeap::MARKING | ShenandoahHeap::TRAVERSAL); __ br(Assembler::EQ, done); by moving TRAVERSAL immediately after MARKING in GCStateBitPos. But you might think that's a bit weird. :-) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Tue Apr 2 17:14:31 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 2 Apr 2019 19:14:31 +0200 Subject: RFC/RFR: Pick up jdk-11.0.3+6 to sh/jdk11 Message-ID: Upstream^W We have pushed the jdk-11.0.3+6 tag upstream to jdk-updates/jdk11u. Let's pick it up to sh/jdk11. The merge is trivial, and includes a single x86_32 fix, plus some accidental commit and reversal. Summary of changes: http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b6/changesets.txt Webrev: http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b6/webrev.01/ Since this is the trivial merge, I plan to skip any further testing, and just tag itshenandoah-jdk-11.0.3+6 right away. Testing: x86_64 {fastdebug|release} tier1_gc_shenandoah Thanks, -Aleksey From zgu at redhat.com Tue Apr 2 17:18:00 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 2 Apr 2019 13:18:00 -0400 Subject: RFC/RFR: Pick up jdk-11.0.3+6 to sh/jdk11 In-Reply-To: References: Message-ID: <1a4d9b1c-7e01-7aee-4e54-4c8ed0feb38f@redhat.com> Looks good. -Zhengyu On 4/2/19 1:14 PM, Aleksey Shipilev wrote: > Upstream^W We have pushed the jdk-11.0.3+6 tag upstream to jdk-updates/jdk11u. Let's pick it up to > sh/jdk11. The merge is trivial, and includes a single x86_32 fix, plus some accidental commit and > reversal. > > Summary of changes: > http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b6/changesets.txt > > Webrev: > http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b6/webrev.01/ > > Since this is the trivial merge, I plan to skip any further testing, and just tag > itshenandoah-jdk-11.0.3+6 right away. > > Testing: x86_64 {fastdebug|release} tier1_gc_shenandoah > > Thanks, > -Aleksey > From shade at redhat.com Tue Apr 2 17:27:23 2019 From: shade at redhat.com (shade at redhat.com) Date: Tue, 02 Apr 2019 17:27:23 +0000 Subject: hg: shenandoah/jdk11: 6 new changesets Message-ID: <201904021727.x32HRO0B018978@aojmv0008.oracle.com> Changeset: a68aa56930c0 Author: dcherepanov Date: 2019-03-20 11:51 +0300 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/a68aa56930c0 8211100: hotspot C1 issue with comparing long numbers on x86 32-bit Reviewed-by: iveresov, thartmann ! src/hotspot/share/c1/c1_LIRGenerator.cpp + test/hotspot/jtreg/compiler/c1/Test8211100.java Changeset: 22cfec306339 Author: joehw Date: 2019-04-01 09:54 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/22cfec306339 8207760: SAXException: Invalid UTF-16 surrogate detected: d83c ? Summary: Properly handle unicode16 characters split across buffer chunks. Reviewed-by: lancea, dfuchs ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToTextStream.java + test/jaxp/javax/xml/jaxp/unittest/transform/JDK8207760.java Changeset: 8e139b8b4f62 Author: phh Date: 2019-04-02 13:07 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/8e139b8b4f62 8221769: Revert JDK-8221767 mistakenly pushed to jdk11u 11.0.3 Reviewed-by: clanger ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java ! src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToTextStream.java - test/jaxp/javax/xml/jaxp/unittest/transform/JDK8207760.java Changeset: bd1035b5571b Author: goetz Date: 2019-04-02 14:47 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/bd1035b5571b Added tag jdk-11.0.3+6 for changeset 8e139b8b4f62 ! .hgtags Changeset: 3b66d8528094 Author: shade Date: 2019-04-02 19:00 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/3b66d8528094 Merge ! .hgtags ! src/hotspot/share/c1/c1_LIRGenerator.cpp Changeset: 26c5e34631c0 Author: shade Date: 2019-04-02 19:01 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/26c5e34631c0 Added tag shenandoah-jdk-11.0.3+6 for changeset 3b66d8528094 ! .hgtags From zgu at redhat.com Tue Apr 2 18:19:15 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 2 Apr 2019 14:19:15 -0400 Subject: RFR: 8220602: Shenandoah-SA: Enable best-effort implementation of heap walk In-Reply-To: References: <7eb10ba1-e586-e7f1-aeef-500ced0edeff@redhat.com> Message-ID: Thanks, Chris. On 4/2/19 2:16 PM, Chris Plummer wrote: > Changes to CollectedHeap.java and ObjectHeap.java look fine. One minor > nit. Please fix the indent of line 258 in ObjectHeap.java: > > ?257???????? while (handle.lessThan(top)) { > ?258???????? Oop obj = null; > ?259?????????? // Raw pointer walk > ?260?????????? handle = handle.addOffsetToAsOopHandle(heap.oopOffset()); I will fix it before push. -Zhengyu > > thanks, > > Chris > > On 4/1/19 6:26 AM, Zhengyu Gu wrote: >> Hi, >> >> May I get review from serviceability? as it has minor changes in >> shared code (CollectedHeap.java and ObjectHeap.java) >> >> >> Thanks, >> >> -Zhengyu >> >> >> On 3/14/19 11:37 AM, Zhengyu Gu wrote: >>> Please review this patch that provides best-effort implementation of >>> live regions iteration for Shenandoah GC. >>> >>> There are minor changes in shared code, to adjust oop offset from >>> base of allocation cell. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8220602 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8220602/webrev.00/index.html >>> >>> >>> Test: >>> ?? hotspot_gc_shenandoah >>> ?? hotspot_serviceability >>> ?? vmTestbase/nsk/jdb >>> ?? manual test: jhsdb hsdb >>> ?? on Linux x64 >>> >>> ?? Passed submit test. >>> >>> >>> Thanks, >>> >>> -Zhengyu > > > From chris.plummer at oracle.com Tue Apr 2 18:16:09 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Apr 2019 11:16:09 -0700 Subject: RFR: 8220602: Shenandoah-SA: Enable best-effort implementation of heap walk In-Reply-To: <7eb10ba1-e586-e7f1-aeef-500ced0edeff@redhat.com> References: <7eb10ba1-e586-e7f1-aeef-500ced0edeff@redhat.com> Message-ID: Changes to CollectedHeap.java and ObjectHeap.java look fine. One minor nit. Please fix the indent of line 258 in ObjectHeap.java: ?257???????? while (handle.lessThan(top)) { ?258???????? Oop obj = null; ?259?????????? // Raw pointer walk ?260?????????? handle = handle.addOffsetToAsOopHandle(heap.oopOffset()); thanks, Chris On 4/1/19 6:26 AM, Zhengyu Gu wrote: > Hi, > > May I get review from serviceability? as it has minor changes in > shared code (CollectedHeap.java and ObjectHeap.java) > > > Thanks, > > -Zhengyu > > > On 3/14/19 11:37 AM, Zhengyu Gu wrote: >> Please review this patch that provides best-effort implementation of >> live regions iteration for Shenandoah GC. >> >> There are minor changes in shared code, to adjust oop offset from >> base of allocation cell. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8220602 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8220602/webrev.00/index.html >> >> >> Test: >> ?? hotspot_gc_shenandoah >> ?? hotspot_serviceability >> ?? vmTestbase/nsk/jdb >> ?? manual test: jhsdb hsdb >> ?? on Linux x64 >> >> ?? Passed submit test. >> >> >> Thanks, >> >> -Zhengyu From zgu at redhat.com Tue Apr 2 20:34:44 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 2 Apr 2019 16:34:44 -0400 Subject: RFR(T) 8221875: Unquarantine Shenandoah string dedup tests Message-ID: <0e00c94c-8a1f-38aa-26eb-e1f4ba957760@redhat.com> The cause of failures are fixed by JDK-8220671 and JDK-8221102, let's put the tests back on. Bug: https://bugs.openjdk.java.net/browse/JDK-8221875 diff -r 9559ba212c18 -r 5aacfca3a4f1 test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt Tue Apr 02 13:08:38 2019 -0400 +++ b/test/hotspot/jtreg/ProblemList.txt Tue Apr 02 16:30:45 2019 -0400 @@ -141,9 +141,6 @@ # :hotspot_gc_shenandoah -gc/shenandoah/TestStringDedup.java 8220671,8221102 generic-all -gc/shenandoah/TestStringDedupStress.java 8220671,8221102 generic-all - ############################################################################# # :hotspot_misc Thanks, -Zhengyu From rkennke at redhat.com Tue Apr 2 20:39:00 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 2 Apr 2019 22:39:00 +0200 Subject: RFR(T) 8221875: Unquarantine Shenandoah string dedup tests In-Reply-To: <0e00c94c-8a1f-38aa-26eb-e1f4ba957760@redhat.com> References: <0e00c94c-8a1f-38aa-26eb-e1f4ba957760@redhat.com> Message-ID: Go! Thanks! > The cause of failures are fixed by JDK-8220671 and JDK-8221102, let's > put the tests back on. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221875 > > > diff -r 9559ba212c18 -r 5aacfca3a4f1 test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt??????? Tue Apr 02 13:08:38 2019 > -0400 > +++ b/test/hotspot/jtreg/ProblemList.txt??????? Tue Apr 02 16:30:45 2019 > -0400 > @@ -141,9 +141,6 @@ > > ?# :hotspot_gc_shenandoah > > -gc/shenandoah/TestStringDedup.java 8220671,8221102 generic-all > -gc/shenandoah/TestStringDedupStress.java 8220671,8221102 generic-all > - > > ############################################################################# > > > ?# :hotspot_misc > > > Thanks, > > -Zhengyu From rkennke at redhat.com Tue Apr 2 21:11:52 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 2 Apr 2019 23:11:52 +0200 Subject: RFR: Aarch64 cmpxchg_oop() fix Message-ID: <90b2831b-701c-27eb-50a8-485d23546848@redhat.com> Aleksey spotted a bug that we apparently introduced with LRB. Let's revert this little part: diff -r c5a159a6b36d src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp --- a/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp Mon Apr 01 13:33:58 2019 +0200 +++ b/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp Tue Apr 02 23:09:55 2019 +0200 @@ -414,7 +414,9 @@ } __ bind(done); - if (!is_cae) { + if (is_cae) { + __ mov(result, tmp1); + } else { __ cset(result, Assembler::EQ); } } Testing: hotspot_gc_shenandoah on aarch64 Ok? From rkennke at redhat.com Tue Apr 2 21:12:40 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 2 Apr 2019 23:12:40 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah Message-ID: (I am cross-posting this to build-dev and compiler-dev because this contains some (trivial-ish) shared build and C2 changes. The C2 changes are almost all reversals of Shenandoah-specific paths that have been introduced in initial Shenandoah push.) I would like to propose that we switch to what we came to call 'load reference barrier' as new barrier scheme for Shenandoah GC. The main difference is that instead of ensuring correct invariant when we store anything into the heap (e.g. read-barrier before reads, write-barrier before writes, plus a bunch of other stuff), we ensure the strong invariance on objects when they get loaded, by employing what is currently our write-barrier. The reason why I'm proposing it is: - simpler barrier interface - easier to get good performance out of it ==> good for upcoming Graal (sup)port - reduced maintenance burden (I intend to backport it all the way) This has a number of advantages: - Strong invariant means it's a lot easier to reason about the state of GC and objects - Much simpler barrier interface. Infact, a lot of stuff that we added to barrier interfaces after JDK11 will now become unused: no need for barriers on primitives, no need for object equality barriers, no need for resolve barriers, etc. Also, some C2 stuff that we added for Shenandoah can now be removed again. (Those are what comprise most shared C2 changes.) - Optimization is much easier: we currently put barriers 'down low' close to their uses (which might be inside a hot loop), and then work hard to optimize barriers upwards, e.g. out of loops. By using load-ref-barriers, we would place them at the outermost site already. Look how much code is removed from shenandoahSupport.cpp! - No more need for object equals barriers. - No more need for 'resolve' barriers. - All barriers are now conditional, which opens up opportunity for further optimization later on. - we can re-enable the fast JNI getfield stuff - we no longer need the nmethod initializer that initializes embedded oops to to-space - We no longer have the problem to use two registers for 'the same' value (pre- and post-barrier). The 'only' optimizations that we do in C2 are: - Look upwards and see if barrier input indicates we don't actually need the barrier. Would be the case for: constants, nulls, method parameters, etc (anything that is not like a load). Even though we insert barriers after loads, you'd be surprised to see how many loads actually disappear. - Look downwards to check uses of the barrier. If it doesn't feed into anything that requires a barrier, we can remove it. Performance doesn't seem to be negatively impacted at all. Some benchmarks benefit positively from it. Testing: Testing: hotspot_gc_shenandoah, SPECjvm2008, SPECjbb2015, all of them many times. This patch has baked in shenandoah/jdk for 1.5 months, undergone our rigorous CI, received various bug-fixes, we have had a close look at the generated code to verify it is sane. jdk/submit job expected good before push. Bug: https://bugs.openjdk.java.net/browse/JDK-8221766 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.00/ Can I please get reviews for this change? Roman From rkennke at redhat.com Tue Apr 2 21:28:02 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 2 Apr 2019 23:28:02 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <8b8673bf-42af-d519-5a57-509d30514b83@oracle.com> References: <8b8673bf-42af-d519-5a57-509d30514b83@oracle.com> Message-ID: Thanks, Erik! Roman > Build change looks good. > > /Erik > > On 2019-04-02 14:12, Roman Kennke wrote: >> (I am cross-posting this to build-dev and compiler-dev because this >> contains some (trivial-ish) shared build and C2 changes. The C2 changes >> are almost all reversals of Shenandoah-specific paths that have been >> introduced in initial Shenandoah push.) >> >> I would like to propose that we switch to what we came to call 'load >> reference barrier' as new barrier scheme for Shenandoah GC. >> >> The main difference is that instead of ensuring correct invariant when >> we store anything into the heap (e.g. read-barrier before reads, >> write-barrier before writes, plus a bunch of other stuff), we ensure the >> strong invariance on objects when they get loaded, by employing what is >> currently our write-barrier. >> >> The reason why I'm proposing it is: >> - simpler barrier interface >> - easier to get good performance out of it >> ?? ==> good for upcoming Graal (sup)port >> - reduced maintenance burden (I intend to backport it all the way) >> >> This has a number of advantages: >> - Strong invariant means it's a lot easier to reason about the state of >> GC and objects >> - Much simpler barrier interface. Infact, a lot of stuff that we added >> to barrier interfaces after JDK11 will now become unused: no need for >> barriers on primitives, no need for object equality barriers, no need >> for resolve barriers, etc. Also, some C2 stuff that we added for >> Shenandoah can now be removed again. (Those are what comprise most >> shared C2 changes.) >> - Optimization is much easier: we currently put barriers 'down low' >> close to their uses (which might be inside a hot loop), and then work >> hard to optimize barriers upwards, e.g. out of loops. By using >> load-ref-barriers, we would place them at the outermost site already. >> Look how much code is removed from shenandoahSupport.cpp! >> - No more need for object equals barriers. >> - No more need for 'resolve' barriers. >> - All barriers are now conditional, which opens up opportunity for >> further optimization later on. >> - we can re-enable the fast JNI getfield stuff >> - we no longer need the nmethod initializer that initializes embedded >> oops to to-space >> - We no longer have the problem to use two registers for 'the same' >> value (pre- and post-barrier). >> >> The 'only' optimizations that we do in C2 are: >> - Look upwards and see if barrier input indicates we don't actually need >> the barrier. Would be the case for: constants, nulls, method parameters, >> etc (anything that is not like a load). Even though we insert barriers >> after loads, you'd be surprised to see how many loads actually disappear. >> - Look downwards to check uses of the barrier. If it doesn't feed into >> anything that requires a barrier, we can remove it. >> >> Performance doesn't seem to be negatively impacted at all. Some >> benchmarks benefit positively from it. >> >> Testing: Testing: hotspot_gc_shenandoah, SPECjvm2008, SPECjbb2015, all >> of them many times. This patch has baked in shenandoah/jdk for 1.5 >> months, undergone our rigorous CI, received various bug-fixes, we have >> had a close look at the generated code to verify it is sane. jdk/submit >> job expected good before push. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8221766 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.00/ >> >> Can I please get reviews for this change? >> >> Roman >> >> From erik.joelsson at oracle.com Tue Apr 2 21:25:06 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 2 Apr 2019 14:25:06 -0700 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: Message-ID: <8b8673bf-42af-d519-5a57-509d30514b83@oracle.com> Build change looks good. /Erik On 2019-04-02 14:12, Roman Kennke wrote: > (I am cross-posting this to build-dev and compiler-dev because this > contains some (trivial-ish) shared build and C2 changes. The C2 changes > are almost all reversals of Shenandoah-specific paths that have been > introduced in initial Shenandoah push.) > > I would like to propose that we switch to what we came to call 'load > reference barrier' as new barrier scheme for Shenandoah GC. > > The main difference is that instead of ensuring correct invariant when > we store anything into the heap (e.g. read-barrier before reads, > write-barrier before writes, plus a bunch of other stuff), we ensure the > strong invariance on objects when they get loaded, by employing what is > currently our write-barrier. > > The reason why I'm proposing it is: > - simpler barrier interface > - easier to get good performance out of it > ==> good for upcoming Graal (sup)port > - reduced maintenance burden (I intend to backport it all the way) > > This has a number of advantages: > - Strong invariant means it's a lot easier to reason about the state of > GC and objects > - Much simpler barrier interface. Infact, a lot of stuff that we added > to barrier interfaces after JDK11 will now become unused: no need for > barriers on primitives, no need for object equality barriers, no need > for resolve barriers, etc. Also, some C2 stuff that we added for > Shenandoah can now be removed again. (Those are what comprise most > shared C2 changes.) > - Optimization is much easier: we currently put barriers 'down low' > close to their uses (which might be inside a hot loop), and then work > hard to optimize barriers upwards, e.g. out of loops. By using > load-ref-barriers, we would place them at the outermost site already. > Look how much code is removed from shenandoahSupport.cpp! > - No more need for object equals barriers. > - No more need for 'resolve' barriers. > - All barriers are now conditional, which opens up opportunity for > further optimization later on. > - we can re-enable the fast JNI getfield stuff > - we no longer need the nmethod initializer that initializes embedded > oops to to-space > - We no longer have the problem to use two registers for 'the same' > value (pre- and post-barrier). > > The 'only' optimizations that we do in C2 are: > - Look upwards and see if barrier input indicates we don't actually need > the barrier. Would be the case for: constants, nulls, method parameters, > etc (anything that is not like a load). Even though we insert barriers > after loads, you'd be surprised to see how many loads actually disappear. > - Look downwards to check uses of the barrier. If it doesn't feed into > anything that requires a barrier, we can remove it. > > Performance doesn't seem to be negatively impacted at all. Some > benchmarks benefit positively from it. > > Testing: Testing: hotspot_gc_shenandoah, SPECjvm2008, SPECjbb2015, all > of them many times. This patch has baked in shenandoah/jdk for 1.5 > months, undergone our rigorous CI, received various bug-fixes, we have > had a close look at the generated code to verify it is sane. jdk/submit > job expected good before push. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221766 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.00/ > > Can I please get reviews for this change? > > Roman > > From rkennke at redhat.com Tue Apr 2 22:41:00 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 3 Apr 2019 00:41:00 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: Message-ID: <2702cb33-4065-d917-d046-41d590a20b93@redhat.com> Hi Vladimir, > This is nice cleanup :) > > 4294 lines changed: 977 ins; 2841 del; 476 mod Yeah, right? :-) > First is general question. I don't understand why you need (diagnostic) > ShenandoahLoadRefBarrier flag if it is new behavior and you can't use > old one because you removed it. I am definitely missing something here. This is added for the same purpose that we had e.g. +/-ShenandoahWriteBarrier before: in order to selectively disable the barrier generation, for testing and diagnostics. > Thank you for thinking about Graal: > > >??? ==> good for upcoming Graal (sup)port :-) > opto/loopnode.cpp new is_Phi check was added. Please, explain. I'm not sure. I believe Roland did this. I'll let him comment on it. > I don't see other issues in C2 code. :-) Thanks, Roman > Regards, > Vladimir > > On 4/2/19 2:12 PM, Roman Kennke wrote: >> (I am cross-posting this to build-dev and compiler-dev because this >> contains some (trivial-ish) shared build and C2 changes. The C2 changes >> are almost all reversals of Shenandoah-specific paths that have been >> introduced in initial Shenandoah push.) >> >> I would like to propose that we switch to what we came to call 'load >> reference barrier' as new barrier scheme for Shenandoah GC. >> >> The main difference is that instead of ensuring correct invariant when >> we store anything into the heap (e.g. read-barrier before reads, >> write-barrier before writes, plus a bunch of other stuff), we ensure the >> strong invariance on objects when they get loaded, by employing what is >> currently our write-barrier. >> >> The reason why I'm proposing it is: >> - simpler barrier interface >> - easier to get good performance out of it >> ?? ==> good for upcoming Graal (sup)port >> - reduced maintenance burden (I intend to backport it all the way) >> >> This has a number of advantages: >> - Strong invariant means it's a lot easier to reason about the state of >> GC and objects >> - Much simpler barrier interface. Infact, a lot of stuff that we added >> to barrier interfaces after JDK11 will now become unused: no need for >> barriers on primitives, no need for object equality barriers, no need >> for resolve barriers, etc. Also, some C2 stuff that we added for >> Shenandoah can now be removed again. (Those are what comprise most >> shared C2 changes.) >> - Optimization is much easier: we currently put barriers 'down low' >> close to their uses (which might be inside a hot loop), and then work >> hard to optimize barriers upwards, e.g. out of loops. By using >> load-ref-barriers, we would place them at the outermost site already. >> Look how much code is removed from shenandoahSupport.cpp! >> - No more need for object equals barriers. >> - No more need for 'resolve' barriers. >> - All barriers are now conditional, which opens up opportunity for >> further optimization later on. >> - we can re-enable the fast JNI getfield stuff >> - we no longer need the nmethod initializer that initializes embedded >> oops to to-space >> - We no longer have the problem to use two registers for 'the same' >> value (pre- and post-barrier). >> >> The 'only' optimizations that we do in C2 are: >> - Look upwards and see if barrier input indicates we don't actually need >> the barrier. Would be the case for: constants, nulls, method parameters, >> etc (anything that is not like a load). Even though we insert barriers >> after loads, you'd be surprised to see how many loads actually disappear. >> - Look downwards to check uses of the barrier. If it doesn't feed into >> anything that requires a barrier, we can remove it. >> >> Performance doesn't seem to be negatively impacted at all. Some >> benchmarks benefit positively from it. >> >> Testing: Testing: hotspot_gc_shenandoah, SPECjvm2008, SPECjbb2015, all >> of them many times. This patch has baked in shenandoah/jdk for 1.5 >> months, undergone our rigorous CI, received various bug-fixes, we have >> had a close look at the generated code to verify it is sane. jdk/submit >> job expected good before push. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8221766 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.00/ >> >> Can I please get reviews for this change? >> >> Roman >> >> From shade at redhat.com Wed Apr 3 07:54:22 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 3 Apr 2019 09:54:22 +0200 Subject: RFR: Aarch64 cmpxchg_oop() fix In-Reply-To: <90b2831b-701c-27eb-50a8-485d23546848@redhat.com> References: <90b2831b-701c-27eb-50a8-485d23546848@redhat.com> Message-ID: <8110aaa2-afa2-6532-1995-fdb7d921c7e1@redhat.com> On 4/2/19 11:11 PM, Roman Kennke wrote: > Aleksey spotted a bug that we apparently introduced with LRB. Let's > revert this little part: > > diff -r c5a159a6b36d > src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp > --- > a/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp > Mon Apr 01 13:33:58 2019 +0200 > +++ > b/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp > Tue Apr 02 23:09:55 2019 +0200 > @@ -414,7 +414,9 @@ > } > __ bind(done); > > - if (!is_cae) { > + if (is_cae) { > + __ mov(result, tmp1); > + } else { > __ cset(result, Assembler::EQ); > } > } > > Testing: hotspot_gc_shenandoah on aarch64 OK, looks good. Was any test failing because of this? -Aleksey From rkennke at redhat.com Wed Apr 3 09:12:56 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 3 Apr 2019 11:12:56 +0200 Subject: RFR: Aarch64 cmpxchg_oop() fix In-Reply-To: <8110aaa2-afa2-6532-1995-fdb7d921c7e1@redhat.com> References: <90b2831b-701c-27eb-50a8-485d23546848@redhat.com> <8110aaa2-afa2-6532-1995-fdb7d921c7e1@redhat.com> Message-ID: <8f918d50-9d42-ebba-dd4f-b322acddfd29@redhat.com> >> Aleksey spotted a bug that we apparently introduced with LRB. Let's >> revert this little part: >> >> diff -r c5a159a6b36d >> src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp >> --- >> a/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp >> Mon Apr 01 13:33:58 2019 +0200 >> +++ >> b/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp >> Tue Apr 02 23:09:55 2019 +0200 >> @@ -414,7 +414,9 @@ >> } >> __ bind(done); >> >> - if (!is_cae) { >> + if (is_cae) { >> + __ mov(result, tmp1); >> + } else { >> __ cset(result, Assembler::EQ); >> } >> } >> >> Testing: hotspot_gc_shenandoah on aarch64 > > OK, looks good. Was any test failing because of this? Nothing in hotspot_gc_shenandoah. Roman From rwestrel at redhat.com Wed Apr 3 11:18:55 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 03 Apr 2019 13:18:55 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: Message-ID: <87h8bfqqu8.fsf@redhat.com> Hi Vladimir, > opto/loopnode.cpp new is_Phi check was added. Please, explain. When we expand barriers, if we find a null check nearby we move the barrier close to the null check so there's a better chance of converting it to an implicit null check. That happens as part of a pass of loop opts. I think that's where that change comes from but I don't remember the details. In general we need the control that's assigned to a load to not be too conservative. Anyway, that change is not required for correctness. But it looks reasonable to me. Roland. From rkennke at redhat.com Wed Apr 3 11:33:41 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Wed, 03 Apr 2019 11:33:41 +0000 Subject: hg: shenandoah/jdk: Aarch64 cmpxchg_oop() fix Message-ID: <201904031133.x33BXfoU026628@aojmv0008.oracle.com> Changeset: 73d0d1848c58 Author: rkennke Date: 2019-04-03 13:33 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/73d0d1848c58 Aarch64 cmpxchg_oop() fix ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp From rkennke at redhat.com Wed Apr 3 14:46:42 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 3 Apr 2019 16:46:42 +0200 Subject: RFR: Backport outstanding changes jdk12 -> sh/jdk11 Message-ID: <8c782660-9412-4a1e-b10e-63b591f9ab65@redhat.com> I'd like to push backports of recent changes coming down from jdk12: List of changes: http://cr.openjdk.java.net/~rkennke/backports-jdk11-2019-04-03/changes.txt Full webrev: http://cr.openjdk.java.net/~rkennke/backports-jdk11-2019-04-03/webrev.00/ Testing: hotspot_gc_shenandoah passes Ok? Roman From shade at redhat.com Wed Apr 3 14:51:11 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 3 Apr 2019 16:51:11 +0200 Subject: RFR: Backport outstanding changes jdk12 -> sh/jdk11 In-Reply-To: <8c782660-9412-4a1e-b10e-63b591f9ab65@redhat.com> References: <8c782660-9412-4a1e-b10e-63b591f9ab65@redhat.com> Message-ID: On 4/3/19 4:46 PM, Roman Kennke wrote: > I'd like to push backports of recent changes coming down from jdk12: > > List of changes: > http://cr.openjdk.java.net/~rkennke/backports-jdk11-2019-04-03/changes.txt > > Full webrev: > http://cr.openjdk.java.net/~rkennke/backports-jdk11-2019-04-03/webrev.00/ Looks good. Go. -Aleksey From rkennke at redhat.com Wed Apr 3 14:54:48 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Wed, 03 Apr 2019 14:54:48 +0000 Subject: hg: shenandoah/jdk11: 4 new changesets Message-ID: <201904031454.x33EsmSJ012722@aojmv0008.oracle.com> Changeset: 5cf51abddfbe Author: shade Date: 2019-03-15 13:01 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/5cf51abddfbe [backport] 8220712: [TESTBUG] gc/shenandoah/compiler/TestMaybeNullUnsafeAccess should run with Shenandoah enabled Reviewed-by: rkennke, roland ! test/hotspot/jtreg/gc/shenandoah/compiler/TestMaybeNullUnsafeAccess.java Changeset: 35c36ebb9474 Author: rkennke Date: 2019-03-18 16:33 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/35c36ebb9474 [backport] 8220780: ShenandoahBS::AccessBarrier::oop_store_in_heap ignores AS_NO_KEEPALIVE Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp Changeset: 92929344bb86 Author: aoqi Date: 2019-03-19 17:03 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/92929344bb86 [backport] 8220812: gc/shenandoah/options/TestLoopMiningArguments.java fails if default GC is serial/parallel/cms Reviewed-by: shade Contributed-by: Ao Qi ! test/hotspot/jtreg/gc/shenandoah/options/TestLoopMiningArguments.java Changeset: 7485813b7a36 Author: rkennke Date: 2019-03-21 22:37 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/7485813b7a36 [backport] 8221278: Shenandoah should not enqueue string dedup candidates during root scan Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp From rkennke at redhat.com Wed Apr 3 16:41:29 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 3 Apr 2019 18:41:29 +0200 Subject: RFR: JDK-8221848: Shenandoah: ArrayCopy post-barrier improvements Message-ID: Just like the arraycopy pre-barrier, the arraycopy post-barrier should check for count == 0 and UPDATEREFS gc-state in the generated stubs to avoid calling into the runtime at all in those cases. The runtime can then elide checking this. Why is this relevant? Because calling into runtime involves storing and restoring *all registers* around the call. That would be 32 (x86) or 64 (aarch64) memory accesses to do nothing at all (outside update-refs-phase or when dealing with empty arraycopy). This change proposes to slightly change the meaning of the UPDATEREFS state: so far it would only be active during the dedicated update-refs phase after evacuation. Updating-references while marking would not have this flag. However, arraycopy is the only place where we use this flag at all, and we use it to determine if current GC phase is actually updating references. I suggest to also activate it during marking (when updating references) and traversal (always also updating references). Then we can make the check in assembly very simple. Bug: https://bugs.openjdk.java.net/browse/JDK-8221848 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8221848/webrev.00/ Testing: hotspot_gc_shenandoah (x86_64 and aarch64) Ok? Roman From rkennke at redhat.com Wed Apr 3 17:13:04 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 3 Apr 2019 19:13:04 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <080b7d98-1144-8111-57b7-0c0334d9147c@oracle.com> References: <87h8bfqqu8.fsf@redhat.com> <080b7d98-1144-8111-57b7-0c0334d9147c@oracle.com> Message-ID: <0103f3a1-bf2e-bbcf-d21c-d186f8332921@redhat.com> > I don't think it should be part of this cleanup. Fair enough. I have run several tests today, and removing the is_Phi() call doesn't seem to negatively impact Shenandoah. Updated webrevs: Incremental: http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.01.diff/ Full: http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.01/ Ok now? Thanks, Roman > Please, file separate RFE to push this change with separate review and > testing. > > Thanks, > Vladimir > > On 4/3/19 4:18 AM, Roland Westrelin wrote: >> >> Hi Vladimir, >> >>> opto/loopnode.cpp new is_Phi check was added. Please, explain. >> >> When we expand barriers, if we find a null check nearby we move the >> barrier close to the null check so there's a better chance of converting >> it to an implicit null check. That happens as part of a pass of loop >> opts. I think that's where that change comes from but I don't remember >> the details. In general we need the control that's assigned to a load to >> not be too conservative. >> >> Anyway, that change is not required for correctness. But it looks >> reasonable to me. >> >> Roland. >> From shade at redhat.com Wed Apr 3 17:33:33 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 3 Apr 2019 19:33:33 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <0103f3a1-bf2e-bbcf-d21c-d186f8332921@redhat.com> References: <87h8bfqqu8.fsf@redhat.com> <080b7d98-1144-8111-57b7-0c0334d9147c@oracle.com> <0103f3a1-bf2e-bbcf-d21c-d186f8332921@redhat.com> Message-ID: <966f7518-8f30-f978-4985-46011786d156@redhat.com> On 4/3/19 7:13 PM, Roman Kennke wrote: > Updated webrevs: > Incremental: > http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.01.diff/ > Full: > http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.01/ Shenandoah parts look good. -Aleksey From aph at redhat.com Thu Apr 4 09:13:27 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Apr 2019 10:13:27 +0100 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: Message-ID: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> On 4/2/19 10:12 PM, Roman Kennke wrote: > The main difference is that instead of ensuring correct invariant when > we store anything into the heap (e.g. read-barrier before reads, > write-barrier before writes, plus a bunch of other stuff), we ensure the > strong invariance on objects when they get loaded, by employing what is > currently our write-barrier. OK, so how does this work? Sure, the OOP load promotes an object to tospace, but how do you ensure that the OOP doesn't become stale when a later phase occurs? -- 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 Apr 4 09:16:34 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 4 Apr 2019 11:16:34 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> References: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> Message-ID: <59493b69-6ba6-8dfe-8ddb-97e172d17584@redhat.com> >> The main difference is that instead of ensuring correct invariant when >> we store anything into the heap (e.g. read-barrier before reads, >> write-barrier before writes, plus a bunch of other stuff), we ensure the >> strong invariance on objects when they get loaded, by employing what is >> currently our write-barrier. > > OK, so how does this work? Sure, the OOP load promotes an object to > tospace, but how do you ensure that the OOP doesn't become stale when > a later phase occurs? Whenever we start an evacuation phase, we pre-evacuate everything that's referenced by stack or registers, and update those stack slots and registers. (We did that with the old barrier-scheme too.) Roman From rkennke at redhat.com Thu Apr 4 09:22:37 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 4 Apr 2019 11:22:37 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <59493b69-6ba6-8dfe-8ddb-97e172d17584@redhat.com> References: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> <59493b69-6ba6-8dfe-8ddb-97e172d17584@redhat.com> Message-ID: >>> The main difference is that instead of ensuring correct invariant when >>> we store anything into the heap (e.g. read-barrier before reads, >>> write-barrier before writes, plus a bunch of other stuff), we ensure the >>> strong invariance on objects when they get loaded, by employing what is >>> currently our write-barrier. >> >> OK, so how does this work? Sure, the OOP load promotes an object to >> tospace, but how do you ensure that the OOP doesn't become stale when >> a later phase occurs? > > Whenever we start an evacuation phase, we pre-evacuate everything that's > referenced by stack or registers, and update those stack slots and > registers. (We did that with the old barrier-scheme too.) Also, outside of evacuation phase, the LRB resolves the oop by reading the fwd ptr. I am not totally sure what you mean by 'stale' though. Roman From rkennke at redhat.com Thu Apr 4 09:51:22 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 4 Apr 2019 11:51:22 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> References: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> Message-ID: <7284c04d-cb6c-8125-4966-d136fe151074@redhat.com> >> The main difference is that instead of ensuring correct invariant when >> we store anything into the heap (e.g. read-barrier before reads, >> write-barrier before writes, plus a bunch of other stuff), we ensure the >> strong invariance on objects when they get loaded, by employing what is >> currently our write-barrier. > > OK, so how does this work? Sure, the OOP load promotes an object to > tospace, but how do you ensure that the OOP doesn't become stale when > a later phase occurs? The nice property of the LRB approach is that it maintains a *strong* invariant over the livecycle of an oop, meaning that we guarantee that an oop that is currently in-use (on stack or register), is in to-space. 1. Whenver we load an oop, we do the usual write-barrier protocol to evacuate it (if needed) or resolve the fwd ptr (otherwise). 2. Whenever anything happens that could make an oop stale, we ensure that the oop is updated. Specifically, in the init-evac pause, we go over all oops in registers, stack and code (== constants), and pre-evac and update the oops. This strong invariant makes it much easier to reason about the lifecycle of oops in the VM. For example, there is no need to worry about comparing oops (cmpxchg-oop remains funny though), no need to worry about resolving oops properly in intrinsics, no need to ensure that oops stored to fields are good, etc. Does all that answer your question? :-) Roman From rkennke at redhat.com Thu Apr 4 10:27:35 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 4 Apr 2019 12:27:35 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: Message-ID: <565ab6ee-5578-aef0-8dba-cf7e59747780@redhat.com> Additional testing on aarch64 showed two problems there: - we must not use rscratch1 in the LRB asm code, there is at least one place where the LRB is called with dst==rscratch1. - we need enter()/leave() around the barrier because this is now called in some places that don't have a proper frame, yet. The fix for the rscratch1 problem also simplifies and streamlines the LRB to be shaped like the C2 generated LRB. It checks for HAS_FORWARDED gc-state, and then dives into the stub, which 1. checks obj in cset, 2. resolves the fwd ptr, 3. compares obj == fwd, and only then dives into slow-path. This passes the failing tests and hotspot_gc_shenandoah on aarch64. jdk/submit job also came back clean. Incremental: http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.02.diff/ Full: http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.02/ Ok to push? Roman > (I am cross-posting this to build-dev and compiler-dev because this > contains some (trivial-ish) shared build and C2 changes. The C2 changes > are almost all reversals of Shenandoah-specific paths that have been > introduced in initial Shenandoah push.) > > I would like to propose that we switch to what we came to call 'load > reference barrier' as new barrier scheme for Shenandoah GC. > > The main difference is that instead of ensuring correct invariant when > we store anything into the heap (e.g. read-barrier before reads, > write-barrier before writes, plus a bunch of other stuff), we ensure the > strong invariance on objects when they get loaded, by employing what is > currently our write-barrier. > > The reason why I'm proposing it is: > - simpler barrier interface > - easier to get good performance out of it > ==> good for upcoming Graal (sup)port > - reduced maintenance burden (I intend to backport it all the way) > > This has a number of advantages: > - Strong invariant means it's a lot easier to reason about the state of > GC and objects > - Much simpler barrier interface. Infact, a lot of stuff that we added > to barrier interfaces after JDK11 will now become unused: no need for > barriers on primitives, no need for object equality barriers, no need > for resolve barriers, etc. Also, some C2 stuff that we added for > Shenandoah can now be removed again. (Those are what comprise most > shared C2 changes.) > - Optimization is much easier: we currently put barriers 'down low' > close to their uses (which might be inside a hot loop), and then work > hard to optimize barriers upwards, e.g. out of loops. By using > load-ref-barriers, we would place them at the outermost site already. > Look how much code is removed from shenandoahSupport.cpp! > - No more need for object equals barriers. > - No more need for 'resolve' barriers. > - All barriers are now conditional, which opens up opportunity for > further optimization later on. > - we can re-enable the fast JNI getfield stuff > - we no longer need the nmethod initializer that initializes embedded > oops to to-space > - We no longer have the problem to use two registers for 'the same' > value (pre- and post-barrier). > > The 'only' optimizations that we do in C2 are: > - Look upwards and see if barrier input indicates we don't actually need > the barrier. Would be the case for: constants, nulls, method parameters, > etc (anything that is not like a load). Even though we insert barriers > after loads, you'd be surprised to see how many loads actually disappear. > - Look downwards to check uses of the barrier. If it doesn't feed into > anything that requires a barrier, we can remove it. > > Performance doesn't seem to be negatively impacted at all. Some > benchmarks benefit positively from it. > > Testing: Testing: hotspot_gc_shenandoah, SPECjvm2008, SPECjbb2015, all > of them many times. This patch has baked in shenandoah/jdk for 1.5 > months, undergone our rigorous CI, received various bug-fixes, we have > had a close look at the generated code to verify it is sane. jdk/submit > job expected good before push. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221766 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.00/ > > Can I please get reviews for this change? > > Roman > > From aph at redhat.com Thu Apr 4 10:45:05 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Apr 2019 11:45:05 +0100 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> <59493b69-6ba6-8dfe-8ddb-97e172d17584@redhat.com> Message-ID: On 4/4/19 10:22 AM, Roman Kennke wrote: >>>> The main difference is that instead of ensuring correct invariant when >>>> we store anything into the heap (e.g. read-barrier before reads, >>>> write-barrier before writes, plus a bunch of other stuff), we ensure the >>>> strong invariance on objects when they get loaded, by employing what is >>>> currently our write-barrier. >>> >>> OK, so how does this work? Sure, the OOP load promotes an object to >>> tospace, but how do you ensure that the OOP doesn't become stale when >>> a later phase occurs? >> >> Whenever we start an evacuation phase, we pre-evacuate everything that's >> referenced by stack or registers, and update those stack slots and >> registers. (We did that with the old barrier-scheme too.) Got it, OK. > Also, outside of evacuation phase, the LRB resolves the oop by reading > the fwd ptr. > > I am not totally sure what you mean by 'stale' though. Maybe you have a different word for it? An oop that points to fromspace even though there is a new copy of the same object in tospace. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Thu Apr 4 10:46:28 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 4 Apr 2019 12:46:28 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <565ab6ee-5578-aef0-8dba-cf7e59747780@redhat.com> References: <565ab6ee-5578-aef0-8dba-cf7e59747780@redhat.com> Message-ID: <0aba2102-cb6f-6bb2-af14-d554b3c3c6ce@redhat.com> On 4/4/19 12:27 PM, Roman Kennke wrote: > - we need enter()/leave() around the barrier because this is now called in some places that don't > have a proper frame, yet. Is it better to put enter/leave we actually call LRB from? I don't know the full implications of this, though. > Incremental: > http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.02.diff/ > Full: > http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.02/ Looks okay to me. Andrew needs to take a look at aarch64 code. This patch fixes AArch64 problems for me. -Aleksey From rkennke at redhat.com Thu Apr 4 11:57:40 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 4 Apr 2019 13:57:40 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <0aba2102-cb6f-6bb2-af14-d554b3c3c6ce@redhat.com> References: <565ab6ee-5578-aef0-8dba-cf7e59747780@redhat.com> <0aba2102-cb6f-6bb2-af14-d554b3c3c6ce@redhat.com> Message-ID: >> - we need enter()/leave() around the barrier because this is now called in some places that don't >> have a proper frame, yet. > > Is it better to put enter/leave we actually call LRB from? Naaa, this would be too cumbersome and introduce stuff into shared code that is only related to the actual LRB. Roman > I don't know the full implications of > this, though. > >> Incremental: >> http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.02.diff/ >> Full: >> http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.02/ > > Looks okay to me. Andrew needs to take a look at aarch64 code. This patch fixes AArch64 problems for me. > > -Aleksey > From rkennke at redhat.com Thu Apr 4 12:00:12 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 4 Apr 2019 14:00:12 +0200 Subject: RFR: Upstream merge jdk-13+15 to sh/jdk Message-ID: <4a620a71-f43d-7309-617c-87c558dbb882@redhat.com> This brings a number of interesting bugfixes and improvements into sh/jdk: http://cr.openjdk.java.net/~rkennke/upstream-jdk13-merge-2019-04-04/changes.txt Merge did have some conflicts in shenandoahBarrierSet* and shenandoahSupport*, but nothing very serious. Testing: hotspot_gc_shenandoah is good Ok? Roman From aph at redhat.com Thu Apr 4 13:37:59 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Apr 2019 14:37:59 +0100 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <565ab6ee-5578-aef0-8dba-cf7e59747780@redhat.com> References: <565ab6ee-5578-aef0-8dba-cf7e59747780@redhat.com> Message-ID: On 4/4/19 11:27 AM, Roman Kennke wrote: > Additional testing on aarch64 showed two problems there: > - we must not use rscratch1 in the LRB asm code, there is at least one > place where the LRB is called with dst==rscratch1. And it might be called with dst==rscratch2, right? You have to code defensively against that. Or at least assert it. > - we need enter()/leave() around the barrier because this is now called > in some places that don't have a proper frame, yet. > > The fix for the rscratch1 problem also simplifies and streamlines the > LRB to be shaped like the C2 generated LRB. It checks for HAS_FORWARDED > gc-state, and then dives into the stub, which 1. checks obj in cset, 2. > resolves the fwd ptr, 3. compares obj == fwd, and only then dives into > slow-path. >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8221766 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.00/ >> >> Can I please get reviews for this change? One thing: Register obj = r0; + __ mov(rscratch2, r0); + resolve_forward_pointer_not_null(cgen->assembler(), r0); + __ cmp(rscratch2, r0); + __ br(Assembler::NE, done); The macro assembler convention is that rscratchX is never preserved across a macro, even if you wrote that macro yourself. I've been trying to clean up these as I go, because this problem has bitten us repeatedly. I guess you know that whatever is called by resolve_forward_pointer_not_null(cgen->assembler(), r0) is okay... Also, if you're going to say Register obj = r0; please either use "obj" everywhere or "r0", not a mixture. I'd just get rid of the Register alias. -- 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 Apr 4 14:56:59 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 4 Apr 2019 16:56:59 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: <565ab6ee-5578-aef0-8dba-cf7e59747780@redhat.com> Message-ID: <937a9ead-9704-c537-ee1e-5e3bf60a4172@redhat.com> >> Additional testing on aarch64 showed two problems there: >> - we must not use rscratch1 in the LRB asm code, there is at least one >> place where the LRB is called with dst==rscratch1. > > And it might be called with dst==rscratch2, right? You have to code > defensively against that. Or at least assert it. Yes, we do have an assert there: assert(dst != rscratch2, "need rscratch2"); >> - we need enter()/leave() around the barrier because this is now called >> in some places that don't have a proper frame, yet. >> >> The fix for the rscratch1 problem also simplifies and streamlines the >> LRB to be shaped like the C2 generated LRB. It checks for HAS_FORWARDED >> gc-state, and then dives into the stub, which 1. checks obj in cset, 2. >> resolves the fwd ptr, 3. compares obj == fwd, and only then dives into >> slow-path. > >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8221766 >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.00/ >>> >>> Can I please get reviews for this change? > > One thing: > > Register obj = r0; > + __ mov(rscratch2, r0); > + resolve_forward_pointer_not_null(cgen->assembler(), r0); > + __ cmp(rscratch2, r0); > + __ br(Assembler::NE, done); > > The macro assembler convention is that rscratchX is never preserved > across a macro, even if you wrote that macro yourself. I've been > trying to clean up these as I go, because this problem has bitten us > repeatedly. I guess you know that whatever is called by > resolve_forward_pointer_not_null(cgen->assembler(), r0) is okay... Yeah... In this case, resolve_forward_pointer_not_null() is really just a single instruction (the load of the fwd ptr into the same register) and I know it is not trashing anything else. I could expand that load right there to make it more obvious, however this might become more complex soon when we eliminate the fwd ptr. But even then, I will make sure that it will still be a single-register-macro. > Also, if you're going to say > > Register obj = r0; > > please either use "obj" everywhere or "r0", not a mixture. > I'd just get rid of the Register alias. > That sounds reasonable. Incremental: http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.03.diff/ Full: http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.03/ Ok to push it like this? Roman From aph at redhat.com Thu Apr 4 15:18:25 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Apr 2019 16:18:25 +0100 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <937a9ead-9704-c537-ee1e-5e3bf60a4172@redhat.com> References: <565ab6ee-5578-aef0-8dba-cf7e59747780@redhat.com> <937a9ead-9704-c537-ee1e-5e3bf60a4172@redhat.com> Message-ID: On 4/4/19 3:56 PM, Roman Kennke wrote: > Yeah... In this case, resolve_forward_pointer_not_null() is really just > a single instruction (the load of the fwd ptr into the same register) > and I know it is not trashing anything else. I could expand that load > right there to make it more obvious, however this might become more > complex soon when we eliminate the fwd ptr. But even then, I will make > sure that it will still be a single-register-macro. // BIG COMMENT NEEDED HERE TO SAY IT PRESERVES ALL REGISTERS >> Also, if you're going to say >> >> Register obj = r0; >> >> please either use "obj" everywhere or "r0", not a mixture. >> I'd just get rid of the Register alias. >> > That sounds reasonable. > > Incremental: > http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.03.diff/ > Full: > http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.03/ > > Ok to push it like this? Sure. With big comment. No need for a resubmit. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Thu Apr 4 16:28:39 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 4 Apr 2019 18:28:39 +0200 Subject: RFR: Upstream merge jdk-13+15 to sh/jdk In-Reply-To: <4a620a71-f43d-7309-617c-87c558dbb882@redhat.com> References: <4a620a71-f43d-7309-617c-87c558dbb882@redhat.com> Message-ID: <0d3062fd-0f4b-ede3-5640-cd215dc6be3c@redhat.com> On 4/4/19 2:00 PM, Roman Kennke wrote: > This brings a number of interesting bugfixes and improvements into sh/jdk: > > http://cr.openjdk.java.net/~rkennke/upstream-jdk13-merge-2019-04-04/changes.txt OK, looks good. -Aleksey From rkennke at redhat.com Thu Apr 4 17:29:29 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Thu, 04 Apr 2019 17:29:29 +0000 Subject: hg: shenandoah/jdk: 101 new changesets Message-ID: <201904041729.x34HTZd8011463@aojmv0008.oracle.com> Changeset: 7d5a4a48e876 Author: joehw Date: 2019-03-27 14:40 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/7d5a4a48e876 8221533: Incorrect copyright header in DurationDayTimeImpl.java, DurationYearMonthImpl.java and XMLStreamException.java Reviewed-by: bpb, lancea ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java ! src/java.xml/share/classes/javax/xml/stream/XMLStreamException.java Changeset: f714e4cebceb Author: bpb Date: 2019-03-27 16:35 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f714e4cebceb 8221568: DataOutputStream/WriteUTF.java fails due to "OutOfMemoryError: Java heap space" Reviewed-by: shade ! test/jdk/java/io/DataOutputStream/WriteUTF.java Changeset: 5b5bd291ca32 Author: jwilhelm Date: 2019-03-28 01:43 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/5b5bd291ca32 Added tag jdk-13+14 for changeset 46cf212cdcca ! .hgtags Changeset: c0037e86ec02 Author: dtitov Date: 2019-03-28 04:26 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/c0037e86ec02 8218727: vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/TestDescription.java crash in native library Reviewed-by: sspitsyn, gadams ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002/em07t002.cpp Changeset: 55025f677f68 Author: dtitov Date: 2019-03-28 04:30 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/55025f677f68 8221532: Incorrect copyright header in FileSystemSupport_md.c Reviewed-by: cjplummer, gadams ! src/java.instrument/unix/native/libinstrument/FileSystemSupport_md.c ! src/java.instrument/windows/native/libinstrument/FileSystemSupport_md.c Changeset: e9618b37f0a5 Author: goetz Date: 2019-03-28 09:15 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/e9618b37f0a5 8221398: Move test NoClassDefFoundMsg.java to subdir exceptionMsgs/ Reviewed-by: coleenp + test/hotspot/jtreg/runtime/exceptionMsgs/NoClassDefFoundError/NoClassDefFoundErrorTest.java + test/hotspot/jtreg/runtime/exceptionMsgs/NoClassDefFoundError/libNoClassDefFoundErrorTest.c - test/hotspot/jtreg/runtime/noClassDefFoundMsg/NoClassDefFoundMsg.java - test/hotspot/jtreg/runtime/noClassDefFoundMsg/libNoClassDefFoundMsg.c Changeset: c9a492ad1aed Author: jlahoda Date: 2019-03-28 10:32 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/c9a492ad1aed 8221413: javac does not recognize variable assigned in switch expression as DA Summary: Fixing definite assignment in presence of implicit throws clause in switch expressions over enums. Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! test/langtools/tools/javac/switchexpr/DefiniteAssignment1.java Changeset: cf75ea6af695 Author: stuefe Date: 2019-03-25 09:35 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/cf75ea6af695 8220786: Create new switch to redirect error reporting output to stdout or stderr Reviewed-by: dholmes, goetz ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/utilities/vmError.cpp + test/hotspot/jtreg/runtime/ErrorHandling/ErrorFileRedirectTest.java Changeset: 846bc643f4ef Author: rehn Date: 2019-03-28 11:08 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/846bc643f4ef 8220351: Cross-modifying code Reviewed-by: rrich, mdoerr, dholmes, eosterlund ! src/hotspot/os_cpu/aix_ppc/orderAccess_aix_ppc.hpp ! src/hotspot/os_cpu/bsd_x86/orderAccess_bsd_x86.hpp ! src/hotspot/os_cpu/bsd_zero/orderAccess_bsd_zero.hpp ! src/hotspot/os_cpu/linux_aarch64/orderAccess_linux_aarch64.hpp ! src/hotspot/os_cpu/linux_arm/orderAccess_linux_arm.hpp ! src/hotspot/os_cpu/linux_ppc/orderAccess_linux_ppc.hpp ! src/hotspot/os_cpu/linux_s390/orderAccess_linux_s390.hpp ! src/hotspot/os_cpu/linux_sparc/orderAccess_linux_sparc.hpp ! src/hotspot/os_cpu/linux_x86/orderAccess_linux_x86.hpp ! src/hotspot/os_cpu/linux_zero/orderAccess_linux_zero.hpp ! src/hotspot/os_cpu/solaris_sparc/orderAccess_solaris_sparc.hpp ! src/hotspot/os_cpu/solaris_x86/orderAccess_solaris_x86.hpp ! src/hotspot/os_cpu/windows_x86/orderAccess_windows_x86.hpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/orderAccess.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/safepointMechanism.cpp ! src/hotspot/share/runtime/safepointMechanism.hpp ! src/hotspot/share/runtime/safepointMechanism.inline.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: 9d5c84b0a598 Author: dfuchs Date: 2019-03-28 12:16 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/9d5c84b0a598 8221395: HttpClient leaving connections in CLOSE_WAIT state until Java process ends Summary: When a non WebSocket connection is not returned to the pool, it needs to be closed even if HttpConnection::isOpen yields false. Reviewed-by: chegar, michaelm ! src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java ! test/jdk/java/net/httpclient/whitebox/ConnectionPoolTestDriver.java ! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/ConnectionPoolTest.java Changeset: 04f1a0f925db Author: erikj Date: 2019-03-28 08:37 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/04f1a0f925db 8220530: Build compare script does not compare the contents of the test image Reviewed-by: tbell ! make/conf/jib-profiles.js ! make/scripts/compare.sh ! make/scripts/compare_exceptions.sh.incl Changeset: eb7f2c367f73 Author: erikj Date: 2019-03-28 10:04 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/eb7f2c367f73 8205934: Define jdk -source/-target version in version-numbers file Reviewed-by: tbell ! make/autoconf/jdk-version.m4 ! make/autoconf/spec.gmk.in ! make/autoconf/version-numbers ! make/common/SetupJavaCompilers.gmk Changeset: a4d19817609c Author: jcbeyler Date: 2019-03-28 11:06 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a4d19817609c 8157372: C2: Node::cmp() should return bool Summary: The method Node::cmp() should return a boolean Reviewed-by: vlivanov, kvn Contributed-by: dthomson at google.com ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/castnode.cpp ! src/hotspot/share/opto/castnode.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/locknode.cpp ! src/hotspot/share/opto/locknode.hpp ! src/hotspot/share/opto/machnode.cpp ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/hotspot/share/opto/multnode.cpp ! src/hotspot/share/opto/multnode.hpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/opaquenode.cpp ! src/hotspot/share/opto/opaquenode.hpp ! src/hotspot/share/opto/subnode.cpp ! src/hotspot/share/opto/subnode.hpp Changeset: 37648a9c4a6a Author: jwilhelm Date: 2019-03-28 19:39 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/37648a9c4a6a 8221341: Update Graal Reviewed-by: kvn ! src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/DataPatchProcessor.java ! src/jdk.internal.vm.ci/share/classes/module-info.java ! src/jdk.internal.vm.compiler.management/share/classes/org.graalvm.compiler.hotspot.management/src/org/graalvm/compiler/hotspot/management/HotSpotGraalRuntimeMBean.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Assembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64MacroAssembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm/src/org/graalvm/compiler/asm/Assembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64ArithmeticLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64LIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.amd64.test/src/org/graalvm/compiler/core/amd64/test/AMD64MatchRuleTest.java ! 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/Fields.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/FieldsScanner.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/GraalOptions.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/UnsafeAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/UnsafeAccess.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/UnsafeArrayTypeReader.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/UnsafeArrayTypeWriter.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.match.processor/src/org/graalvm/compiler/core/match/processor/MatchProcessor.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/CheckGraalInvariants.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/FinalizableSubclassTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/NewInstanceTest.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/SwitchTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/UnbalancedMonitorsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyBailoutUsage.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyCallerSensitiveMethods.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyDebugUsage.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyFoldableMethods.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyGetOptionsUsage.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyGraphAddUsage.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyInstanceOfUsage.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifySystemPropertyUsage.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyUnsafeAccess.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyUpdateUsages.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyUsageWithEquals.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/VerifyVirtualizableUsage.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/ea/EATestBase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/tutorial/StaticAnalysis.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/tutorial/StaticAnalysisTests.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/LIRGenerationPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/gen/NodeLIRBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/gen/NodeMatchRules.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/match/MatchContext.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/match/MatchPattern.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/match/MatchStatement.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/match/MatchableNode.java ! 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/LogStream.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/MemUseTrackerKey.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.debug/src/org/graalvm/compiler/debug/Versions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/Edges.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/Node.java ! 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.graph/src/org/graalvm/compiler/graph/NodeSourcePosition.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/UnsafeAccess.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotBackendFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64IndirectCallOp.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64ArrayCompareToStub.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64ArrayEqualsStub.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotNodeLIRBuilder.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/NodeCostDumpUtil.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/StringInternConstantTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/BootstrapWatchDog.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompilationStatistics.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompilationTask.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompilationWatchDog.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfigBase.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/HotSpotGraalCompilerFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalRuntime.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotTTYStreamProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/IsGraalPredicate.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/IsGraalPredicateBase.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/NodeCostDumpUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/SymbolicSnippetEncoder.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/meta/HotSpotNodePlugin.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotObjdumpDisassemblerProvider.java ! 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/phases/AheadOfTimeVerificationPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/BytecodeParser.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/FrameStateBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/GraphBuilderPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64ArithmeticLIRGeneratorTool.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64Call.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64Compare.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64ControlFlow.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64MathIntrinsicBinaryOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64Move.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ArrayIndexOfOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64Binary.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64BinaryConsumer.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/gen/LIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/gen/LIRGeneratorTool.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/hashing/HashFunction.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/hashing/Hasher.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/SimplifyingGraphDecoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/JavaWriteNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/GraphBuilderConfiguration.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/GraphBuilderTool.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/NodePlugin.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/memory/AbstractWriteNode.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/CoreProviders.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/CoreProvidersImpl.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/LoweringTool.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/NodeLIRBuilderTool.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.options/src/org/graalvm/compiler/options/OptionsParser.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/LoweringPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/ProfileCompiledMethodsPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/walker/InliningData.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/VerifyPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/tiers/PhaseContext.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases/src/org/graalvm/compiler/phases/util/Providers.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/GraphPrinterDumpHandler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64GraphBuilderPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/CachingPEGraphDecoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/ConstantStringIndexOfSnippets.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/GraphKit.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/InlineDuringParsingPlugin.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/IntrinsicGraphBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/PEGraphDecoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/ReplacementsImpl.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/SnippetCounterNode.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/UnsafeAccess.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/ClassfileBytecodeProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/ArrayCompareToNode.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/ArrayRegionEqualsNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/MacroNode.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalUnsafeAccess.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/JavaVersionUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/EffectsClosure.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/PartialEscapeClosure.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/UnsafeAccess.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/Word.java Changeset: ddd60ad787d4 Author: pliden Date: 2019-03-28 19:43 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/ddd60ad787d4 8221394: Clean up ConcurrentGCThread Reviewed-by: kbarrett, eosterlund ! src/hotspot/share/gc/shared/concurrentGCThread.cpp ! src/hotspot/share/gc/shared/concurrentGCThread.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: 69e80a82db9a Author: pliden Date: 2019-03-28 19:43 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/69e80a82db9a 8221540: ZGC: Reduce width of zForwardingEntry::from_index field Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zForwarding.cpp ! src/hotspot/share/gc/z/zForwarding.inline.hpp ! src/hotspot/share/gc/z/zForwardingEntry.hpp ! src/hotspot/share/gc/z/zRelocate.cpp ! test/hotspot/gtest/gc/z/test_zForwarding.cpp Changeset: f0fec71d2fff Author: pliden Date: 2019-03-28 19:43 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f0fec71d2fff 8221153: ZGC: Heap iteration and verification pollutes GC statistics Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zHeap.cpp ! src/hotspot/share/gc/z/zHeapIterator.cpp ! src/hotspot/share/gc/z/zStat.cpp ! src/hotspot/share/gc/z/zStat.hpp Changeset: 9a8fe0bc38c3 Author: cushon Date: 2019-03-26 16:09 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/9a8fe0bc38c3 8220632: Suggest recompiling with a larger value of -Xmaxerrs/-Xmaxwarns if diagnostics were suppressed Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java + test/langtools/tools/javac/diags/examples/CountErrorRecompile.java + test/langtools/tools/javac/diags/examples/CountWarnRecompile.java + test/langtools/tools/javac/warnings/MaxDiagsRecompile.all.out + test/langtools/tools/javac/warnings/MaxDiagsRecompile.java + test/langtools/tools/javac/warnings/MaxDiagsRecompile.max1.out + test/langtools/tools/javac/warnings/MaxWarnsRecompile.all.out + test/langtools/tools/javac/warnings/MaxWarnsRecompile.java + test/langtools/tools/javac/warnings/MaxWarnsRecompile.max1.out Changeset: 2a29e62446bd Author: valeriep Date: 2019-03-29 00:39 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/2a29e62446bd 8220016: Clean up redundant RSA services in the SunJSSE provider Summary: Removed duplicated RSA signature/KF/KPG support in SunJSSE Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/SunJSSE.java ! test/jdk/java/security/Signature/Offsets.java ! test/jdk/java/security/SignedObject/Chain.java ! test/jdk/sun/security/pkcs11/KeyStore/Basic.java + test/jdk/sun/security/rsa/BrokenRSAPrivateCrtKey.java - test/jdk/sun/security/ssl/rsa/BrokenRSAPrivateCrtKey.java + test/jdk/sun/security/ssl/rsa/CheckProviderEntries.java ! test/jdk/sun/security/ssl/rsa/SignatureOffsets.java ! test/jdk/sun/security/ssl/rsa/SignedObjectChain.java Changeset: f1548abd4ae0 Author: iklam Date: 2019-03-28 20:45 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f1548abd4ae0 8221621: FindTests.gmk cannot handle "=" in TEST.groups comments Reviewed-by: erikj, dholmes ! make/common/FindTests.gmk Changeset: d9f6d16299b1 Author: stuefe Date: 2019-03-29 08:36 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/d9f6d16299b1 8221408: Windows 32bit build build errors/warnings in hotspot Reviewed-by: kbarrett, dholmes ! src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/oops/markOop.hpp Changeset: a335a4ddc631 Author: zgu Date: 2019-03-29 10:21 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a335a4ddc631 8221688: Quarantine Shenandoah string dedup tests Reviewed-by: rkennke ! test/hotspot/jtreg/ProblemList.txt Changeset: 5a9d780eb9dd Author: redestad Date: 2019-03-29 15:59 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/5a9d780eb9dd 8221687: Deprecated j.u.jar.Attributes.Name attributes accidentally set to null Reviewed-by: alanb ! src/java.base/share/classes/java/util/jar/Attributes.java Changeset: 7a34a3270270 Author: zgu Date: 2019-03-26 12:12 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/7a34a3270270 8221435: Shenandoah should not mark through weak roots Reviewed-by: rkennke, shade ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.cpp ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp Changeset: f69a2f675f19 Author: ronsh Date: 2019-03-29 07:38 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f69a2f675f19 8221118: Avoid eagerly creating JCDiagnostic for CompletionFailures Reviewed-by: jjg, mcimadamore, forax ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! test/langtools/tools/javac/defaultMethods/BadClassfile.java Changeset: 2221f042556d Author: iklam Date: 2019-03-29 08:42 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/2221f042556d 8221351: Crash in KlassFactory::check_shared_class_file_load_hook Reviewed-by: dholmes, ccheung ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/classfile/klassFactory.cpp ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/memory/filemap.hpp ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/runtime/appcds/TestCommon.java ! test/hotspot/jtreg/runtime/appcds/customLoader/HelloCustom.java + test/hotspot/jtreg/runtime/appcds/customLoader/HelloCustom_JFR.java ! test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ModulePathAndCP.java + test/hotspot/jtreg/runtime/appcds/jigsaw/modulepath/ModulePathAndCP_JFR.java ! test/hotspot/jtreg/runtime/appcds/jvmti/ClassFileLoadHook.java ! test/hotspot/jtreg/runtime/appcds/jvmti/ClassFileLoadHookTest.java Changeset: 0b47455de59b Author: stuefe Date: 2019-03-26 16:26 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/0b47455de59b 8221480: jcmd VM.metaspace shall print limits in basic mode Reviewed-by: adinn, rehn ! src/hotspot/share/memory/metaspace.cpp ! test/hotspot/jtreg/runtime/Metaspace/PrintMetaspaceDcmd.java Changeset: 07212a29787a Author: joehw Date: 2019-03-29 18:00 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/07212a29787a 8220254: fix headings in java.xml Reviewed-by: lancea ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegularExpression.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java ! src/java.xml/share/classes/javax/xml/catalog/CatalogResolver.java ! src/java.xml/share/classes/javax/xml/datatype/DatatypeFactory.java ! src/java.xml/share/classes/javax/xml/parsers/DocumentBuilderFactory.java ! src/java.xml/share/classes/javax/xml/parsers/SAXParserFactory.java ! src/java.xml/share/classes/javax/xml/transform/TransformerFactory.java ! src/java.xml/share/classes/javax/xml/validation/SchemaFactory.java ! src/java.xml/share/classes/javax/xml/xpath/XPathFactory.java Changeset: 6a1406c718ec Author: zgu Date: 2019-03-29 14:17 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/6a1406c718ec 8221643: Tighten up assert(_keep_alive >= 0) in CLD::inc_keep_alive Reviewed-by: coleenp ! src/hotspot/share/classfile/classLoaderData.cpp Changeset: 8cd2af66ac7c Author: zgu Date: 2019-03-28 13:53 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/8cd2af66ac7c 8221629: Shenandoah: Cleanup class unloading logic Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp + src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp Changeset: 1042cac8bc2a Author: mseledtsov Date: 2019-03-29 18:25 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/1042cac8bc2a 8221596: test/hotspot/jtreg/runtime/containers/docker/TestCPUSets.java failed with FileAlreadyExistsException Summary: Using StandardCopyOption.REPLACE_EXISTING to copy whitebox.jar Reviewed-by: dholmes, mseledtsov Contributed-by: jiefu ! test/lib/jdk/test/lib/containers/docker/Common.java Changeset: b7ebff3e4e69 Author: weijun Date: 2019-03-30 16:32 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b7ebff3e4e69 8221257: Improve serial number generation mechanism for keytool -gencert Reviewed-by: xuelei, mullan ! src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/x509/CertificateSerialNumber.java + test/jdk/sun/security/tools/keytool/Serial64.java Changeset: 235883996bc7 Author: iklam Date: 2019-03-30 08:26 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/235883996bc7 8221698: Remove redundant includes from popular header files Summary: Removed histogram.hpp classLoader.hpp utf8.hpp moduleEntry.hpp packageEntry.hpp Reviewed-by: coleenp, stuefe ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/moduleEntry.cpp ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/classfile/symbolTable.cpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/memory/oopFactory.cpp ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/prims/unsafe.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/services/management.cpp Changeset: f062188117ad Author: clanger Date: 2019-03-30 21:29 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f062188117ad 8221610: Resurrect (legacy) JRE bundle target Reviewed-by: erikj, azeller ! make/Bundles.gmk ! make/Main.gmk ! make/autoconf/spec.gmk.in Changeset: 492af1f4b6d5 Author: ngasson Date: 2019-03-29 09:31 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/492af1f4b6d5 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g Reviewed-by: clanger, sballal, jcbeyler ! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java Changeset: 4f9772f4403d Author: pmuthuswamy Date: 2019-04-01 12:44 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/4f9772f4403d 8215599: Remove support for javadoc "frames" mode Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractPackageIndexWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllPackagesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DocFilesHandlerImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FrameOutputWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleFrameWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageFrameWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java - test/langtools/jdk/javadoc/doclet/AccessFrameTitle/AccessFrameTitle.java - test/langtools/jdk/javadoc/doclet/AccessFrameTitle/p1/C1.java - test/langtools/jdk/javadoc/doclet/AccessFrameTitle/p2/C2.java ! test/langtools/jdk/javadoc/doclet/AccessH1/AccessH1.java ! test/langtools/jdk/javadoc/doclet/AccessSummary/AccessSummary.java ! test/langtools/jdk/javadoc/doclet/DocRootSlash/DocRootSlash.java ! test/langtools/jdk/javadoc/doclet/JavascriptWinTitle/JavascriptWinTitle.java ! test/langtools/jdk/javadoc/doclet/MetaTag/MetaTag.java - test/langtools/jdk/javadoc/doclet/PackagesHeader/PackagesHeader.java - test/langtools/jdk/javadoc/doclet/PackagesHeader/p1/C1.java - test/langtools/jdk/javadoc/doclet/PackagesHeader/p2/C2.java ! test/langtools/jdk/javadoc/doclet/ValidHtml/ValidHtml.java ! test/langtools/jdk/javadoc/doclet/WindowTitles/WindowTitles.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/TestClassDocCatalog.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyAnnotation.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyClass.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyEnum.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyError.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyException.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyInterface.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyAnnotation.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyClass.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyEnum.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyError.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyException.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyInterface.java - test/langtools/jdk/javadoc/doclet/testFramesNoFrames/TestFramesNoFrames.java ! test/langtools/jdk/javadoc/doclet/testGeneratedBy/TestGeneratedBy.java ! test/langtools/jdk/javadoc/doclet/testGroupName/TestGroupName.java ! test/langtools/jdk/javadoc/doclet/testGroupOption/TestGroupOption.java ! test/langtools/jdk/javadoc/doclet/testHeadings/TestHeadings.java ! test/langtools/jdk/javadoc/doclet/testHiddenTag/TestHiddenTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlLandmarkRegions/TestHtmlLandmarkRegions.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/langtools/jdk/javadoc/doclet/testIndex/TestIndex.java ! test/langtools/jdk/javadoc/doclet/testIndexWithModules/TestIndexWithModules.java ! test/langtools/jdk/javadoc/doclet/testJavascript/TestJavascript.java ! test/langtools/jdk/javadoc/doclet/testMetadata/TestMetadata.java ! test/langtools/jdk/javadoc/doclet/testModuleDirs/TestModuleDirs.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java ! test/langtools/jdk/javadoc/doclet/testNavigation/TestNavigation.java ! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java + test/langtools/jdk/javadoc/doclet/testNoFrames/TestNoFrames.java ! test/langtools/jdk/javadoc/doclet/testOrdering/TestOrdering.java ! test/langtools/jdk/javadoc/doclet/testOverview/TestOverview.java ! test/langtools/jdk/javadoc/doclet/testPackageDeprecation/TestPackageDeprecation.java ! test/langtools/jdk/javadoc/doclet/testRecurseSubPackages/TestRecurseSubPackages.java ! test/langtools/jdk/javadoc/doclet/testRelativeLinks/TestRelativeLinks.java ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/langtools/jdk/javadoc/doclet/testSummaryTag/TestSummaryTag.java ! test/langtools/jdk/javadoc/doclet/testTopOption/TestTopOption.java ! test/langtools/jdk/javadoc/doclet/testUseOption/TestUseOption.java - test/langtools/jdk/javadoc/doclet/testWindowTitle/TestWindowTitle.java - test/langtools/jdk/javadoc/doclet/testWindowTitle/p1/C1.java - test/langtools/jdk/javadoc/doclet/testWindowTitle/p2/C2.java ! test/langtools/jdk/javadoc/tool/TestScriptInComment.java Changeset: 964186594f5f Author: shade Date: 2019-04-01 10:02 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/964186594f5f 8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot) Reviewed-by: dholmes, stuefe ! src/hotspot/cpu/aarch64/aarch64.ad Changeset: e0603b4537c3 Author: shade Date: 2019-04-01 10:04 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/e0603b4537c3 8221726: Multiple build failures after JDK-8221698 (Remove redundant includes from popular header files) Reviewed-by: dholmes, stuefe, iklam ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp ! src/hotspot/share/classfile/systemDictionary.hpp Changeset: dfaa9daab43c Author: shade Date: 2019-04-01 13:33 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/dfaa9daab43c 8221735: Shenandoah fails ctw/modules/jdk_management_agent.java with Traversal Reviewed-by: rkennke, roland ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Changeset: 80830caaac6e Author: gadams Date: 2019-04-01 07:34 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/80830caaac6e 8221694: jstatLineCounts1 needs to be NaN resilient Reviewed-by: cjplummer, jcbeyler ! test/jdk/sun/tools/jstat/lineCounts1.awk ! test/jdk/sun/tools/jstat/lineCounts2.awk Changeset: f226ab0b7f21 Author: coleenp Date: 2019-04-01 09:53 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f226ab0b7f21 8221183: Avoid code cache walk in MetadataOnStackMark Summary: Note nmethods with "old" Methods in them in table to walk instead. Reviewed-by: eosterlund, sspitsyn ! src/hotspot/share/aot/aotCompiledMethod.hpp ! src/hotspot/share/classfile/classLoaderDataGraph.cpp ! src/hotspot/share/classfile/metadataOnStackMark.cpp ! src/hotspot/share/classfile/metadataOnStackMark.hpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/compiledMethod.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp Changeset: 62e87f00e420 Author: rkennke Date: 2019-04-01 16:30 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/62e87f00e420 8221750: Shenandoah: Enable ThreadLocalHandshake by default Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp Changeset: a8564226f446 Author: hannesw Date: 2019-04-01 16:49 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a8564226f446 8219733: Restore javadoc header styles Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Changeset: 72b637d53318 Author: hannesw Date: 2019-04-01 16:51 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/72b637d53318 8221366: Search box tries to search for "Search" Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java Changeset: 3d8934bf505a Author: naoto Date: 2019-04-01 08:19 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/3d8934bf505a 8205432: Replace the placeholder Japanese era name Reviewed-by: rriggs, chegar ! make/data/cldr/common/main/ja.xml ! make/data/cldr/common/main/root.xml ! make/data/unicodedata/UnicodeData.txt ! src/java.base/share/classes/java/time/chrono/JapaneseEra.java ! src/java.base/share/classes/java/util/JapaneseImperialCalendar.java ! src/java.base/share/classes/sun/text/resources/FormatData.java ! src/java.base/share/classes/sun/text/resources/JavaTimeSupplementary.java ! src/java.base/share/classes/sun/util/calendar/Era.java ! src/java.base/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ja.java ! src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_ja.java ! test/jdk/java/lang/Character/UnicodeData.txt ! test/jdk/java/text/Format/DateFormat/WeekDateTest.java ! test/jdk/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/jdk/java/time/tck/java/time/chrono/TCKJapaneseEra.java ! test/jdk/java/time/test/java/time/chrono/TestJapaneseChronology.java ! test/jdk/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java ! test/jdk/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/jdk/java/util/Calendar/CalendarTestScripts/CalendarAdapter.java ! test/jdk/java/util/Calendar/CalendarTestScripts/Symbol.java ! test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese.cts ! test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_add.cts ! test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_minmax.cts ! test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_roll.cts ! test/jdk/java/util/Calendar/JapaneseEraNameTest.java ! test/jdk/java/util/Calendar/JapaneseLenientEraTest.java ! test/jdk/java/util/Calendar/NarrowNamesTest.java ! test/jdk/java/util/Calendar/ZoneOffsets.java Changeset: 6a4abdb6749c Author: naoto Date: 2019-04-01 08:21 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/6a4abdb6749c 8174268: Declare a public field in JapaneseEra for the era starting May 2019 Reviewed-by: rriggs, chegar ! src/java.base/share/classes/java/time/chrono/JapaneseChronology.java ! src/java.base/share/classes/java/time/chrono/JapaneseEra.java ! src/java.base/share/classes/java/util/spi/CalendarNameProvider.java ! test/jdk/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/jdk/java/time/tck/java/time/chrono/TCKJapaneseEra.java ! test/jdk/java/time/test/java/time/chrono/TestEraDisplayName.java ! test/jdk/java/time/test/java/time/chrono/TestJapaneseChronology.java Changeset: 879051d3772a Author: stefank Date: 2019-04-01 18:34 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/879051d3772a 8220610: Make CollectedHeap nmethod functions pure virtual Reviewed-by: shade ! src/hotspot/share/gc/epsilon/epsilonHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp Changeset: 313e034d0bcb Author: stefank Date: 2019-04-01 18:34 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/313e034d0bcb 8221146: ZGC: Reports too much relocated Reviewed-by: pliden, eosterlund ! src/hotspot/share/gc/z/zRelocationSetSelector.cpp Changeset: f60c52198a42 Author: stefank Date: 2019-04-01 18:36 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f60c52198a42 8221149: os::malloc checks MallocCatchPtr outside of ifdef ASSERT block Reviewed-by: stuefe, dholmes ! src/hotspot/share/runtime/os.cpp Changeset: baf213e62aeb Author: stefank Date: 2019-04-01 18:36 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/baf213e62aeb 8221558: Remove obsolete uses of OopStorage::ParState<'false, false> _par_state Reviewed-by: pliden, tschatzl ! src/hotspot/share/gc/cms/concurrentMarkSweepGeneration.cpp ! src/hotspot/share/gc/cms/parNewGeneration.cpp ! src/hotspot/share/gc/cms/parNewGeneration.hpp ! src/hotspot/share/gc/g1/g1RootProcessor.cpp ! src/hotspot/share/gc/g1/g1RootProcessor.hpp Changeset: dd5c64326027 Author: erikj Date: 2019-04-01 11:02 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/dd5c64326027 8221703: Rmic build for java.management.api has bad incremental behavior Reviewed-by: tbell ! make/common/RMICompilation.gmk ! make/rmic/Rmic-java.management.rmi.gmk Changeset: 2b48cedce327 Author: kbarrett Date: 2019-04-01 17:11 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/2b48cedce327 8220671: Initialization race for non-JavaThread PtrQueues Summary: Include on_thread_(attach|detach) under NJTList_lock. Reviewed-by: pliden, rkennke ! src/hotspot/share/gc/g1/g1BarrierSet.cpp ! src/hotspot/share/gc/shared/barrierSet.hpp ! src/hotspot/share/gc/shared/satbMarkQueue.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: e2c096943ba2 Author: ctornqvi Date: 2019-04-01 14:34 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/e2c096943ba2 8212627: [TESTBUG] runtime/CreateMirror/ArraysNewInstanceBug.java timed out Reviewed-by: coleenp, dcubed, hseigel ! test/hotspot/jtreg/runtime/CreateMirror/ArraysNewInstanceBug.java Changeset: f15b5d110fbc Author: sangheki Date: 2019-04-01 14:54 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f15b5d110fbc 8221517: G1: Reserved page size for heap can be wrong Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp + test/hotspot/jtreg/gc/g1/TestLargePageUseForHeap.java Changeset: 66185e52b979 Author: bpb Date: 2019-04-01 15:59 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/66185e52b979 8218418: (fs) Files.createSymbolicLink should use SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE (win) Reviewed-by: alanb ! src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c Changeset: e057e45b49af Author: xuelei Date: 2019-04-01 16:50 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/e057e45b49af 8168261: Use server cipher suites preference by default Reviewed-by: mullan ! src/java.base/share/classes/javax/net/ssl/SSLContextSpi.java ! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java + test/jdk/sun/security/ssl/SSLContextImpl/DefaultCipherSuitePreference.java Changeset: 72e44c1e7dc6 Author: aoqi Date: 2019-04-02 00:23 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/72e44c1e7dc6 8221763: Build fails when using --with-jvm-features=-g1gc,-jfr,-shenandoahgc Summary: Add missing #include of softRefPolicy.hpp Reviewed-by: kbarrett ! src/hotspot/share/memory/metaspaceShared.cpp Changeset: 9ac5d41abf68 Author: weijun Date: 2019-04-02 10:17 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/9ac5d41abf68 8157404: Unable to read certain PKCS12 keystores from SequenceInputStream Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/util/DerIndefLenConverter.java ! src/java.base/share/classes/sun/security/util/DerInputStream.java ! src/java.base/share/classes/sun/security/util/DerValue.java Changeset: 13935056b05e Author: weijun Date: 2019-04-02 11:05 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/13935056b05e 8221801: Update src/java.base/share/legal/public_suffix.md Reviewed-by: xuelei ! src/java.base/share/legal/public_suffix.md + test/jdk/sun/security/util/RegisteredDomain/Versions.java Changeset: 22eb1f7416f1 Author: mbaesken Date: 2019-03-27 10:25 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/22eb1f7416f1 8221541: clean up functions in CompilerOracle Reviewed-by: mdoerr, kvn ! src/hotspot/share/compiler/compilerOracle.cpp ! src/hotspot/share/compiler/compilerOracle.hpp Changeset: a5ce9300462f Author: pliden Date: 2019-04-02 10:04 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a5ce9300462f 8221648: Remove CollectedHeap::is_in_closed_subset() Reviewed-by: kbarrett, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shared/genCollectedHeap.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/memory/iterator.inline.hpp Changeset: 2a2fab6fb3a5 Author: pliden Date: 2019-04-02 10:04 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/2a2fab6fb3a5 8221732: Introduce CollectedHeap::hash_oop() Reviewed-by: kbarrett, tschatzl, stefank ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/gc/z/zHeap.hpp ! src/hotspot/share/gc/z/zHeap.inline.hpp ! src/hotspot/share/prims/jvmtiTagMap.cpp Changeset: 35794e8db61b Author: pliden Date: 2019-04-02 10:04 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/35794e8db61b 8221748: Remove unused oopDesc::is_unlocked_oop() Reviewed-by: kbarrett ! src/hotspot/share/oops/oop.cpp ! src/hotspot/share/oops/oop.hpp Changeset: 7c576e4d0afa Author: redestad Date: 2019-04-02 11:24 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/7c576e4d0afa 8221723: Avoid storing zero to String.hash Reviewed-by: shade, prappo, jiangli ! src/java.base/share/classes/java/lang/String.java ! test/micro/org/openjdk/bench/java/lang/StringHashCode.java Changeset: 40a7e2fc9beb Author: redestad Date: 2019-04-02 11:37 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/40a7e2fc9beb 8221724: Enable archiving of Strings with hash 0 Reviewed-by: jiangli, iklam ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/oops/constantPool.cpp ! test/hotspot/jtreg/runtime/appcds/sharedStrings/HelloStringPlus.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/LockStringTest.java Changeset: e297c7bb6469 Author: erikj Date: 2017-10-24 10:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/e297c7bb6469 8189861: Refactor CacheFind Reviewed-by: tbell ! make/Bundles.gmk ! make/CompileDemos.gmk ! make/CompileJavaModules.gmk ! make/CopyImportModules.gmk ! make/CreateBuildJdkCopy.gmk ! make/CreateJmods.gmk ! make/Docs.gmk ! make/Images.gmk ! make/MacBundles.gmk ! make/ZipSource.gmk ! make/common/JarArchive.gmk ! make/common/JavaCompilation.gmk ! make/common/MakeBase.gmk ! make/common/NativeCompilation.gmk ! make/common/TestFilesCompilation.gmk ! make/common/TextFileProcessing.gmk ! make/common/Utils.gmk ! make/common/ZipArchive.gmk ! make/copy/CopyCommon.gmk ! make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk ! make/gensrc/Gensrc-jdk.internal.vm.compiler.management.gmk ! make/gensrc/GensrcCommonLangtools.gmk ! make/gensrc/GensrcLocaleData.gmk ! make/gensrc/GensrcProperties.gmk ! make/hotspot/lib/CompileJvm.gmk ! make/hotspot/lib/JvmOverrideFiles.gmk ! make/lib/Lib-java.base.gmk ! make/lib/Lib-java.desktop.gmk ! test/make/TestCopyFiles.gmk ! test/make/TestMakeBase.gmk ! test/make/UtilsForTests.gmk Changeset: c47660e8f5b6 Author: shade Date: 2019-04-02 17:10 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/c47660e8f5b6 8221824: Build failure with MSVS 2013 after JDK-8218418 Reviewed-by: stuefe, alanb ! src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c Changeset: 61616f509ef8 Author: erikj Date: 2019-04-02 08:19 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/61616f509ef8 8221762: Improve Main.gmk/FindTests.gmk bootstrap time Reviewed-by: tbell ! make/InitSupport.gmk ! make/RunTestsPrebuilt.gmk ! make/common/FindTests.gmk Changeset: cdc3bb0983a6 Author: rkennke Date: 2019-04-02 18:13 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/cdc3bb0983a6 8221751: Shenandoah: Improve SATB enqueueing Reviewed-by: shade ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRuntime.cpp Changeset: cd3b7ad53265 Author: kvn Date: 2019-04-02 09:45 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/cd3b7ad53265 8221782: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.jdk.vm.ci.services Reviewed-by: dlong, alanb, mullan ! src/java.base/share/lib/security/default.policy Changeset: 9559ba212c18 Author: kbarrett Date: 2019-04-02 13:08 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/9559ba212c18 8221102: Allow GC threads to participate in threads claiming protocol Summary: Expand claim counter from 1bit to uintx, with rare overflow handling. Reviewed-by: tschatzl, rkennke ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/strongRootsScope.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/z/zRootsIterator.cpp ! src/hotspot/share/runtime/sweeper.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp + test/hotspot/gtest/runtime/test_threads.cpp Changeset: 00fc7ba000b4 Author: iignatyev Date: 2019-04-02 13:39 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/00fc7ba000b4 8221870: use driver to run CtwRunner in applications/ctw tests Reviewed-by: shade, epavlova ! test/hotspot/jtreg/applications/ctw/modules/generate.bash ! test/hotspot/jtreg/applications/ctw/modules/java_base.java ! test/hotspot/jtreg/applications/ctw/modules/java_base_2.java ! test/hotspot/jtreg/applications/ctw/modules/java_compiler.java ! test/hotspot/jtreg/applications/ctw/modules/java_datatransfer.java ! test/hotspot/jtreg/applications/ctw/modules/java_desktop.java ! test/hotspot/jtreg/applications/ctw/modules/java_desktop_2.java ! test/hotspot/jtreg/applications/ctw/modules/java_instrument.java ! test/hotspot/jtreg/applications/ctw/modules/java_logging.java ! test/hotspot/jtreg/applications/ctw/modules/java_management.java ! test/hotspot/jtreg/applications/ctw/modules/java_management_rmi.java ! test/hotspot/jtreg/applications/ctw/modules/java_naming.java + test/hotspot/jtreg/applications/ctw/modules/java_net_http.java ! test/hotspot/jtreg/applications/ctw/modules/java_prefs.java ! test/hotspot/jtreg/applications/ctw/modules/java_rmi.java ! test/hotspot/jtreg/applications/ctw/modules/java_scripting.java ! test/hotspot/jtreg/applications/ctw/modules/java_security_jgss.java ! test/hotspot/jtreg/applications/ctw/modules/java_security_sasl.java ! test/hotspot/jtreg/applications/ctw/modules/java_smartcardio.java ! test/hotspot/jtreg/applications/ctw/modules/java_sql.java ! test/hotspot/jtreg/applications/ctw/modules/java_sql_rowset.java + test/hotspot/jtreg/applications/ctw/modules/java_transaction_xa.java ! test/hotspot/jtreg/applications/ctw/modules/java_xml.java ! test/hotspot/jtreg/applications/ctw/modules/java_xml_crypto.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_accessibility.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_aot.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_attach.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_charsets.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_compiler.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_crypto_cryptoki.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_crypto_ec.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_crypto_mscapi.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_crypto_ucrypto.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_dynalink.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_editpad.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_hotspot_agent.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_httpserver.java - test/hotspot/jtreg/applications/ctw/modules/jdk_incubator_httpclient.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_internal_ed.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_internal_jvmstat.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_internal_le.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_internal_opt.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_internal_vm_ci.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_internal_vm_compiler.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_internal_vm_compiler_management.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_jartool.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_javadoc.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_jcmd.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_jconsole.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_jdeps.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_jdi.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_jfr.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_jlink.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_jshell.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_jsobject.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_jstatd.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_localedata.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_management.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_management_agent.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_management_jfr.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_naming_dns.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_naming_rmi.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_net.java - test/hotspot/jtreg/applications/ctw/modules/jdk_packager.java - test/hotspot/jtreg/applications/ctw/modules/jdk_packager_services.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_rmic.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_scripting_nashorn.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_scripting_nashorn_shell.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_sctp.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_security_auth.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_security_jgss.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_unsupported.java + test/hotspot/jtreg/applications/ctw/modules/jdk_unsupported_desktop.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_xml_dom.java ! test/hotspot/jtreg/applications/ctw/modules/jdk_zipfs.java Changeset: cbde3b803d93 Author: zgu Date: 2019-04-02 16:36 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/cbde3b803d93 8221875: Unquarantine Shenandoah string dedup tests Reviewed-by: rkennke ! test/hotspot/jtreg/ProblemList.txt Changeset: a1acc800c87a Author: zgu Date: 2019-03-14 09:53 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a1acc800c87a 8220602: Shenandoah-SA: Enable best-effort implementation of heap walk Reviewed-by: rkennke, cjplummer ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/vmStructs_shenandoah.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/CollectedHeap.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahBitMap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeapRegion.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java ! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java Changeset: 772f62a13376 Author: lmesnik Date: 2019-04-02 17:11 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/772f62a13376 8221437: assert(java_lang_invoke_ResolvedMethodName::vmtarget(resolved_method()) == m()) failed: Should not change after link resolution Reviewed-by: coleenp, sspitsyn ! src/hotspot/share/prims/methodHandles.cpp Changeset: 3326be37cd9a Author: ronsh Date: 2019-04-02 17:27 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/3326be37cd9a 8220792: Performance bottleneck in JavacFileManager.list() Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/BaseFileManager.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java Changeset: f9feec76a481 Author: amlu Date: 2019-04-03 13:24 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f9feec76a481 8178335: fake pass: jdk/internal/ref/Cleaner/ExitOnThrow.java Reviewed-by: mchung ! test/jdk/jdk/internal/ref/Cleaner/ExitOnThrow.java Changeset: 33ef346b1478 Author: prr Date: 2019-03-21 21:37 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/33ef346b1478 8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 7de72c87766a Author: psadhukhan Date: 2019-03-22 14:39 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/7de72c87766a Merge - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/doc-files/CompilationBailoutActionHelp.txt ! test/jdk/ProblemList.txt Changeset: a26c1f6f9ad5 Author: serb Date: 2019-03-22 12:44 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a26c1f6f9ad5 8177960: Deprecate the Swing Motif Look and Feel and document it as unsupported on macOS Reviewed-by: psadhukhan, prr ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/java.desktop/unix/classes/sun/awt/X11/XAWTLookAndFeel.java Changeset: 24d072f23933 Author: stuefe Date: 2019-03-26 16:53 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/24d072f23933 8221405: Fix Windows 32bit awt build Reviewed-by: clanger, aivanov ! src/java.desktop/share/native/common/awt/debug/debug_trace.c ! src/java.desktop/share/native/common/awt/debug/debug_trace.h Changeset: 6526e0a7dd99 Author: mhalder Date: 2019-03-27 12:24 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/6526e0a7dd99 8216971: [macosx swing] For JCheckBoxMenuItem actionPerformed() is called twice, when apple.laf.useScreenMenuBar=true and modifier is InputEvent.META_DOWN_MASK Reviewed-by: psadhukhan, kaddepalli ! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuItem.m + test/jdk/javax/swing/JMenuItem/8216971/DoubleActionTest.java Changeset: 65030bbf5ac1 Author: psadhukhan Date: 2019-03-27 12:27 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/65030bbf5ac1 8220250: fix headings in java.desktop Reviewed-by: aivanov, jjg, serb ! src/java.desktop/share/classes/java/awt/AlphaComposite.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Font.java ! src/java.desktop/share/classes/java/awt/font/TextAttribute.java ! src/java.desktop/share/classes/java/awt/geom/AffineTransform.java ! src/java.desktop/share/classes/javax/accessibility/package-info.java ! src/java.desktop/share/classes/javax/print/DocFlavor.java ! src/java.desktop/share/classes/javax/print/attribute/package-info.java ! src/java.desktop/share/classes/javax/print/attribute/standard/package-info.java ! src/java.desktop/share/classes/javax/print/package-info.java ! src/java.desktop/share/classes/javax/swing/Action.java ! src/java.desktop/share/classes/javax/swing/GroupLayout.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/javax/swing/SizeSequence.java ! src/java.desktop/share/classes/javax/swing/SpringLayout.java ! src/java.desktop/share/classes/javax/swing/UIManager.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java Changeset: 62171da145f9 Author: psadhukhan Date: 2019-03-28 13:47 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/62171da145f9 8217735: awt_image_GifImageDecoder_parseImage() "interlace" param has the wrong type Reviewed-by: psadhukhan, jdv Contributed-by: andrew_m_leonard at uk.ibm.com ! src/java.desktop/share/native/libawt/awt/image/gif/gifdecoder.c Changeset: b10e1f4f8b69 Author: psadhukhan Date: 2019-03-28 13:49 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b10e1f4f8b69 8221411: NullPointerException in RasterPrinterJob without PrinterResolution Reviewed-by: prr ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java Changeset: 31c35004f300 Author: aivanov Date: 2019-03-28 14:52 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/31c35004f300 8221412: lookupPrintServices() does not always update the list of Windows remote printers Reviewed-by: prr, serb ! src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp Changeset: 3a217bbdd3a2 Author: aivanov Date: 2019-03-28 18:51 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/3a217bbdd3a2 8217707: JNICALL declaration breaks Splash screen functions Reviewed-by: prr, stuefe ! src/java.desktop/share/native/libsplashscreen/splashscreen_impl.c ! src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h ! src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c ! src/java.desktop/windows/native/libsplashscreen/splashscreen_sys.c Changeset: 35975113d5d8 Author: psadhukhan Date: 2019-03-29 10:11 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/35975113d5d8 8212904: JTextArea line wrapping incorrect when using UI scale Reviewed-by: serb, prr ! src/java.desktop/share/classes/javax/swing/text/Utilities.java ! src/java.desktop/share/classes/javax/swing/text/WrappedPlainView.java + test/jdk/javax/swing/JTextArea/JTextAreaWordWrapTest.java Changeset: d5b11b78ed62 Author: dcherepanov Date: 2019-03-27 13:14 +0300 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/d5b11b78ed62 8221244: Unexpected behavior of PropertyDescription.getReadMethod for boolean properties Reviewed-by: serb ! src/java.desktop/share/classes/com/sun/beans/introspect/PropertyInfo.java + test/jdk/java/beans/Introspector/Test8221244.java Changeset: 9727e63dff13 Author: serb Date: 2019-03-29 16:09 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/9727e63dff13 8215105: java/awt/Robot/HiDPIScreenCapture/ScreenCaptureTest.java: Wrong Pixel Color Reviewed-by: prr ! src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m + test/jdk/java/awt/Robot/CheckCommonColors/CheckCommonColors.java Changeset: 93b37d7435e8 Author: serb Date: 2019-03-29 17:46 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/93b37d7435e8 8220320: Remove unused old code in GraphicsEnvironment on unix Reviewed-by: prr ! src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java ! src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c Changeset: 080937e6e85c Author: serb Date: 2019-03-29 23:14 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/080937e6e85c 8221436: Incorrect check of package in Line.Info.toString() Reviewed-by: prr ! src/java.desktop/share/classes/javax/sound/sampled/Line.java + test/jdk/javax/sound/sampled/Lines/ToString.java Changeset: 901ff5aba330 Author: serb Date: 2019-03-31 16:57 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/901ff5aba330 8220495: Update GIFlib library to the 5.1.8 Reviewed-by: prr ! src/java.desktop/share/legal/giflib.md ! src/java.desktop/share/native/libsplashscreen/giflib/dgif_lib.c ! src/java.desktop/share/native/libsplashscreen/giflib/gif_hash.h ! src/java.desktop/share/native/libsplashscreen/giflib/gif_lib.h ! src/java.desktop/share/native/libsplashscreen/giflib/gif_lib_private.h ! src/java.desktop/share/native/libsplashscreen/giflib/gifalloc.c ! src/java.desktop/share/native/libsplashscreen/giflib/openbsd-reallocarray.c Changeset: 8fe16bf92ebd Author: psadhukhan Date: 2019-04-02 10:55 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/8fe16bf92ebd 8221731: Fix doclint handling of accessibility heading in java.desktop Reviewed-by: erikj ! make/CompileJavaModules.gmk Changeset: 94986cf5e969 Author: psadhukhan Date: 2019-04-02 10:57 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/94986cf5e969 Merge ! src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/UnsafeAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/UnsafeAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/UnsafeAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/NodeCostDumpUtil.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/UnsafeAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/UnsafeAccess.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesFrameWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FrameOutputWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleFrameWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageFrameWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java - test/hotspot/jtreg/runtime/containers/docker/Dockerfile-BasicTest - test/hotspot/jtreg/runtime/containers/docker/Dockerfile-BasicTest-aarch64 - test/hotspot/jtreg/runtime/containers/docker/Dockerfile-BasicTest-ppc64le - test/hotspot/jtreg/runtime/containers/docker/Dockerfile-BasicTest-s390x - test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java - test/hotspot/jtreg/runtime/noClassDefFoundMsg/NoClassDefFoundMsg.java - test/hotspot/jtreg/runtime/noClassDefFoundMsg/libNoClassDefFoundMsg.c - test/jdk/jdk/internal/platform/docker/Dockerfile-BasicTest - test/jdk/jdk/internal/platform/docker/Dockerfile-BasicTest-aarch64 - test/jdk/jdk/internal/platform/docker/Dockerfile-BasicTest-ppc64le - test/jdk/jdk/internal/platform/docker/Dockerfile-BasicTest-s390x - test/jdk/sun/security/ssl/rsa/BrokenRSAPrivateCrtKey.java - test/langtools/jdk/javadoc/doclet/AccessFrameTitle/AccessFrameTitle.java - test/langtools/jdk/javadoc/doclet/AccessFrameTitle/p1/C1.java - test/langtools/jdk/javadoc/doclet/AccessFrameTitle/p2/C2.java - test/langtools/jdk/javadoc/doclet/PackagesHeader/PackagesHeader.java - test/langtools/jdk/javadoc/doclet/PackagesHeader/p1/C1.java - test/langtools/jdk/javadoc/doclet/PackagesHeader/p2/C2.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/TestClassDocCatalog.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyAnnotation.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyClass.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyEnum.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyError.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyException.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyInterface.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyAnnotation.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyClass.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyEnum.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyError.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyException.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyInterface.java - test/langtools/jdk/javadoc/doclet/testFramesNoFrames/TestFramesNoFrames.java - test/langtools/jdk/javadoc/doclet/testWindowTitle/TestWindowTitle.java - test/langtools/jdk/javadoc/doclet/testWindowTitle/p1/C1.java - test/langtools/jdk/javadoc/doclet/testWindowTitle/p2/C2.java Changeset: 7feb5e303c83 Author: psadhukhan Date: 2019-04-03 13:30 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/7feb5e303c83 Merge ! make/CompileJavaModules.gmk - test/hotspot/jtreg/applications/ctw/modules/jdk_incubator_httpclient.java - test/hotspot/jtreg/applications/ctw/modules/jdk_packager.java - test/hotspot/jtreg/applications/ctw/modules/jdk_packager_services.java Changeset: 1ad7f5bcc670 Author: lucy Date: 2019-04-03 16:55 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/1ad7f5bcc670 8221482: Initialize VMRegImpl::regName[] earlier to prevent assert during PrintStubCode Reviewed-by: kvn ! src/hotspot/share/runtime/init.cpp Changeset: 41356f083e93 Author: redestad Date: 2019-04-03 17:06 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/41356f083e93 8221701: Archive constant BaseLocales Reviewed-by: naoto ! src/hotspot/share/memory/heapShared.cpp ! src/java.base/share/classes/java/util/Locale.java ! src/java.base/share/classes/sun/util/locale/BaseLocale.java ! src/java.base/share/classes/sun/util/locale/LocaleUtils.java ! src/java.base/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/java.base/share/classes/sun/util/locale/provider/LocaleResources.java Changeset: 30067047ed88 Author: lancea Date: 2019-04-03 11:30 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/30067047ed88 8216539: tools/jar/modularJar/Basic.java times out Reviewed-by: mchung, alanb, bchristi, bpb ! test/jdk/tools/jar/modularJar/Basic.java Changeset: f855ec13aa25 Author: rkennke Date: 2019-03-27 22:25 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f855ec13aa25 8220664: Simplify ShenandoahUpdateHeapRefsClosure Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.inline.hpp Changeset: 40b0400fc019 Author: rkennke Date: 2019-04-04 13:58 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/40b0400fc019 Merge ! .hgtags ! make/hotspot/lib/JvmOverrideFiles.gmk ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/share/classfile/classLoaderData.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/g1/g1BarrierSet.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/shared/barrierSet.hpp ! src/hotspot/share/gc/shared/collectedHeap.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shared/satbMarkQueue.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRuntime.cpp ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.cpp ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp ! src/hotspot/share/gc/shenandoah/vmStructs_shenandoah.hpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.hpp ! src/hotspot/share/gc/z/zForwarding.cpp ! src/hotspot/share/gc/z/zForwarding.inline.hpp ! src/hotspot/share/gc/z/zForwardingEntry.hpp ! src/hotspot/share/oops/oop.cpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/machnode.cpp ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/hotspot/share/opto/multnode.cpp ! src/hotspot/share/opto/node.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/subnode.cpp ! src/hotspot/share/opto/subnode.hpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/CollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeapRegion.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/UnsafeAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/UnsafeAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/UnsafeAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/NodeCostDumpUtil.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/UnsafeAccess.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.word/src/org/graalvm/compiler/word/UnsafeAccess.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesFrameWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FrameOutputWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleFrameWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexFrameWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModulePackageIndexFrameWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageFrameWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexFrameWriter.java ! test/hotspot/gtest/gc/z/test_zForwarding.cpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/applications/ctw/modules/jdk_incubator_httpclient.java - test/hotspot/jtreg/applications/ctw/modules/jdk_packager.java - test/hotspot/jtreg/applications/ctw/modules/jdk_packager_services.java - test/hotspot/jtreg/runtime/noClassDefFoundMsg/NoClassDefFoundMsg.java - test/hotspot/jtreg/runtime/noClassDefFoundMsg/libNoClassDefFoundMsg.c ! test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java ! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/em04t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002/em07t002.cpp - test/jdk/sun/security/ssl/rsa/BrokenRSAPrivateCrtKey.java - test/langtools/jdk/javadoc/doclet/AccessFrameTitle/AccessFrameTitle.java - test/langtools/jdk/javadoc/doclet/AccessFrameTitle/p1/C1.java - test/langtools/jdk/javadoc/doclet/AccessFrameTitle/p2/C2.java - test/langtools/jdk/javadoc/doclet/PackagesHeader/PackagesHeader.java - test/langtools/jdk/javadoc/doclet/PackagesHeader/p1/C1.java - test/langtools/jdk/javadoc/doclet/PackagesHeader/p2/C2.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/TestClassDocCatalog.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyAnnotation.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyClass.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyEnum.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyError.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyException.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg1/EmptyInterface.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyAnnotation.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyClass.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyEnum.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyError.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyException.java - test/langtools/jdk/javadoc/doclet/testClassDocCatalog/pkg2/EmptyInterface.java - test/langtools/jdk/javadoc/doclet/testFramesNoFrames/TestFramesNoFrames.java - test/langtools/jdk/javadoc/doclet/testWindowTitle/TestWindowTitle.java - test/langtools/jdk/javadoc/doclet/testWindowTitle/p1/C1.java - test/langtools/jdk/javadoc/doclet/testWindowTitle/p2/C2.java From simone.bordet at gmail.com Thu Apr 4 19:12:34 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 4 Apr 2019 21:12:34 +0200 Subject: Read during Evacuation Message-ID: Hi, while studying a bit Shenandoah, I would like to ask your help about how reads are handled in case of a concurrent evacuation, the following case: * Mutator1 reads the fwd_ptr of an object, points to self. * Mutator2 wants to write to the same object, but GC is in the evacuation phase. * Mutator2 evacuates the object, CASes the fwd_ptr, updates the field it wants to write and let's assume that this is a volatile write. * Mutator1 resumes and follows the old fwd_ptr, and reads a stale value. How can Mutator1 know that the object has been evacuated _and_ changed? Is Mutator1 triggering a barrier that performs the evacuation even during reads because the GC is in the evacuation phase? Pointers to code to study? Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From zgu at redhat.com Thu Apr 4 19:14:11 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 4 Apr 2019 15:14:11 -0400 Subject: RFR: JDK-8221848: Shenandoah: ArrayCopy post-barrier improvements In-Reply-To: References: Message-ID: <22dfbd21-c09f-a140-53c7-b7de2c9e109e@redhat.com> Looks good. -Zhengyu On 4/3/19 12:41 PM, Roman Kennke wrote: > Just like the arraycopy pre-barrier, the arraycopy post-barrier should > check for count == 0 and UPDATEREFS gc-state in the generated stubs to > avoid calling into the runtime at all in those cases. The runtime can > then elide checking this. > > Why is this relevant? Because calling into runtime involves storing and > restoring *all registers* around the call. That would be 32 (x86) or 64 > (aarch64) memory accesses to do nothing at all (outside > update-refs-phase or when dealing with empty arraycopy). > > This change proposes to slightly change the meaning of the UPDATEREFS > state: so far it would only be active during the dedicated update-refs > phase after evacuation. Updating-references while marking would not have > this flag. However, arraycopy is the only place where we use this flag > at all, and we use it to determine if current GC phase is actually > updating references. I suggest to also activate it during marking (when > updating references) and traversal (always also updating references). > Then we can make the check in assembly very simple. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221848 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8221848/webrev.00/ > > Testing: hotspot_gc_shenandoah (x86_64 and aarch64) > > Ok? > > Roman From rkennke at redhat.com Thu Apr 4 19:17:43 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 4 Apr 2019 21:17:43 +0200 Subject: Read during Evacuation In-Reply-To: References: Message-ID: > while studying a bit Shenandoah, I would like to ask your help about > how reads are handled in case of a concurrent evacuation, the > following case: > > * Mutator1 reads the fwd_ptr of an object, points to self. > * Mutator2 wants to write to the same object, but GC is in the evacuation phase. > * Mutator2 evacuates the object, CASes the fwd_ptr, updates the field > it wants to write and let's assume that this is a volatile write. > * Mutator1 resumes and follows the old fwd_ptr, and reads a stale value. > > How can Mutator1 know that the object has been evacuated _and_ changed? This is a race, with or without Shenandoah. Shenandoah cannot fix that race. Write down the same sequence of events without Shenandoah. Mutator1 would still read a stale value (e.g. from its CPU cache). Roman From simone.bordet at gmail.com Thu Apr 4 19:38:05 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 4 Apr 2019 21:38:05 +0200 Subject: Read during Evacuation In-Reply-To: References: Message-ID: Hi, On Thu, Apr 4, 2019 at 9:17 PM Roman Kennke wrote: > > > while studying a bit Shenandoah, I would like to ask your help about > > how reads are handled in case of a concurrent evacuation, the > > following case: > > > > * Mutator1 reads the fwd_ptr of an object, points to self. > > * Mutator2 wants to write to the same object, but GC is in the evacuation phase. > > * Mutator2 evacuates the object, CASes the fwd_ptr, updates the field > > it wants to write and let's assume that this is a volatile write. > > * Mutator1 resumes and follows the old fwd_ptr, and reads a stale value. > > > > How can Mutator1 know that the object has been evacuated _and_ changed? > > This is a race, with or without Shenandoah. Shenandoah cannot fix that race. What if Mutator2 is instead a GC thread? Wouldn't a read barrier that performs the evacuation solve the issue? The read would be guaranteed to happen in the to-space object and the loser thread would discard its copy. I am sure I am missing something here :) Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From rkennke at redhat.com Thu Apr 4 19:43:03 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 4 Apr 2019 21:43:03 +0200 Subject: Read during Evacuation In-Reply-To: References: Message-ID: <9ed2e4c2-1244-6310-d710-69150bd69ba1@redhat.com> >>> while studying a bit Shenandoah, I would like to ask your help about >>> how reads are handled in case of a concurrent evacuation, the >>> following case: >>> >>> * Mutator1 reads the fwd_ptr of an object, points to self. >>> * Mutator2 wants to write to the same object, but GC is in the evacuation phase. >>> * Mutator2 evacuates the object, CASes the fwd_ptr, updates the field >>> it wants to write and let's assume that this is a volatile write. >>> * Mutator1 resumes and follows the old fwd_ptr, and reads a stale value. >>> >>> How can Mutator1 know that the object has been evacuated _and_ changed? >> >> This is a race, with or without Shenandoah. Shenandoah cannot fix that race. > > What if Mutator2 is instead a GC thread? A GC thread wouldn't mess with any data that Mutator 1 is trying to read. > Wouldn't a read barrier that performs the evacuation solve the issue? > The read would be guaranteed to happen in the to-space object and the > loser thread would discard its copy. > > I am sure I am missing something here :) In the absence of synchronization, there is still no guarantee what Mutator1 would read. Mutator 2 might update the field, but Mutator 1 might read his cached copy. Roman From simone.bordet at gmail.com Thu Apr 4 20:11:49 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Thu, 4 Apr 2019 22:11:49 +0200 Subject: Read during Evacuation In-Reply-To: <9ed2e4c2-1244-6310-d710-69150bd69ba1@redhat.com> References: <9ed2e4c2-1244-6310-d710-69150bd69ba1@redhat.com> Message-ID: Hi, On Thu, Apr 4, 2019 at 9:43 PM Roman Kennke wrote: > A GC thread wouldn't mess with any data that Mutator 1 is trying to read. Right. > In the absence of synchronization, there is still no guarantee what > Mutator1 would read. Mutator 2 might update the field, but Mutator 1 > might read his cached copy. Got it. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From aph at redhat.com Fri Apr 5 12:37:38 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Apr 2019 13:37:38 +0100 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <7284c04d-cb6c-8125-4966-d136fe151074@redhat.com> References: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> <7284c04d-cb6c-8125-4966-d136fe151074@redhat.com> Message-ID: <68757927-ca40-db91-561b-71ff065bc44c@redhat.com> On 4/4/19 10:51 AM, Roman Kennke wrote: > Does all that answer your question? :-) Sure. One thing that always bothered me about the write barrier was that it looked fantastically expensive: all of the CPU state was pushed, and there is a lot of CPU state on AArch64. I never did understand why we can't have a fast path for that. -- 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 Fri Apr 5 12:50:09 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 5 Apr 2019 14:50:09 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <68757927-ca40-db91-561b-71ff065bc44c@redhat.com> References: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> <7284c04d-cb6c-8125-4966-d136fe151074@redhat.com> <68757927-ca40-db91-561b-71ff065bc44c@redhat.com> Message-ID: <94bc3f91-8984-debc-6804-1abb2e90a763@redhat.com> >> Does all that answer your question? :-) > > Sure. One thing that always bothered me about the write barrier was that > it looked fantastically expensive: all of the CPU state was pushed, and > there is a lot of CPU state on AArch64. I never did understand why we can't > have a fast path for that. The write-barrier/LRB slowpath is not actually very hot, and with LRB it is even less hot. We did have a fast-path for that, you actually wrote it yourself, but it didn't make much difference (or any difference at all) in overall throughput. We ditched it when we introduced our 'safety net' mechanism to deal with OOM during evacuation, which would have required to slap even more stuff into that 'fastpath'. It didn't seem useful, and it only added to maintenance... Roman From aph at redhat.com Fri Apr 5 16:17:09 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Apr 2019 17:17:09 +0100 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <94bc3f91-8984-debc-6804-1abb2e90a763@redhat.com> References: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> <7284c04d-cb6c-8125-4966-d136fe151074@redhat.com> <68757927-ca40-db91-561b-71ff065bc44c@redhat.com> <94bc3f91-8984-debc-6804-1abb2e90a763@redhat.com> Message-ID: <52f37068-e906-d235-9529-3a99dc0d7277@redhat.com> On 4/5/19 1:50 PM, Roman Kennke wrote: >>> Does all that answer your question? :-) >> >> Sure. One thing that always bothered me about the write barrier was that >> it looked fantastically expensive: all of the CPU state was pushed, and >> there is a lot of CPU state on AArch64. I never did understand why we can't >> have a fast path for that. > > The write-barrier/LRB slowpath is not actually very hot, and with LRB it > is even less hot. We did have a fast-path for that, you actually wrote > it yourself, but it didn't make much difference (or any difference at > all) in overall throughput. Yeah, I remember. I just wish I understood why the write barrier is so cold. I mean, you're racing with the GC threads, right? So if we load a stale pointer we have to promote the object ... and apparently that is extremely rare. Is that true even at times of heavy load? I don't get it. -- 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 Fri Apr 5 16:21:54 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 05 Apr 2019 18:21:54 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <52f37068-e906-d235-9529-3a99dc0d7277@redhat.com> References: <77b4bb32-229f-b517-9edc-07e82c40c1f4@redhat.com> <7284c04d-cb6c-8125-4966-d136fe151074@redhat.com> <68757927-ca40-db91-561b-71ff065bc44c@redhat.com> <94bc3f91-8984-debc-6804-1abb2e90a763@redhat.com> <52f37068-e906-d235-9529-3a99dc0d7277@redhat.com> Message-ID: Am 5. April 2019 18:17:09 MESZ schrieb Andrew Haley : >On 4/5/19 1:50 PM, Roman Kennke wrote: >>>> Does all that answer your question? :-) >>> >>> Sure. One thing that always bothered me about the write barrier was >that >>> it looked fantastically expensive: all of the CPU state was pushed, >and >>> there is a lot of CPU state on AArch64. I never did understand why >we can't >>> have a fast path for that. >> >> The write-barrier/LRB slowpath is not actually very hot, and with LRB >it >> is even less hot. We did have a fast-path for that, you actually >wrote >> it yourself, but it didn't make much difference (or any difference at > >> all) in overall throughput. > >Yeah, I remember. I just wish I understood why the write barrier is so >cold. I mean, you're racing with the GC threads, right? So if we load >a stale pointer we have to promote the object ... and apparently that >is extremely rare. Is that true even at times of heavy load? I don't >get it. We only have to enter the slowpath if: - obj is != NULL - evacuation is in progress - obj is in cset (smallish subset of all regions) - obj is not evacuated already We check all this in the fast-/mid-path before diving into runtime for the slowpath. Also, if obj is already evacuated, we resolve it in the midpath and are done. Roman -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From aph at redhat.com Sun Apr 7 10:25:23 2019 From: aph at redhat.com (Andrew Haley) Date: Sun, 7 Apr 2019 11:25:23 +0100 Subject: RFR: JDK-8221848: Shenandoah: ArrayCopy post-barrier improvements In-Reply-To: References: Message-ID: On 4/3/19 5:41 PM, Roman Kennke wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8221848 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8221848/webrev.00/ > > Testing: hotspot_gc_shenandoah (x86_64 and aarch64) OK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From simone.bordet at gmail.com Sun Apr 7 12:41:28 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Sun, 7 Apr 2019 14:41:28 +0200 Subject: Troubles with Shenandoah Message-ID: Hi, using 12-testing+0-builds.shipilev.net-openjdk-jdk12-b157-20190406-jdk-1233jdk-12-ga. I'm running the CometD benchmark (https://docs.cometd.org/current/reference/#_benchmarking), which is basically a messaging web application running in Jetty. Running the benchmark with Shenandoah, I don't have crashes or exceptions on the server, but many messages are not relayed back to the clients. I suspect there is something wrong with Shenandoah because the benchmark succeeds with G1 and ZGC on 20+ minutes runs, but fails with Shenandoah with just 1 minute runs - the only change is the GC I'm using. I have 2 questions: A) is the version I'm using a "stable" enough version (it's this one: https://builds.shipilev.net/openjdk-jdk12/openjdk-jdk12-latest-linux-x86_64-release.tar.xz) B) is there any command line option that I can set to make Shenandoah verify that it's doing the job correctly? Or maybe use some debug version of Shenandoah that could help identify if there is an issue? I will happily re-run the benchmark with your suggestions. Thanks! ---- -XX:InitialHeapSize=17179869184 -XX:MaxHeapSize=51539607552 -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC [2019-04-07T06:45:36.007-0500][info][gc] Consider -XX:+ClassUnloadingWithConcurrentMark if large pause times are observed on class-unloading sensitive workloads [2019-04-07T06:45:36.010-0500][info][gc,init] Regions: 3072 x 16384K [2019-04-07T06:45:36.010-0500][info][gc,init] Humongous object threshold: 16384K [2019-04-07T06:45:36.010-0500][info][gc,init] Max TLAB size: 16384K [2019-04-07T06:45:36.010-0500][info][gc,init] GC threads: 23 parallel, 23 concurrent [2019-04-07T06:45:36.010-0500][info][gc,init] Reference processing: parallel [2019-04-07T06:45:36.010-0500][info][gc ] Heuristics ergonomically sets -XX:+ExplicitGCInvokesConcurrent [2019-04-07T06:45:36.010-0500][info][gc ] Heuristics ergonomically sets -XX:+ShenandoahImplicitGCInvokesConcurrent [2019-04-07T06:45:36.010-0500][info][gc,init] Shenandoah heuristics: adaptive [2019-04-07T06:45:36.012-0500][info][gc,ergo] Pacer for Idle. Initial: 983M, Alloc Tax Rate: 1.0x [2019-04-07T06:45:36.012-0500][info][gc,init] Initialize Shenandoah heap with initial size 16384M [2019-04-07T06:45:36.012-0500][info][gc,init] Safepointing mechanism: global-page poll [2019-04-07T06:45:36.012-0500][info][gc ] Using Shenandoah -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From shade at redhat.com Sun Apr 7 12:50:03 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 7 Apr 2019 14:50:03 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: Message-ID: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> On 4/7/19 2:41 PM, Simone Bordet wrote: > I have 2 questions: > > A) is the version I'm using a "stable" enough version (it's this one: > https://builds.shipilev.net/openjdk-jdk12/openjdk-jdk12-latest-linux-x86_64-release.tar.xz) That is basically 12u bleeding edge for testing, and it might be broken. The releases that ship by major vendors are usually much more stable. > B) is there any command line option that I can set to make Shenandoah > verify that it's doing the job correctly? Or maybe use some debug > version of Shenandoah that could help identify if there is an issue? Checklist is here: https://wiki.openjdk.java.net/display/Shenandoah#Main-FunctionalDiagnostics -Aleksey From simone.bordet at gmail.com Sun Apr 7 13:04:28 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Sun, 7 Apr 2019 15:04:28 +0200 Subject: Troubles with Shenandoah In-Reply-To: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> Message-ID: Hi, On Sun, Apr 7, 2019 at 2:50 PM Aleksey Shipilev wrote: > > On 4/7/19 2:41 PM, Simone Bordet wrote: > > I have 2 questions: > > > > A) is the version I'm using a "stable" enough version (it's this one: > > https://builds.shipilev.net/openjdk-jdk12/openjdk-jdk12-latest-linux-x86_64-release.tar.xz) > > That is basically 12u bleeding edge for testing, and it might be broken. The releases that ship by > major vendors are usually much more stable. This is a point I'm struggling with. Oracle does not ship 12 with Shenandoah. At redhat.com there is no link for downloading a Linux JDK with Shenandoah, only Windows (https://developers.redhat.com/products/openjdk/download/). Cannot find it at AdoptOpenJDK.com. Thanks to you there is https://builds.shipilev.net/, or otherwise I would need to build it myself (no big deal to build it - I've done it in the recent past, but I find it so strange that there are no binaries under a big, easy-to-find, link). Do you have pointers for a non-RedHat Linux 12-with-Shenandoah binaries? > > B) is there any command line option that I can set to make Shenandoah > > verify that it's doing the job correctly? Or maybe use some debug > > version of Shenandoah that could help identify if there is an issue? > > Checklist is here: > https://wiki.openjdk.java.net/display/Shenandoah#Main-FunctionalDiagnostics Will do, thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From rkennke at redhat.com Sun Apr 7 13:24:29 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 07 Apr 2019 15:24:29 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> Message-ID: <137995b320eb70e509056d87b8ca56006c1594b2.camel@redhat.com> > I have 2 questions: > > > > > > A) is the version I'm using a "stable" enough version (it's this > > > one: > > > https://builds.shipilev.net/openjdk-jdk12/openjdk-jdk12-latest-linux-x86_64-release.tar.xz) > > > > That is basically 12u bleeding edge for testing, and it might be > > broken. The releases that ship by > > major vendors are usually much more stable. > > This is a point I'm struggling with. > Oracle does not ship 12 with Shenandoah. > At redhat.com there is no link for downloading a Linux JDK with > Shenandoah, only Windows > (https://developers.redhat.com/products/openjdk/download/). > Cannot find it at AdoptOpenJDK.com. > Thanks to you there is https://builds.shipilev.net/, or otherwise I > would need to build it myself (no big deal to build it - I've done it > in the recent past, but I find it so strange that there are no > binaries under a big, easy-to-find, link). > Do you have pointers for a non-RedHat Linux 12-with-Shenandoah > binaries? I haven't checked, but I was under the assumption that AdoptOpenJDK binaries have Shenandoah enabled. Isn't that the case? I.e. this guy: https://github.com/AdoptOpenJDK/openjdk12-binaries/releases/download/jdk-12%2B33/OpenJDK12U-jdk_x64_linux_hotspot_12_33.tar.gz ? > > > B) is there any command line option that I can set to make > > > Shenandoah > > > verify that it's doing the job correctly? Or maybe use some debug > > > version of Shenandoah that could help identify if there is an > > > issue? > > > > Checklist is here: > > > > https://wiki.openjdk.java.net/display/Shenandoah#Main-FunctionalDiagnostics > > Will do, thanks! I will also investigate as soon as I get to it. Thanks for reporting the issue. Roman From rkennke at redhat.com Sun Apr 7 13:28:58 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 07 Apr 2019 15:28:58 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> Message-ID: Yeah, the AdoptOpenJDK binary has it: /jdk-12+33/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -version openjdk version "12" 2019-03-19 OpenJDK Runtime Environment AdoptOpenJDK (build 12+33) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 12+33, mixed mode, sharing) Roman > Hi, > > On Sun, Apr 7, 2019 at 2:50 PM Aleksey Shipilev > wrote: > > On 4/7/19 2:41 PM, Simone Bordet wrote: > > > I have 2 questions: > > > > > > A) is the version I'm using a "stable" enough version (it's this > > > one: > > > https://builds.shipilev.net/openjdk-jdk12/openjdk-jdk12-latest-linux-x86_64-release.tar.xz) > > > > That is basically 12u bleeding edge for testing, and it might be > > broken. The releases that ship by > > major vendors are usually much more stable. > > This is a point I'm struggling with. > Oracle does not ship 12 with Shenandoah. > At redhat.com there is no link for downloading a Linux JDK with > Shenandoah, only Windows > (https://developers.redhat.com/products/openjdk/download/). > Cannot find it at AdoptOpenJDK.com. > Thanks to you there is https://builds.shipilev.net/, or otherwise I > would need to build it myself (no big deal to build it - I've done it > in the recent past, but I find it so strange that there are no > binaries under a big, easy-to-find, link). > Do you have pointers for a non-RedHat Linux 12-with-Shenandoah > binaries? > > > > B) is there any command line option that I can set to make > > > Shenandoah > > > verify that it's doing the job correctly? Or maybe use some debug > > > version of Shenandoah that could help identify if there is an > > > issue? > > > > Checklist is here: > > > > https://wiki.openjdk.java.net/display/Shenandoah#Main-FunctionalDiagnostics > > Will do, thanks! > From rkennke at redhat.com Sun Apr 7 14:04:36 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 07 Apr 2019 16:04:36 +0200 Subject: Heads-Up: -XX:+ClassUnloadingWithConcurrentMark currently broken Message-ID: <3f0f96f6a546bc7f37998f32f3a7780a0fe93fb7.camel@redhat.com> Just tried to run SPECjbb2015 with the flag, and it crashed within first few minutes in C2-compiled code. I suspect it may be related to recent roots scanning cleanups, and we're probably missing to mark some constants. Will investigate. Roman From simone.bordet at gmail.com Sun Apr 7 14:16:34 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Sun, 7 Apr 2019 16:16:34 +0200 Subject: Troubles with Shenandoah In-Reply-To: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> Message-ID: Hi, On Sun, Apr 7, 2019 at 2:50 PM Aleksey Shipilev wrote: > > On 4/7/19 2:41 PM, Simone Bordet wrote: > > I have 2 questions: > > > > A) is the version I'm using a "stable" enough version (it's this one: > > https://builds.shipilev.net/openjdk-jdk12/openjdk-jdk12-latest-linux-x86_64-release.tar.xz) > > That is basically 12u bleeding edge for testing, and it might be broken. The releases that ship by > major vendors are usually much more stable. Found at AdoptOpenJDK the stable one, but the problem still occurs. I have added -XX:+ShenandoahVerify, I see no crashes and typical output is: [2019-04-07T09:13:01.120-0500][info][gc,start ] GC(15) Verify After Updating References, Level 4 [2019-04-07T09:13:01.257-0500][info][gc ] GC(15) Verify After Updating References, Level 4 (6178264 reachable, 192 marked) Not sure if it's correct. Trying now with -XX:ShenandoahGCHeuristics=passive. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From rkennke at redhat.com Sun Apr 7 14:46:31 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 07 Apr 2019 16:46:31 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> Message-ID: I am trying with the development version of Shenandoah in jdk/jdk. Even with other GCs, I don't even get it to prompt for parameters as described in the docs. It seems to start up and then hang or wait for something. I used the latest cometd download. Roman Hi, > > On Sun, Apr 7, 2019 at 2:50 PM Aleksey Shipilev > wrote: > > On 4/7/19 2:41 PM, Simone Bordet wrote: > > > I have 2 questions: > > > > > > A) is the version I'm using a "stable" enough version (it's this > > > one: > > > https://builds.shipilev.net/openjdk-jdk12/openjdk-jdk12-latest-linux-x86_64-release.tar.xz) > > > > That is basically 12u bleeding edge for testing, and it might be > > broken. The releases that ship by > > major vendors are usually much more stable. > > Found at AdoptOpenJDK the stable one, but the problem still occurs. > I have added -XX:+ShenandoahVerify, I see no crashes and typical > output is: > > [2019-04-07T09:13:01.120-0500][info][gc,start ] GC(15) Verify > After Updating References, Level 4 > [2019-04-07T09:13:01.257-0500][info][gc ] GC(15) Verify > After Updating References, Level 4 (6178264 reachable, 192 marked) > > Not sure if it's correct. > > Trying now with -XX:ShenandoahGCHeuristics=passive. > From rkennke at redhat.com Sun Apr 7 14:54:56 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 07 Apr 2019 16:54:56 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> Message-ID: <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> Oh apparently it has trobles to print anything to the terminal. I can get it to start by blindly pressing enter a few times ;-) Duh. Roman I am getting an exception like this on the server side, do you also see it? https://paste.fedoraproject.org/paste/uTRDekos5uPbU7bojMK45g Roman > Am Sonntag, den 07.04.2019, 16:46 +0200 schrieb Roman Kennke: > I am trying with the development version of Shenandoah in jdk/jdk. > Even > with other GCs, I don't even get it to prompt for parameters as > described in the docs. It seems to start up and then hang or wait for > something. I used the latest cometd download. > > Roman > > Hi, > > On Sun, Apr 7, 2019 at 2:50 PM Aleksey Shipilev > > wrote: > > > On 4/7/19 2:41 PM, Simone Bordet wrote: > > > > I have 2 questions: > > > > > > > > A) is the version I'm using a "stable" enough version (it's > > > > this > > > > one: > > > > https://builds.shipilev.net/openjdk-jdk12/openjdk-jdk12-latest-linux-x86_64-release.tar.xz) > > > > > > That is basically 12u bleeding edge for testing, and it might be > > > broken. The releases that ship by > > > major vendors are usually much more stable. > > > > Found at AdoptOpenJDK the stable one, but the problem still occurs. > > I have added -XX:+ShenandoahVerify, I see no crashes and typical > > output is: > > > > [2019-04-07T09:13:01.120-0500][info][gc,start ] GC(15) Verify > > After Updating References, Level 4 > > [2019-04-07T09:13:01.257-0500][info][gc ] GC(15) Verify > > After Updating References, Level 4 (6178264 reachable, 192 marked) > > > > Not sure if it's correct. > > > > Trying now with -XX:ShenandoahGCHeuristics=passive. > > From simone.bordet at gmail.com Sun Apr 7 15:19:48 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Sun, 7 Apr 2019 17:19:48 +0200 Subject: Troubles with Shenandoah In-Reply-To: <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> Message-ID: Hi, On Sun, Apr 7, 2019 at 4:54 PM Roman Kennke wrote: > > Oh apparently it has trobles to print anything to the terminal. I can > get it to start by blindly pressing enter a few times ;-) Duh. This is an issue in a library used by Maven Go to $MAVEN/lib/ and delete or rename jansi-.jar to jansi-.jar.dontuse > I am getting an exception like this on the server side, do you also see > it? > > https://paste.fedoraproject.org/paste/uTRDekos5uPbU7bojMK45g Ah yes, this is due to the fact that the monitoring we use was not aware of the JMX names of Shenandoah. You will have a better luck using the latest code: $ git clone https://github.com/cometd/cometd.git $ cd cometd $ mvn clean install -DskipTests You're good to go. I can setup a Google Meet/Hangout if you want. I'm running now with heuristics=passive, and the problem seems gone. I'll post when the run is finished, in about 15-20 minutes. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From simone.bordet at gmail.com Sun Apr 7 15:56:42 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Sun, 7 Apr 2019 17:56:42 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> Message-ID: Hi, On Sun, Apr 7, 2019 at 5:19 PM Simone Bordet wrote: > I'm running now with heuristics=passive, and the problem seems gone. > I'll post when the run is finished, in about 15-20 minutes. heuristics=passive completed a 20+ minutes run successfully. Can I help in some other way? -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From rkennke at redhat.com Sun Apr 7 16:16:01 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 07 Apr 2019 18:16:01 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> Message-ID: On Sun, Apr 7, 2019 at 5:19 PM Simone Bordet > wrote: > > I'm running now with heuristics=passive, and the problem seems > > gone. > > I'll post when the run is finished, in about 15-20 minutes. > > heuristics=passive completed a 20+ minutes run successfully. passive in server or client? > Can I help in some other way? Have you tried running with fastdebug build already? Thanks, Roman From simone.bordet at gmail.com Sun Apr 7 16:29:31 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Sun, 7 Apr 2019 18:29:31 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> Message-ID: Hi, On Sun, Apr 7, 2019 at 6:16 PM Roman Kennke wrote: > > On Sun, Apr 7, 2019 at 5:19 PM Simone Bordet > > wrote: > > > I'm running now with heuristics=passive, and the problem seems > > > gone. > > > I'll post when the run is finished, in about 15-20 minutes. > > > > heuristics=passive completed a 20+ minutes run successfully. > > passive in server or client? Passive on server, clients are not on Shenandoah. Are you trying to replicate? Did you replicate? > > Can I help in some other way? > > Have you tried running with fastdebug build already? Nope. I'm building it from 12+33. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From aph at redhat.com Sun Apr 7 16:47:14 2019 From: aph at redhat.com (Andrew Haley) Date: Sun, 7 Apr 2019 17:47:14 +0100 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: Message-ID: <071b38ba-344c-f1a7-a03d-0d9ef44aaa21@redhat.com> On 4/2/19 10:12 PM, Roman Kennke wrote: > - No more need for object equals barriers. I'm pleased about that. I really hated the AArch64 Shenandoah CAS! -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Sun Apr 7 16:54:48 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 07 Apr 2019 18:54:48 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> Message-ID: I believe builds.Shipilev.net also has fastdebug builds. Also, any idea what it gets stuck on? Roman Am 7. April 2019 18:29:31 MESZ schrieb Simone Bordet : >Hi, > >On Sun, Apr 7, 2019 at 6:16 PM Roman Kennke wrote: >> >> On Sun, Apr 7, 2019 at 5:19 PM Simone Bordet > > > wrote: >> > > I'm running now with heuristics=passive, and the problem seems >> > > gone. >> > > I'll post when the run is finished, in about 15-20 minutes. >> > >> > heuristics=passive completed a 20+ minutes run successfully. >> >> passive in server or client? > >Passive on server, clients are not on Shenandoah. > >Are you trying to replicate? Did you replicate? > >> > Can I help in some other way? >> >> Have you tried running with fastdebug build already? > >Nope. I'm building it from 12+33. > >Thanks! > >-- >Simone Bordet >--- >Finally, no matter how good the architecture and design are, >to deliver bug-free software with optimal performance and reliability, >the implementation technique must be flawless. Victoria Livschitz -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From simone.bordet at gmail.com Sun Apr 7 17:52:34 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Sun, 7 Apr 2019 19:52:34 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> Message-ID: Hi, On Sun, Apr 7, 2019 at 6:54 PM Roman Kennke wrote: > > I believe builds.Shipilev.net also has fastdebug builds. > > Also, any idea what it gets stuck on? No. The web application is a chat application: it receives 1 message via HTTP request and sends that message to other 10 clients. Lots of short lives objects (HTTP request/response, gazillions of strings for headers/fields and such, messages converted to/from JSON, etc.). There are long-lived objects such as the client sessions on server-side and they have a queue of messages (also long-lived). No application exceptions and no crashes, and works with heuristics=passive, I frankly don't know what to think. Perhaps the server-side queues lose messages, and that's why the clients report that? Will try the fastdebug build and report back. Is there anything special I need to set for the fastdebug run? Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From rkennke at redhat.com Sun Apr 7 18:16:48 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 07 Apr 2019 20:16:48 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> Message-ID: > Also, any idea what it gets stuck on? > > No. > > The web application is a chat application: it receives 1 message via > HTTP request and sends that message to other 10 clients. > Lots of short lives objects (HTTP request/response, gazillions of > strings for headers/fields and such, messages converted to/from JSON, > etc.). > There are long-lived objects such as the client sessions on > server-side and they have a queue of messages (also long-lived). > No application exceptions and no crashes, and works with > heuristics=passive, I frankly don't know what to think. > Perhaps the server-side queues lose messages, and that's why the > clients report that? > > Will try the fastdebug build and report back. > Is there anything special I need to set for the fastdebug run? > No, run as normal. It will be slower, but may throw interesting asserts. Also, might be worth running with latest jdk13 build: https://builds.shipilev.net/openjdk-jdk/ We have completely rewired the barriers, and this may behave differently. Thanks, Roman From rkennke at redhat.com Sun Apr 7 18:18:03 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 07 Apr 2019 20:18:03 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <071b38ba-344c-f1a7-a03d-0d9ef44aaa21@redhat.com> References: <071b38ba-344c-f1a7-a03d-0d9ef44aaa21@redhat.com> Message-ID: On 4/2/19 10:12 PM, Roman Kennke wrote: > > - No more need for object equals barriers. > > I'm pleased about that. I really hated the AArch64 Shenandoah CAS! I'm sorry to disappoint you, but the CAS barrier is still needed. The memory location may still legally hold a from-space reference, and comparing that to a to-space reference needs some special care. And yes, ZGC has a similar problem as far as I know. Roman From rkennke at redhat.com Sun Apr 7 19:45:10 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 07 Apr 2019 21:45:10 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> Message-ID: <810129fe569106b90f68d12eaffdc4804409bcd6.camel@redhat.com> Actually, I am not quite clear what is the success scenario or the failure scenario. Can you describe a little more detail what I should watch out for for both cases? To me it behaves all ~the same (maybe that means I failed to reproduce so far) Roman > Hi, > > On Sun, Apr 7, 2019 at 6:54 PM Roman Kennke > wrote: > > I believe builds.Shipilev.net also has fastdebug builds. > > > > Also, any idea what it gets stuck on? > > No. > > The web application is a chat application: it receives 1 message via > HTTP request and sends that message to other 10 clients. > Lots of short lives objects (HTTP request/response, gazillions of > strings for headers/fields and such, messages converted to/from JSON, > etc.). > There are long-lived objects such as the client sessions on > server-side and they have a queue of messages (also long-lived). > No application exceptions and no crashes, and works with > heuristics=passive, I frankly don't know what to think. > Perhaps the server-side queues lose messages, and that's why the > clients report that? > > Will try the fastdebug build and report back. > Is there anything special I need to set for the fastdebug run? > > Thanks! > From simone.bordet at gmail.com Sun Apr 7 20:41:46 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Sun, 7 Apr 2019 22:41:46 +0200 Subject: Troubles with Shenandoah In-Reply-To: <810129fe569106b90f68d12eaffdc4804409bcd6.camel@redhat.com> References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <810129fe569106b90f68d12eaffdc4804409bcd6.camel@redhat.com> Message-ID: Hi, On Sun, Apr 7, 2019 at 9:45 PM Roman Kennke wrote: > > Actually, I am not quite clear what is the success scenario or the > failure scenario. Can you describe a little more detail what I should > watch out for for both cases? To me it behaves all ~the same (maybe > that means I failed to reproduce so far) In the client(s) you should see (the numbers may be different): All messages arrived 120002911/120002911 and then the latency histogram. If you see: Interrupting wait for messages 100001234/120002911 then you have a failure. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From zgu at redhat.com Sun Apr 7 20:54:02 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Sun, 7 Apr 2019 16:54:02 -0400 Subject: Heads-Up: -XX:+ClassUnloadingWithConcurrentMark currently broken In-Reply-To: <3f0f96f6a546bc7f37998f32f3a7780a0fe93fb7.camel@redhat.com> References: <3f0f96f6a546bc7f37998f32f3a7780a0fe93fb7.camel@redhat.com> Message-ID: <3c5ae9bb-44f0-b974-3709-398bb759334a@redhat.com> What VM options you used? I tested with XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC XX:+ClassUnloadingWithConcurrentMark XX:ShenandoahUnloadClassesFrequency=2 passed SPECjvm (on gotland) and SPECjbb2015 (on polwarth) -Zhengyu On 4/7/19 10:04 AM, Roman Kennke wrote: > Just tried to run SPECjbb2015 with the flag, and it crashed within > first few minutes in C2-compiled code. I suspect it may be related to > recent roots scanning cleanups, and we're probably missing to mark some > constants. Will investigate. > > Roman > From simone.bordet at gmail.com Sun Apr 7 20:57:42 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Sun, 7 Apr 2019 22:57:42 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> Message-ID: Hi, On Sun, Apr 7, 2019 at 7:52 PM Simone Bordet wrote: > Will try the fastdebug build and report back. I got a crash with fastdebug, attached hs_err. Let me know if it's helpful. I'm interested in the details of the failure, if the file has enough information. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From shade at redhat.com Sun Apr 7 21:09:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 7 Apr 2019 23:09:58 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> Message-ID: <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> On 4/7/19 10:57 PM, Simone Bordet wrote: > On Sun, Apr 7, 2019 at 7:52 PM Simone Bordet wrote: >> Will try the fastdebug build and report back. > > I got a crash with fastdebug, attached hs_err. > > Let me know if it's helpful. > I'm interested in the details of the failure, if the file has enough > information. I think it has. Signal is raised trying to access 0x00007f006b8a54fc: siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x00007f006b8a54fc ...which looks to come from %rbx: RBX=0x00007f006b8a54fc: in /lib/x86_64-linux-gnu/libnsl.so.1 at 0x00007f006b7c5000 ...and Instructions section disassembly shows this: https://onlinedisassembler.com/odaweb/uV5P7D1q/0 00000016 48 bb fc 54 8a 6b 00 7f 00 00 movabs rbx,0x7f006b8a54fc 00000020 80 3c 0b 00 cmp BYTE PTR [rbx+rcx*1],0x0 <-- SEGV here It looks like bad constant oop in the generated code. -XX:ScavengeRootsInCode=0 might be a plausible workaround. -Aleksey From shade at redhat.com Sun Apr 7 21:20:25 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 7 Apr 2019 23:20:25 +0200 Subject: Troubles with Shenandoah In-Reply-To: <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> Message-ID: <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> On 4/7/19 11:09 PM, Aleksey Shipilev wrote: > It looks like bad constant oop in the generated code. -XX:ScavengeRootsInCode=0 might be a plausible > workaround. Also, it might be Shenandoah code roots code screwing up, try with -XX:ShenandoahCodeRootsStyle={0,1,2}. -Aleksey From rkennke at redhat.com Sun Apr 7 21:30:40 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 07 Apr 2019 23:30:40 +0200 Subject: Heads-Up: -XX:+ClassUnloadingWithConcurrentMark currently broken In-Reply-To: <3c5ae9bb-44f0-b974-3709-398bb759334a@redhat.com> References: <3f0f96f6a546bc7f37998f32f3a7780a0fe93fb7.camel@redhat.com> <3c5ae9bb-44f0-b974-3709-398bb759334a@redhat.com> Message-ID: Hmm, a second run with the same option did not crash. It may not be related. It looks a little like the crash that Simone reported. Roman Am 7. April 2019 22:54:02 MESZ schrieb Zhengyu Gu : >What VM options you used? I tested with >XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC >XX:+ClassUnloadingWithConcurrentMark >XX:ShenandoahUnloadClassesFrequency=2 > >passed SPECjvm (on gotland) and SPECjbb2015 (on polwarth) > >-Zhengyu > > > >On 4/7/19 10:04 AM, Roman Kennke wrote: >> Just tried to run SPECjbb2015 with the flag, and it crashed within >> first few minutes in C2-compiled code. I suspect it may be related to >> recent roots scanning cleanups, and we're probably missing to mark >some >> constants. Will investigate. >> >> Roman >> -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From zgu at redhat.com Mon Apr 8 00:57:12 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Sun, 7 Apr 2019 20:57:12 -0400 Subject: RFR(T) 8222086: CodeCache::UnloadingScope needs to preserve and restore previous IsUnloadingBehavior Message-ID: <4aee03db-ad25-23b9-04a9-1c4c72f7165c@redhat.com> Shenandoah can (will) do concurrent class unloading, but also unloads classes at pauses, e.g. during full gc. Currently, CodeCache::UnloadingScope's destructor resets IsUnloadingBehaviour that is setup for concurrent class unloading, which results fatal crash during next concurrent unloading cycle. Bug: https://bugs.openjdk.java.net/browse/JDK-8222086 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222086/webrev.00/ Test: hotspot_gc on Linux x64 (fastdebug and release) Submit tests. Thanks, -Zhengyu From gnu.andrew at redhat.com Mon Apr 8 04:53:31 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 8 Apr 2019 05:53:31 +0100 Subject: [RFR] [8u] 8u202 Upstream Sync Message-ID: <01082237-f8fb-40bf-3615-a2a3e790bbfb@redhat.com> Hi, I propose to merge jdk8u202-b08 (i.e. jdk8u202-ga) into the aarch64/shenandoah-jdk8u repository to create aarch64-shenandoah-jdk8u202-b08. As webrevs for such merges tend not to illustrate the actual changes taking place very well, I have instead just include the merge changesets this time and saved on uploading about a gigabyte of largely useless data... http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/root/merge.changeset Changes in aarch64-shenandoah-jdk8u201-b13: [These are committed changes but not yet tagged] - S8151775: aarch64: add support for 8.1 LSE atomic operations - S8153172: aarch64: hotspot crashes after the 8.1 LSE patch is merged - S8219635: aarch64: missing LoadStore barrier in TemplateTable::fast_storefield - S8221220: AArch64: Add StoreStore membar explicitly for Volatile Writes in TemplateTable Changes in aarch64-shenandoah-jdk8u202-b08: - S8033251: Use DWARF debug symbols for Linux 32-bit as default - S8044235: src.zip should include all sources - S8064811: Use THREAD instead of CHECK_NULL in return statements - S8068440: Test6857159.java times out - S8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling - S8073159: improve Test6857159.java - S8129560: TestKeyPairGenerator.java fails on Solaris because private exponent needs to comply with FIPS 186-4 - S8130655: OS X: keyboard input in textfield is not possible if the window contained textfield is owned by EmbeddedFrame - S8131048: ppc implement CRC32 intrinsic - S8131051: KDC might issue a renewable ticket even if not requested - S8134124: sun/security/tools/jarsigner/warnings.sh fails when using Hindi locale - S8139507: WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs - S8141421: Various test fail with OOME on win x86 - S8145788: JVM crashes with -XX:+EnableTracing - S8155635: C2: Mixed unsafe accesses break alias analysis - S8156709: Cannot call setSeed on NativePRNG on Mac if EGD is /dev/urandom - S8160928: javac incorrectly copies over interior type annotations to bridge method - S8161732: [TEST_BUG] Test closed/java/awt/MenuBar/MenuBarPeer/MenuBarPeerDisposeTest.java fails in unix enviroments with NullPointerException - S8163083: SocketListeningConnector does not allow invocations with port 0 - S8164383: jhsdb dumps core on Solaris 12 when loading dumped core - S8164920: ppc: enhancement of CRC32 intrinsic - S8165852: (fs) Mount point not found for a file which is present in overlayfs - S8170937: Swing apps are slow if displaying from a remote source to many local displays - S8172850: Anti-dependency on membar causes crash in register allocator due to invalid instruction scheduling - S8174050: Compilation errors with clang-4.0 - S8182461: IndexOutOfBoundsException when reading indexed color BMP - S8183979: Remove Kodak CMS (KCMS) code from Oracle JDK - S8186098: sun/security/pkcs11/KeyStore/SecretKeysBasic.sh failed due to libnss3 version cannot be parsed - S8187218: GSSCredential.getRemainingLifetime() returns negative value for TTL > 24 days. - S8189762: [TESTBUG] Create tests for JDK-8146115 container awareness and resource configuration - S8191006: hsdis disassembler plugin does not compile with binutils 2.29+ - S8191178: [macos] Problem with input of yen symbol - S8191948: db error: InvalidTypeException: Can't assign double[][][] to double[][][] - S8193879: Java debugger hangs on method invocation - S8194864: Outputs more details for PKCS11 tests if the NSS lib version cannot be determined - S8196882: VS2017 Hotspot Defined vsnprintf Function Causes C2084 Already Defined Compilation Error - S8200719: Cannot connect to IPv6 host when exists any active network interface without IPv6 address - S8201801: RTL language (Hebrew) is presented from left to right - S8201818: [macosx] Printing attributes break page size set via "java.awt.print.Book" object - S8202261: (fc) FileChannel.map and RandomAccessFile.setLength should not preallocate space - S8202264: Race condition in AudioClip.loop() - S8202557: OpenJDK fails to start in Windows 7 and 8.1 after upgrading compiler to VC 2017 - S8204966: [TESTBUG] hotspot/test/compiler/whitebox/IsMethodCompilableTest.java test fails with -XX:CompileThreshold=1 - S8205330: InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection - S8205479: OS X: requestFocus() does not work properly for embedded frame - S8205965: SIGSEGV on write to NativeCallStack::EMPTY_STACK - S8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut - S8206911: javax/xml/crypto/dsig/GenerationTests.java fails in 8u-dev - S8207057: No debug info for assembler files - S8207060: Memory leak when malloc fails within WITH_UNICODE_STRING block - S8207145: (fs) Native memory leak in WindowsNativeDispatcher.LookupPrivilegeValue0 - S8207150: Clip.isRunning() may return true after Clip.stop() was called - S8207322: Backport GTK3 support on Linux to 8u - S8207750: Native handle leak in java.io.WinNTFileSystem.list() - S8207775: Better management of CipherCore buffers - S8208091: SA: jhsdb jstack --mixed throws UnmappedAddressException on i686 - S8208183: update HSDIS plugin license to UPL - S8208541: non-ASCII characters in hsdis UPL text - S8208583: Better management of internal KeyStore buffers - S8208638: Instead of circle rendered in appl window, but ellipse is produced JEditor Pane - S8209002: 8u192 installed exe and dll files have wrong file version - S8209129: Further improvements to cipher buffer management - S8209184: JCK Test Failure due to ResourceBundle - S8209359: [8u] hotspot needs to recognise cl.exe 19.13 to build with VS2017. - S8209639: assert failure in coalesce.cpp: attempted to spill a non-spillable item - S8209862: CipherCore performance improvement - S8209863: Add a test to verify that -XX:+EnableTracing works - S8210350: -Wl,-z,defs JDK 8 build failure - S8210384: SunLayoutEngine.isAAT() font is expensive on MacOS - S8210423: Backport of 8034788 breaks GCC version detection - S8210695: Create test to cover JDK-8205330 InitialDirContext ctor sometimes throws NPE if the server has sent a disconnection - S8210736: jdk/javax/xml/crypto/dsig/GenerationTests.java slow on linux - S8210891: Remove unused extutil.h from JDK8u sources - S8211107: LDAPS communication failure with jdk 1.8.0_181 - S8211124: HotSpot update for vm_version.cpp to recognise updated VS2017 - S8211150: G1 Full GC not purging code root memory and hence causing memory leak - S8211387: [Zero] atomic_copy64: Use ldrexd for atomic reads on ARMv7 - S8211394: CHECK_ must be used in the rhs of an assignment statement within a block - S8211909: JDWP Transport Listener: dt_socket thread crash - S8211933: [8u] hotspot adlc needs to link statically with libstdc++ for gcc7.3 - S8212709: Backout backport of JDK-8211394 from jdk 8u-dev - S8212821: CHECK_ must be used in the rhs of an assignment statement within a block (round 2) diffstat for corba b/.hgtags | 8 ++++++++ b/THIRD_PARTY_README | 29 ----------------------------- 2 files changed, 8 insertions(+), 29 deletions(-) diffstat for hotspot a/test/compiler/6857159/Test6857159.sh | 54 b/.hgtags | 8 b/THIRD_PARTY_README | 29 b/agent/src/os/solaris/proc/salibproc.h | 20 b/agent/src/os/solaris/proc/saproc.cpp | 8 b/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java | 10 b/agent/src/share/classes/sun/jvm/hotspot/debugger/windows/x86/WindowsX86CFrame.java | 10 b/make/defs.make | 10 b/make/linux/makefiles/adlc.make | 8 b/make/linux/makefiles/gcc.make | 6 b/make/linux/makefiles/saproc.make | 2 b/make/windows/makefiles/compile.make | 3 b/src/cpu/ppc/vm/assembler_ppc.hpp | 8 b/src/cpu/ppc/vm/assembler_ppc.inline.hpp | 4 b/src/cpu/ppc/vm/interpreterGenerator_ppc.hpp | 2 b/src/cpu/ppc/vm/macroAssembler_ppc.cpp | 972 ++++++++++ b/src/cpu/ppc/vm/macroAssembler_ppc.hpp | 28 b/src/cpu/ppc/vm/stubGenerator_ppc.cpp | 86 b/src/cpu/ppc/vm/stubRoutines_ppc_64.cpp | 763 +++++++ b/src/cpu/ppc/vm/stubRoutines_ppc_64.hpp | 38 b/src/cpu/ppc/vm/templateInterpreter_ppc.cpp | 191 + b/src/cpu/ppc/vm/vm_version_ppc.cpp | 17 b/src/cpu/ppc/vm/vm_version_ppc.hpp | 3 b/src/os/aix/vm/perfMemory_aix.cpp | 4 b/src/os/bsd/vm/perfMemory_bsd.cpp | 4 b/src/os/linux/vm/os_linux.cpp | 2 b/src/os/linux/vm/perfMemory_linux.cpp | 4 b/src/os/posix/vm/os_posix.cpp | 12 b/src/os/solaris/vm/perfMemory_solaris.cpp | 4 b/src/os/windows/vm/os_windows.cpp | 36 b/src/os_cpu/linux_zero/vm/os_linux_zero.hpp | 10 b/src/share/tools/hsdis/Makefile | 45 b/src/share/tools/hsdis/README | 65 b/src/share/tools/hsdis/hsdis-demo.c | 46 b/src/share/tools/hsdis/hsdis.c | 64 b/src/share/tools/hsdis/hsdis.h | 44 b/src/share/vm/ci/ciReplay.cpp | 5 b/src/share/vm/classfile/classLoaderData.cpp | 4 b/src/share/vm/classfile/defaultMethods.cpp | 4 b/src/share/vm/classfile/javaClasses.cpp | 2 b/src/share/vm/classfile/systemDictionary.cpp | 2 b/src/share/vm/classfile/verificationType.cpp | 2 b/src/share/vm/classfile/verificationType.hpp | 4 b/src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp | 23 b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp | 3 b/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp | 8 b/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp | 11 b/src/share/vm/memory/allocation.cpp | 5 b/src/share/vm/memory/oopFactory.hpp | 20 b/src/share/vm/oops/constantPool.cpp | 2 b/src/share/vm/oops/generateOopMap.cpp | 9 b/src/share/vm/oops/instanceKlass.cpp | 6 b/src/share/vm/oops/klass.cpp | 2 b/src/share/vm/oops/methodData.cpp | 4 b/src/share/vm/oops/objArrayKlass.cpp | 8 b/src/share/vm/oops/typeArrayKlass.cpp | 4 b/src/share/vm/opto/cfgnode.cpp | 1 b/src/share/vm/opto/coalesce.cpp | 32 b/src/share/vm/opto/compile.cpp | 25 b/src/share/vm/opto/library_call.cpp | 70 b/src/share/vm/opto/loopPredicate.cpp | 2 b/src/share/vm/opto/machnode.cpp | 1 b/src/share/vm/opto/matcher.cpp | 3 b/src/share/vm/opto/runtime.cpp | 19 b/src/share/vm/opto/type.cpp | 9 b/src/share/vm/opto/type.hpp | 2 b/src/share/vm/prims/jni.cpp | 2 b/src/share/vm/prims/jvm.cpp | 12 b/src/share/vm/prims/jvmtiEnv.cpp | 52 b/src/share/vm/prims/methodHandles.cpp | 8 b/src/share/vm/runtime/fieldDescriptor.cpp | 4 b/src/share/vm/runtime/os.cpp | 8 b/src/share/vm/runtime/os.hpp | 3 b/src/share/vm/runtime/reflection.cpp | 4 b/src/share/vm/runtime/synchronizer.hpp | 4 b/src/share/vm/runtime/vm_version.cpp | 9 b/src/share/vm/services/mallocSiteTable.hpp | 4 b/src/share/vm/services/memTracker.hpp | 10 b/src/share/vm/services/virtualMemoryTracker.cpp | 2 b/src/share/vm/services/virtualMemoryTracker.hpp | 4 b/src/share/vm/trace/traceEventClasses.xsl | 4 b/src/share/vm/trace/traceStream.hpp | 13 b/src/share/vm/utilities/array.hpp | 4 b/src/share/vm/utilities/exceptions.cpp | 4 b/src/share/vm/utilities/exceptions.hpp | 2 b/src/share/vm/utilities/globalDefinitions_visCPP.hpp | 10 b/src/share/vm/utilities/nativeCallStack.cpp | 5 b/src/share/vm/utilities/nativeCallStack.hpp | 15 b/src/share/vm/utilities/ostream.cpp | 134 + b/src/share/vm/utilities/ostream.hpp | 1 b/test/compiler/6857159/Test6857159.java | 33 b/test/compiler/c2/SubsumingLoadsCauseFlagSpill.java | 72 b/test/compiler/gcbarriers/TestMembarDependencies.java | 98 + b/test/compiler/unsafe/MixedUnsafeStoreObject.java | 76 b/test/compiler/whitebox/CompilerWhiteBoxTest.java | 6 b/test/runtime/EnableTracing/TestEnableTracing.java | 56 b/test/test_env.sh | 9 97 files changed, 3154 insertions(+), 426 deletions(-) diffstat for jaxp b/.hgtags | 8 ++++++++ b/THIRD_PARTY_README | 29 ----------------------------- 2 files changed, 8 insertions(+), 29 deletions(-) diffstat for jaxws b/.hgtags | 8 ++++++++ b/THIRD_PARTY_README | 29 ----------------------------- 2 files changed, 8 insertions(+), 29 deletions(-) diffstat for jdk a/make/mapfiles/libkcms/mapfile-vers | 47 a/src/solaris/native/sun/awt/extutil.h | 251 b/.hgtags | 8 b/THIRD_PARTY_README | 29 b/make/CompileJavaClasses.gmk | 4 b/make/CopyFiles.gmk | 9 b/make/CopyIntoClasses.gmk | 10 b/make/CreateJars.gmk | 83 b/make/lib/Awt2dLibraries.gmk | 57 b/make/lib/SoundLibraries.gmk | 4 b/make/mapfiles/libawt_xawt/mapfile-vers | 3 b/make/mapfiles/libnio/mapfile-linux | 3 b/make/mapfiles/libnio/mapfile-macosx | 3 b/make/mapfiles/libnio/mapfile-solaris | 3 b/make/profile-includes.txt | 1 b/src/macosx/classes/java/util/prefs/MacOSXPreferences.java | 34 b/src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java | 16 b/src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java | 2 b/src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java | 41 b/src/macosx/native/sun/awt/AWTView.m | 8 b/src/macosx/native/sun/awt/AWTWindow.m | 16 b/src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java | 3 b/src/share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java | 29 b/src/share/classes/com/sun/java/swing/plaf/gtk/GTKGraphicsUtils.java | 33 b/src/share/classes/com/sun/java/swing/plaf/gtk/GTKIconFactory.java | 14 b/src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java | 34 b/src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java | 102 b/src/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java | 38 b/src/share/classes/com/sun/jdi/connect/ListeningConnector.java | 8 b/src/share/classes/com/sun/media/sound/DirectAudioDevice.java | 48 b/src/share/classes/com/sun/media/sound/EventDispatcher.java | 9 b/src/share/classes/com/sun/media/sound/JavaSoundAudioClip.java | 44 b/src/share/classes/com/sun/tools/jdi/GenericListeningConnector.java | 8 b/src/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java | 12 b/src/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java | 8 b/src/share/classes/com/sun/tools/jdi/SocketListeningConnector.java | 20 b/src/share/classes/com/sun/tools/jdi/VMState.java | 18 b/src/share/classes/java/util/ResourceBundle.java | 8 b/src/share/classes/javax/swing/text/html/ImageView.java | 42 b/src/share/classes/sun/font/SunLayoutEngine.java | 31 b/src/share/classes/sun/font/TrueTypeFont.java | 1 b/src/share/classes/sun/nio/ch/FileChannelImpl.java | 15 b/src/share/classes/sun/nio/ch/FileDispatcher.java | 9 b/src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java | 7 b/src/share/classes/sun/security/krb5/KrbKdcRep.java | 9 b/src/share/native/com/sun/media/sound/SoundDefs.h | 4 b/src/solaris/bin/ppc64le/jvm.cfg | 34 b/src/solaris/classes/java/util/prefs/FileSystemPreferences.java | 38 b/src/solaris/classes/sun/awt/UNIXToolkit.java | 70 b/src/solaris/classes/sun/awt/X11/XDesktopPeer.java | 8 b/src/solaris/classes/sun/awt/X11/XMenuBarPeer.java | 16 b/src/solaris/classes/sun/awt/X11/XToolkit.java | 91 b/src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java | 12 b/src/solaris/classes/sun/nio/fs/LinuxFileStore.java | 21 b/src/solaris/classes/sun/nio/fs/LinuxFileSystem.java | 6 b/src/solaris/classes/sun/security/provider/NativePRNG.java | 3 b/src/solaris/native/java/io/io_util_md.c | 19 b/src/solaris/native/java/net/net_util_md.c | 4 b/src/solaris/native/sun/awt/awt_InputMethod.c | 3 b/src/solaris/native/sun/awt/awt_UNIXToolkit.c | 89 b/src/solaris/native/sun/awt/gtk2_interface.c | 361 - b/src/solaris/native/sun/awt/gtk2_interface.h | 490 - b/src/solaris/native/sun/awt/gtk3_interface.c | 2863 ++++++++++ b/src/solaris/native/sun/awt/gtk3_interface.h | 577 ++ b/src/solaris/native/sun/awt/gtk_interface.c | 161 b/src/solaris/native/sun/awt/gtk_interface.h | 567 + b/src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c | 78 b/src/solaris/native/sun/awt/swing_GTKEngine.c | 141 b/src/solaris/native/sun/awt/swing_GTKStyle.c | 37 b/src/solaris/native/sun/nio/ch/FileChannelImpl.c | 39 b/src/solaris/native/sun/nio/ch/FileDispatcherImpl.c | 59 b/src/solaris/native/sun/xawt/XToolkit.c | 4 b/src/solaris/native/sun/xawt/awt_Desktop.c | 14 b/src/solaris/native/sun/xawt/gnome_interface.h | 4 b/src/windows/classes/java/util/prefs/WindowsPreferences.java | 36 b/src/windows/classes/java/util/prefs/WindowsPreferencesFactory.java | 6 b/src/windows/classes/sun/nio/ch/FileDispatcherImpl.java | 11 b/src/windows/classes/sun/nio/fs/WindowsSecurity.java | 9 b/src/windows/native/java/io/WinNTFileSystem_md.c | 21 b/src/windows/native/java/io/io_util_md.c | 12 b/src/windows/native/sun/nio/ch/FileChannelImpl.c | 35 b/src/windows/native/sun/nio/ch/FileDispatcherImpl.c | 27 b/src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c | 7 b/test/ProblemList.txt | 6 b/test/com/sun/jdi/MethodInvokeWithTraceOnTest.java | 168 b/test/com/sun/jdi/TestScaffold.java | 15 b/test/com/sun/jdi/connect/WildcardPortSupport.java | 141 b/test/java/awt/Desktop/DesktopGtkLoadTest/DesktopGtkLoadTest.java | 66 b/test/java/awt/Frame/CycleThroughFrameTest/CycleThroughFrameTest.java | 141 b/test/java/awt/Gtk/GtkVersionTest/GtkVersionTest.java | 78 b/test/java/awt/Toolkit/ScreenInsetsTest/ScreenInsetsTest.java | 39 b/test/java/awt/Window/WindowOwnedByEmbeddedFrameTest/WindowOwnedByEmbeddedFrameTest.java | 104 b/test/java/security/SecureRandom/MacNativePRNGSetSeed.java | 37 b/test/javax/imageio/plugins/bmp/BMP8BPPLoadTest.java | 53 b/test/javax/sound/sampled/Clip/AutoCloseTimeCheck.java | 128 b/test/javax/sound/sampled/Clip/ClipIsRunningAfterStop.java | 96 b/test/javax/swing/JEditorPane/8195095/ImageViewTest.java | 82 b/test/javax/swing/LookAndFeel/8145547/DemandGTK.java | 70 b/test/javax/swing/LookAndFeel/8145547/DemandGTK2.sh | 87 b/test/javax/swing/LookAndFeel/8145547/DemandGTK2.txt | 37 b/test/javax/swing/LookAndFeel/8145547/DemandGTK3.sh | 80 b/test/javax/swing/LookAndFeel/8145547/ProvokeGTK.java | 56 b/test/javax/xml/crypto/dsig/GenerationTests.java | 35 b/test/lib/testlibrary/jdk/testlibrary/Utils.java | 31 b/test/sun/security/krb5/auto/KDC.java | 108 b/test/sun/security/krb5/auto/LongLife.java | 96 b/test/sun/security/pkcs11/PKCS11Test.java | 29 b/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java | 4 b/test/tools/launcher/Settings.java | 2 109 files changed, 7245 insertions(+), 1703 deletions(-) diffstat for langtools b/.hgtags | 8 b/THIRD_PARTY_README | 29 -- b/src/share/classes/com/sun/tools/javac/code/SymbolMetadata.java | 22 +- b/test/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java | 97 ++++++++++ 4 files changed, 124 insertions(+), 32 deletions(-) diffstat for nashorn b/.hgtags | 8 ++++++++ b/THIRD_PARTY_README | 29 ----------------------------- 2 files changed, 8 insertions(+), 29 deletions(-) diffstat for root b/.hgtags | 8 b/THIRD_PARTY_README | 29 - b/common/autoconf/basics.m4 | 2 b/common/autoconf/flags.m4 | 10 b/common/autoconf/generated-configure.sh | 578 +++++++++++++++++++++++++++++-- b/common/autoconf/jdk-options.m4 | 2 b/common/autoconf/platform.m4 | 2 b/common/autoconf/spec.gmk.in | 2 b/common/autoconf/toolchain_windows.m4 | 47 ++ 9 files changed, 628 insertions(+), 52 deletions(-) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From rkennke at redhat.com Mon Apr 8 07:12:35 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 09:12:35 +0200 Subject: Troubles with Shenandoah In-Reply-To: <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: <5ee62c40c737e845d318839e958946bd97f439a7.camel@redhat.com> It might also be worth trying: -XX:-ShenandoahConcurrentScanCodeRoots and/or -XX:-ShenandoahOptimizeStaticFinals. > On 4/7/19 11:09 PM, Aleksey Shipilev wrote: > > It looks like bad constant oop in the generated code. > > -XX:ScavengeRootsInCode=0 might be a plausible > > workaround. > > Also, it might be Shenandoah code roots code screwing up, try with > -XX:ShenandoahCodeRootsStyle={0,1,2}. > > -Aleksey > From aph at redhat.com Mon Apr 8 08:28:59 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 8 Apr 2019 09:28:59 +0100 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: <071b38ba-344c-f1a7-a03d-0d9ef44aaa21@redhat.com> Message-ID: <6e110064-02fb-b57f-fcfe-6621bdd3525c@redhat.com> On 4/7/19 7:18 PM, Roman Kennke wrote: > On 4/2/19 10:12 PM, Roman Kennke wrote: >>> - No more need for object equals barriers. >> >> I'm pleased about that. I really hated the AArch64 Shenandoah CAS! > > I'm sorry to disappoint you, but the CAS barrier is still needed. The > memory location may still legally hold a from-space reference, and > comparing that to a to-space reference needs some special care. And > yes, ZGC has a similar problem as far as I know. That's interesting. Could we not simply promote the reference in the reference field we're CASing, then do a normal CAS? -- 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 Mon Apr 8 08:36:05 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 10:36:05 +0200 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: <6e110064-02fb-b57f-fcfe-6621bdd3525c@redhat.com> References: <071b38ba-344c-f1a7-a03d-0d9ef44aaa21@redhat.com> <6e110064-02fb-b57f-fcfe-6621bdd3525c@redhat.com> Message-ID: On 4/7/19 7:18 PM, Roman Kennke wrote: > > On 4/2/19 10:12 PM, Roman Kennke wrote: > > > > - No more need for object equals barriers. > > > > > > I'm pleased about that. I really hated the AArch64 Shenandoah > > > CAS! > > > > I'm sorry to disappoint you, but the CAS barrier is still needed. > > The > > memory location may still legally hold a from-space reference, and > > comparing that to a to-space reference needs some special care. And > > yes, ZGC has a similar problem as far as I know. > > That's interesting. Could we not simply promote the reference in the > reference field we're CASing, then do a normal CAS? Yes. But it requires two CASes in a row. Don't know if that is better than our loop, which is rarely even entered (normally the CAS-construct goes via fast-path with a single CAS). Roman From shade at redhat.com Mon Apr 8 09:11:05 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 11:11:05 +0200 Subject: [RFR] [8u] 8u202 Upstream Sync In-Reply-To: <01082237-f8fb-40bf-3615-a2a3e790bbfb@redhat.com> References: <01082237-f8fb-40bf-3615-a2a3e790bbfb@redhat.com> Message-ID: On 4/8/19 6:53 AM, Andrew John Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/jaxws/merge.changeset Looks trivially fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/jdk/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/langtools/merge.changeset Looks fine. Hotspot/Shenandoah changes would need to be tested right after the integration, I think. They look fine, but might surprise us. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/nashorn/merge.changeset Looks trivially fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/root/merge.changeset Looks fine. Thumbs up. -Aleksey From rkennke at redhat.com Mon Apr 8 09:13:56 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 11:13:56 +0200 Subject: Troubles with Shenandoah In-Reply-To: <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: I'm still failing to reproduce the problem. I am running with those settings: /home/rkennke/progs/jdk- 12+33/bin/java -showversion -Xmx16g -Xms2g -Xlog:gc:stderr:time,level,tags -XX:+PrintCommandLineFlags -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC and I don't get lost messages or anything like that. I am having troubles with the benchmark though: if I understand it correctly, the server and client are asking some parameters on startup. However, for some reason, I don't see the messages printed out, but apparently it is waiting for input. So I keep pressing ENTER a couple of times, blindly. The questions start appearing then. (Missing terminal flushes/syncs?) Also, the client appears to be waiting for something between test runs. Is there a way to automate this? I.e. pass the parameters to the pom.xml and make the client not wait between runs? client output typically looks like this: https://paste.fedoraproject.org/paste/0-DFcz5bwJ9cQNPfd4Jfrg Roman >On 4/7/19 11:09 PM, Aleksey Shipilev wrote: > > It looks like bad constant oop in the generated code. > > -XX:ScavengeRootsInCode=0 might be a plausible > > workaround. > > Also, it might be Shenandoah code roots code screwing up, try with > -XX:ShenandoahCodeRootsStyle={0,1,2}. > > -Aleksey > From aph at redhat.com Mon Apr 8 09:19:21 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 8 Apr 2019 10:19:21 +0100 Subject: RFR: JDK-8221766: Load-reference barriers for Shenandoah In-Reply-To: References: <071b38ba-344c-f1a7-a03d-0d9ef44aaa21@redhat.com> <6e110064-02fb-b57f-fcfe-6621bdd3525c@redhat.com> Message-ID: <0cb44e4b-8967-48bd-5f77-e0c443b63410@redhat.com> On 4/8/19 9:36 AM, Roman Kennke wrote: > On 4/7/19 7:18 PM, Roman Kennke wrote: >>> On 4/2/19 10:12 PM, Roman Kennke wrote: >>>>> - No more need for object equals barriers. >>>> >>>> I'm pleased about that. I really hated the AArch64 Shenandoah >>>> CAS! >>> >>> I'm sorry to disappoint you, but the CAS barrier is still needed. >>> The >>> memory location may still legally hold a from-space reference, and >>> comparing that to a to-space reference needs some special care. And >>> yes, ZGC has a similar problem as far as I know. >> >> That's interesting. Could we not simply promote the reference in the >> reference field we're CASing, then do a normal CAS? > > Yes. But it requires two CASes in a row. Don't know if that is better > than our loop, which is rarely even entered (normally the CAS-construct > goes via fast-path with a single CAS). I think it's better, yes: it's significantly less complex to promote both if needed and then do a normal CAS. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From simone.bordet at gmail.com Mon Apr 8 09:58:17 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 11:58:17 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: Hi, On Mon, Apr 8, 2019 at 11:13 AM Roman Kennke wrote: > > I'm still failing to reproduce the problem. I am running with those > settings: > > /home/rkennke/progs/jdk- > 12+33/bin/java > > -showversion > -Xmx16g > -Xms2g > -Xlog:gc:stderr:time,level,tags > -XX:+PrintCommandLineFlags > -XX:+UnlockExperimentalVMOptions > -XX:+UseShenandoahGC > > > and I don't get lost messages or anything like that. > > I am having troubles with the benchmark though: if I understand it > correctly, the server and client are asking some parameters on startup. > However, for some reason, I don't see the messages printed out, but > apparently it is waiting for input. So I keep pressing ENTER a couple > of times, blindly. Please see my previous message about this: it's a Maven library bug and I explain the workaround. For short runs such as ~10s when you press all enters to the benchmark, I also don't see any problem. They start to appear for longer runs. Try to set batch size = 10000 (i.e. 10 times the default). This will make the benchmark run for ~100s and for me this was enough to get the failures. > The questions start appearing then. (Missing > terminal flushes/syncs?) Also, the client appears to be waiting for > something between test runs. Is there a way to automate this? I.e. pass > the parameters to the pom.xml and make the client not wait between > runs? You can't make automatic back to back runs, but you can tune the parameters to make a run longer, see above. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From rkennke at redhat.com Mon Apr 8 10:26:31 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 12:26:31 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: <40acfddcdb62191534757dc71d11ecbeac260e06.camel@redhat.com> > Hi Simone, > > I'm still failing to reproduce the problem. I am running with those > > settings: > > > > /home/rkennke/progs/jdk- > > 12+33/bin/java > > > > -showversion > > -Xmx16g > > -Xms2g > > -Xlog:gc:stderr:time,level,tags > > -XX:+PrintCommandLineFlags > > -XX:+UnlockExperimentalVMOptions > > -XX:+UseShenandoahGC > > > > > > and I don't get lost messages or anything like that. > > > > I am having troubles with the benchmark though: if I understand it > > correctly, the server and client are asking some parameters on > > startup. > > However, for some reason, I don't see the messages printed out, but > > apparently it is waiting for input. So I keep pressing ENTER a > > couple > > of times, blindly. > > Please see my previous message about this: it's a Maven library bug > and I explain the workaround. Oh, somehow I missed that. This works now. Thanks! > For short runs such as ~10s when you press all enters to the > benchmark, I also don't see any problem. > They start to appear for longer runs. > Try to set batch size = 10000 (i.e. 10 times the default). This will > make the benchmark run for ~100s and for me this was enough to get > the > failures. You probably mean batch count? With batch count = 10000, it still works well here. With batch *size* cranked from 10 to 10000, I am getting exceptions. Roman From rkennke at redhat.com Mon Apr 8 10:43:11 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 12:43:11 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: I think I can see the problem with clients=10000: Waiting for messages to arrive 8446564/10001850 Right? Roman > Hi, > > On Mon, Apr 8, 2019 at 11:13 AM Roman Kennke > wrote: > > I'm still failing to reproduce the problem. I am running with those > > settings: > > > > /home/rkennke/progs/jdk- > > 12+33/bin/java > > > > -showversion > > -Xmx16g > > -Xms2g > > -Xlog:gc:stderr:time,level,tags > > -XX:+PrintCommandLineFlags > > -XX:+UnlockExperimentalVMOptions > > -XX:+UseShenandoahGC > > > > > > and I don't get lost messages or anything like that. > > > > I am having troubles with the benchmark though: if I understand it > > correctly, the server and client are asking some parameters on > > startup. > > However, for some reason, I don't see the messages printed out, but > > apparently it is waiting for input. So I keep pressing ENTER a > > couple > > of times, blindly. > > Please see my previous message about this: it's a Maven library bug > and I explain the workaround. > > For short runs such as ~10s when you press all enters to the > benchmark, I also don't see any problem. > They start to appear for longer runs. > Try to set batch size = 10000 (i.e. 10 times the default). This will > make the benchmark run for ~100s and for me this was enough to get > the > failures. > > > The questions start appearing then. (Missing > > terminal flushes/syncs?) Also, the client appears to be waiting for > > something between test runs. Is there a way to automate this? I.e. > > pass > > the parameters to the pom.xml and make the client not wait between > > runs? > > You can't make automatic back to back runs, but you can tune the > parameters to make a run longer, see above. > From rkennke at redhat.com Mon Apr 8 10:58:49 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 12:58:49 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: I also see it with latest jdk/jdk build. Also, I notice that latencies go through the roof. Usally in the us range, we suddenly get up to multi-seconds (!!) range. @ _ 1.394.016 ?s (207208, 2,09%) @ _ 2.788.033 ?s (710359, 7,16%) @ _ 4.182.050 ?s (853475, 8,60%) @ _ 5.576.067 ?s (735210, 7,41%) @ _ 6.970.084 ?s (732427, 7,38%) @ _ 8.364.101 ?s (694916, 7,00%) @ _ 9.758.118 ?s (593103, 5,98%) @ _ 11.152.134 ?s (715708, 7,21%) ^50% @ _ 12.546.151 ?s (769548, 7,76%) @ _ 13.940.168 ?s (739466, 7,45%) @ _ 15.334.185 ?s (854111, 8,61%) @ _ 16.728.202 ?s (739780, 7,46%) @ _ 18.122.219 ?s (584904, 5,90%) ^85% WTF is going on here?! Roman > Hi, > > On Mon, Apr 8, 2019 at 11:13 AM Roman Kennke > wrote: > > I'm still failing to reproduce the problem. I am running with those > > settings: > > > > /home/rkennke/progs/jdk- > > 12+33/bin/java > > > > -showversion > > -Xmx16g > > -Xms2g > > -Xlog:gc:stderr:time,level,tags > > -XX:+PrintCommandLineFlags > > -XX:+UnlockExperimentalVMOptions > > -XX:+UseShenandoahGC > > > > > > and I don't get lost messages or anything like that. > > > > I am having troubles with the benchmark though: if I understand it > > correctly, the server and client are asking some parameters on > > startup. > > However, for some reason, I don't see the messages printed out, but > > apparently it is waiting for input. So I keep pressing ENTER a > > couple > > of times, blindly. > > Please see my previous message about this: it's a Maven library bug > and I explain the workaround. > > For short runs such as ~10s when you press all enters to the > benchmark, I also don't see any problem. > They start to appear for longer runs. > Try to set batch size = 10000 (i.e. 10 times the default). This will > make the benchmark run for ~100s and for me this was enough to get > the > failures. > > > The questions start appearing then. (Missing > > terminal flushes/syncs?) Also, the client appears to be waiting for > > something between test runs. Is there a way to automate this? I.e. > > pass > > the parameters to the pom.xml and make the client not wait between > > runs? > > You can't make automatic back to back runs, but you can tune the > parameters to make a run longer, see above. > From rkennke at redhat.com Mon Apr 8 12:38:37 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 14:38:37 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: <76cdde2e4f799f4326e407377ed9771570c87d17.camel@redhat.com> Can you try with -XX:ShenandoahParallelSafepointThreads=2 ? It defaults to 4, and this seems to cause troubles for yet-unknown reasons. With this setting, it can handle approximately as much load as other GCs here. The dropping of messages seems to happen with any GC if load is high enough, is that correct? Roman > Hi, > > On Mon, Apr 8, 2019 at 11:13 AM Roman Kennke > wrote: > > I'm still failing to reproduce the problem. I am running with those > > settings: > > > > /home/rkennke/progs/jdk- > > 12+33/bin/java > > > > -showversion > > -Xmx16g > > -Xms2g > > -Xlog:gc:stderr:time,level,tags > > -XX:+PrintCommandLineFlags > > -XX:+UnlockExperimentalVMOptions > > -XX:+UseShenandoahGC > > > > > > and I don't get lost messages or anything like that. > > > > I am having troubles with the benchmark though: if I understand it > > correctly, the server and client are asking some parameters on > > startup. > > However, for some reason, I don't see the messages printed out, but > > apparently it is waiting for input. So I keep pressing ENTER a > > couple > > of times, blindly. > > Please see my previous message about this: it's a Maven library bug > and I explain the workaround. > > For short runs such as ~10s when you press all enters to the > benchmark, I also don't see any problem. > They start to appear for longer runs. > Try to set batch size = 10000 (i.e. 10 times the default). This will > make the benchmark run for ~100s and for me this was enough to get > the > failures. > > > The questions start appearing then. (Missing > > terminal flushes/syncs?) Also, the client appears to be waiting for > > something between test runs. Is there a way to automate this? I.e. > > pass > > the parameters to the pom.xml and make the client not wait between > > runs? > > You can't make automatic back to back runs, but you can tune the > parameters to make a run longer, see above. > From simone.bordet at gmail.com Mon Apr 8 12:53:43 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 14:53:43 +0200 Subject: Troubles with Shenandoah In-Reply-To: <40acfddcdb62191534757dc71d11ecbeac260e06.camel@redhat.com> References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> <40acfddcdb62191534757dc71d11ecbeac260e06.camel@redhat.com> Message-ID: Hi, On Mon, Apr 8, 2019 at 12:26 PM Roman Kennke wrote: > You probably mean batch count? With batch count = 10000, it still works > well here. Sorry, yes I meant batch count. Have you tried longer? -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From simone.bordet at gmail.com Mon Apr 8 12:55:24 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 14:55:24 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: Hi, On Mon, Apr 8, 2019 at 12:43 PM Roman Kennke wrote: > > I think I can see the problem with clients=10000: > > Waiting for messages to arrive 8446564/10001850 The "Waiting" is fine - it'll wait until it sees no progress. When you see "Interrupting" means the client gave up and that is your failure. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From rkennke at redhat.com Mon Apr 8 12:58:46 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 14:58:46 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: <46181acf14f624fe5f9321d49d8c9901d0265a3c.camel@redhat.com> Hi, > > On Mon, Apr 8, 2019 at 12:43 PM Roman Kennke > wrote: > > I think I can see the problem with clients=10000: > > > > Waiting for messages to arrive 8446564/10001850 > > The "Waiting" is fine - it'll wait until it sees no progress. > > When you see "Interrupting" means the client gave up and that is your > failure. Yes. I see it interrupting with any GC if I run with enough clients (e.g. they all fail with 9000 clients). Depending on settings, this may fail earlier. This appears to be an overloading problem, isn't it? Or is overloading by cranking up client count not the problem that you have? Roman From simone.bordet at gmail.com Mon Apr 8 12:59:53 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 14:59:53 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: Hi, On Mon, Apr 8, 2019 at 12:59 PM Roman Kennke wrote: > > I also see it with latest jdk/jdk build. > > Also, I notice that latencies go through the roof. Usally in the us > range, we suddenly get up to multi-seconds (!!) range. > > @ _ 1.394.016 ?s (207208, 2,09%) > @ _ 2.788.033 ?s (710359, 7,16%) > @ _ 4.182.050 ?s (853475, 8,60%) > @ _ 5.576.067 ?s (735210, 7,41%) > @ _ 6.970.084 ?s (732427, 7,38%) > @ _ 8.364.101 ?s (694916, 7,00%) > @ _ 9.758.118 ?s (593103, 5,98%) > @ _ 11.152.134 ?s (715708, 7,21%) ^50% > @ _ 12.546.151 ?s (769548, 7,76%) > @ _ 13.940.168 ?s (739466, 7,45%) > @ _ 15.334.185 ?s (854111, 8,61%) > @ _ 16.728.202 ?s (739780, 7,46%) > @ _ 18.122.219 ?s (584904, 5,90%) ^85% > > > WTF is going on here?! Could be that your current settings are too small for the load you're imposing, so either the client or the server cannot keep up. You may need to typically increase the number of threads or the number of selectors. Other explanations could be full gcs, swapping, huge pages recycling, etc. I did not need much load to trigger the Shenandoah failure, so perhaps stay low on the load (batch size = 10 or decrement it down to 1 even), and make the runs longer (batch count = 1_000 -> 100_000). -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From simone.bordet at gmail.com Mon Apr 8 13:02:34 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 15:02:34 +0200 Subject: Troubles with Shenandoah In-Reply-To: <46181acf14f624fe5f9321d49d8c9901d0265a3c.camel@redhat.com> References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> <46181acf14f624fe5f9321d49d8c9901d0265a3c.camel@redhat.com> Message-ID: Hi, On Mon, Apr 8, 2019 at 2:58 PM Roman Kennke wrote: > Yes. I see it interrupting with any GC if I run with enough clients > (e.g. they all fail with 9000 clients). Depending on settings, this may > fail earlier. > > This appears to be an overloading problem, isn't it? Or is overloading > by cranking up client count not the problem that you have? Yes, you could fail the run by overloading it. I would recommend you stay on default values for everything, except for the batch count, which controls the run length in time, that you want to increase from 1_000 to 10_000 (~2 mins) or even larger. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From simone.bordet at gmail.com Mon Apr 8 13:04:03 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 15:04:03 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> <46181acf14f624fe5f9321d49d8c9901d0265a3c.camel@redhat.com> Message-ID: Roman, did you get crashes with fastdebug? My setting for the server is -Xmx48g, could it be related to compressed (or not) oops? -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From rkennke at redhat.com Mon Apr 8 13:06:08 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 15:06:08 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> <46181acf14f624fe5f9321d49d8c9901d0265a3c.camel@redhat.com> Message-ID: > did you get crashes with fastdebug? Not yet. > My setting for the server is -Xmx48g, could it be related to > compressed (or not) oops? Don't know yet. As long as I couldn't reproduce it, it could be anything. :-) Roman From rkennke at redhat.com Mon Apr 8 13:48:18 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 15:48:18 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: > I did not need much load to trigger the Shenandoah failure, so > perhaps > stay low on the load (batch size = 10 or decrement it down to 1 > even), > and make the runs longer (batch count = 1_000 -> 100_000). Ok, I got it to fail with 20000 batch count. I currently suspect that it's running out of code cache, and drops back to interpreter. -XX:ReservedCodeCacheSize=2048m seems to fix it for me. Can you verify it? Not sure why code cache would not be cleaned though. We'll look into that. Thanks, Roman From simone.bordet at gmail.com Mon Apr 8 13:59:26 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 15:59:26 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: Roman, On Mon, Apr 8, 2019 at 3:48 PM Roman Kennke wrote: > > > I did not need much load to trigger the Shenandoah failure, so > > perhaps > > stay low on the load (batch size = 10 or decrement it down to 1 > > even), > > and make the runs longer (batch count = 1_000 -> 100_000). > > Ok, I got it to fail with 20000 batch count. > > I currently suspect that it's running out of code cache, and drops back > to interpreter. -XX:ReservedCodeCacheSize=2048m seems to fix it for me. > Can you verify it? Just had another crash with fastdebug and -XX:ReservedCodeCacheSize=2048m, attached the hs_err. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From shade at redhat.com Mon Apr 8 14:13:29 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 16:13:29 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: On 4/8/19 3:59 PM, Simone Bordet wrote: >> I currently suspect that it's running out of code cache, and drops back >> to interpreter. -XX:ReservedCodeCacheSize=2048m seems to fix it for me. >> Can you verify it? > > Just had another crash with fastdebug and > -XX:ReservedCodeCacheSize=2048m, attached the hs_err. # fatal error: Safepoint sync time longer than 10000ms detected when executing Cleanup. jdk/jdk has the code that SIGILLs the thread that failed to reach the safepoint, and thus provides better diagnostics than this. -Aleksey From rkennke at redhat.com Mon Apr 8 14:19:41 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 16:19:41 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: I don't see the issue with latest code: Can you try: https://builds.shipilev.net/openjdk-jdk/ and see if that works better for you? I'll check out fastdebug build in the meantime and see what's up there. Roman >Am Montag, den 08.04.2019, 15:59 +0200 schrieb Simone Bordet: > Roman, > > On Mon, Apr 8, 2019 at 3:48 PM Roman Kennke > wrote: > > > I did not need much load to trigger the Shenandoah failure, so > > > perhaps > > > stay low on the load (batch size = 10 or decrement it down to 1 > > > even), > > > and make the runs longer (batch count = 1_000 -> 100_000). > > > > Ok, I got it to fail with 20000 batch count. > > > > I currently suspect that it's running out of code cache, and drops > > back > > to interpreter. -XX:ReservedCodeCacheSize=2048m seems to fix it for > > me. > > Can you verify it? > > Just had another crash with fastdebug and > -XX:ReservedCodeCacheSize=2048m, attached the hs_err. > From simone.bordet at gmail.com Mon Apr 8 14:34:45 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 16:34:45 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: Hi, On Mon, Apr 8, 2019 at 4:19 PM Roman Kennke wrote: > > I don't see the issue with latest code: > > Can you try: > https://builds.shipilev.net/openjdk-jdk/ > > and see if that works better for you? I get an immediate crash even before starting the run. Attached hs_err. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From simone.bordet at gmail.com Mon Apr 8 14:44:33 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 16:44:33 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: Hi, On Mon, Apr 8, 2019 at 4:34 PM Simone Bordet wrote: > I get an immediate crash even before starting the run. > Attached hs_err. There is also a file `replay_pid25995.log`. Same pid as the crash, is that relevant? Attaching it in any case. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From rkennke at redhat.com Mon Apr 8 14:44:16 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 16:44:16 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: Wow. that is weird. It works flawlessly for me, even with fastdebug build. However, that assert should be harmless. You could try the -release build and see if that works. I'll try to get the fastdebug build to fail in the meantime. Roman > Am Montag, den 08.04.2019, 16:34 +0200 schrieb Simone Bordet: > Hi, > > On Mon, Apr 8, 2019 at 4:19 PM Roman Kennke > wrote: > > I don't see the issue with latest code: > > > > Can you try: > > https://builds.shipilev.net/openjdk-jdk/ > > > > and see if that works better for you? > > I get an immediate crash even before starting the run. > Attached hs_err. > From shade at redhat.com Mon Apr 8 14:46:30 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 16:46:30 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: On 4/8/19 4:34 PM, Simone Bordet wrote: > On Mon, Apr 8, 2019 at 4:19 PM Roman Kennke wrote: >> >> I don't see the issue with latest code: >> >> Can you try: >> https://builds.shipilev.net/openjdk-jdk/ >> >> and see if that works better for you? > > I get an immediate crash even before starting the run. > Attached hs_err. This is the failing block: #ifdef ASSERT tty->print_cr("Unknown node in get_barrier_strength:"); n->dump(1); ShouldNotReachHere(); #else ...so your console output should have listed the node that was not covered by the switch in that file. -Aleksey From rkennke at redhat.com Mon Apr 8 14:46:39 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 16:46:39 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> Message-ID: <53e2e1f8f86803988019a8bbd8a5e46bf3bc911e.camel@redhat.com> Yeah, might be interesting. Do you see anything printed to stderr or stdout by the application before crashing? That would be interesting. Roman > Hi, > > On Mon, Apr 8, 2019 at 4:34 PM Simone Bordet > wrote: > > I get an immediate crash even before starting the run. > > Attached hs_err. > > There is also a file `replay_pid25995.log`. Same pid as the crash, is > that relevant? > Attaching it in any case. > From simone.bordet at gmail.com Mon Apr 8 14:50:33 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 16:50:33 +0200 Subject: Troubles with Shenandoah In-Reply-To: <53e2e1f8f86803988019a8bbd8a5e46bf3bc911e.camel@redhat.com> References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> <7e136b0a-b3ec-3bd6-be89-fe0ebb45d3a4@redhat.com> <53e2e1f8f86803988019a8bbd8a5e46bf3bc911e.camel@redhat.com> Message-ID: Hi, On Mon, Apr 8, 2019 at 4:46 PM Roman Kennke wrote: > > Yeah, might be interesting. Do you see anything printed to stderr or > stdout by the application before crashing? That would be interesting. Attached. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From rkennke at redhat.com Mon Apr 8 15:50:47 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 17:50:47 +0200 Subject: RFR: JDK-8222129: Shenandoah: Missing CompareAndSwapP/N case in get_barrier_strength() Message-ID: <489fc47bfc70f844321e193aea7ffe627d0aa92c.camel@redhat.com> Missing case CompareAndSwapN/P in get_barrier_strength() trips as assert in shenadoahSupport.cpp. Bug: https://bugs.openjdk.java.net/browse/JDK-8222129 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8222129/webrev.00/ Testing: hotspot_gc_shenandoah Ok? From rkennke at redhat.com Mon Apr 8 15:54:15 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 17:54:15 +0200 Subject: RFR: JDK-8222125: Shenandoah: Crash when running with ShenandoahParallelSafepointThreads=1 Message-ID: Apparently, we're unconditionally calling: _safepoint_workers->threads_do(tcl); however, _safepoint_workers may legally be NULL, when ShenandoahParallelSafepointThreasds=1. Bug: https://bugs.openjdk.java.net/browse/JDK-8222125 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8222125/webrev.00/ Testing: hotspot_gc_shenandoah Ok? Roman From shade at redhat.com Mon Apr 8 15:54:29 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 17:54:29 +0200 Subject: RFR: JDK-8222129: Shenandoah: Missing CompareAndSwapP/N case in get_barrier_strength() In-Reply-To: <489fc47bfc70f844321e193aea7ffe627d0aa92c.camel@redhat.com> References: <489fc47bfc70f844321e193aea7ffe627d0aa92c.camel@redhat.com> Message-ID: On 4/8/19 5:50 PM, Roman Kennke wrote: > Missing case CompareAndSwapN/P in get_barrier_strength() trips as > assert in shenadoahSupport.cpp. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8222129 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8222129/webrev.00/ Case labels should be closer to other CompareAndSwaps, I think? 3132 case Op_CompareAndSwapL: 3133 case Op_CompareAndSwapI: 3134 case Op_CompareAndSwapB: 3135 case Op_CompareAndSwapS: // should be here? 3136 case Op_ShenandoahCompareAndSwapN: 3137 case Op_ShenandoahCompareAndSwapP: 3138 case Op_ShenandoahWeakCompareAndSwapN: 3139 case Op_ShenandoahWeakCompareAndSwapP: 3140 case Op_ShenandoahCompareAndExchangeN: 3141 case Op_ShenandoahCompareAndExchangeP: 3142 case Op_CompareAndSwapN: // they are here 3143 case Op_CompareAndSwapP: CompareAndExchangeP/N are not affected by this? -Aleksey From rkennke at redhat.com Mon Apr 8 15:55:45 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 17:55:45 +0200 Subject: RFR: JDK-8222129: Shenandoah: Missing CompareAndSwapP/N case in get_barrier_strength() In-Reply-To: References: <489fc47bfc70f844321e193aea7ffe627d0aa92c.camel@redhat.com> Message-ID: <2e36c3e6d0fbcd87eb56090bcf9aa59bcc39c7be.camel@redhat.com> Am Montag, den 08.04.2019, 17:54 +0200 schrieb Aleksey Shipilev: > On 4/8/19 5:50 PM, Roman Kennke wrote: > > Missing case CompareAndSwapN/P in get_barrier_strength() trips as > > assert in shenadoahSupport.cpp. > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8222129 > > Webrev: > > http://cr.openjdk.java.net/~rkennke/JDK-8222129/webrev.00/ > > Case labels should be closer to other CompareAndSwaps, I think? Dunno. I put them closer to other non-Shenandoah* cases ;-) Roman > 3132 case Op_CompareAndSwapL: > 3133 case Op_CompareAndSwapI: > 3134 case Op_CompareAndSwapB: > 3135 case Op_CompareAndSwapS: > // should be here? > 3136 case Op_ShenandoahCompareAndSwapN: > 3137 case Op_ShenandoahCompareAndSwapP: > 3138 case Op_ShenandoahWeakCompareAndSwapN: > 3139 case Op_ShenandoahWeakCompareAndSwapP: > 3140 case Op_ShenandoahCompareAndExchangeN: > 3141 case Op_ShenandoahCompareAndExchangeP: > 3142 case Op_CompareAndSwapN: // they are here > 3143 case Op_CompareAndSwapP: > > CompareAndExchangeP/N are not affected by this? > > -Aleksey > From shade at redhat.com Mon Apr 8 15:58:28 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 17:58:28 +0200 Subject: RFR: JDK-8222125: Shenandoah: Crash when running with ShenandoahParallelSafepointThreads=1 In-Reply-To: References: Message-ID: On 4/8/19 5:54 PM, Roman Kennke wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8222125 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8222125/webrev.00/ Looks fine. Would you mind adding a simple "options" test, for example by copy-pastng gc/shenandoah/options/TestAlwaysPreTouch.java, or maybe TestParallelRegionStride, if it needs to have at least one GC cycle to expose the bug. Thanks, -Aleksey From shade at redhat.com Mon Apr 8 16:00:41 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 18:00:41 +0200 Subject: RFR: JDK-8222129: Shenandoah: Missing CompareAndSwapP/N case in get_barrier_strength() In-Reply-To: <2e36c3e6d0fbcd87eb56090bcf9aa59bcc39c7be.camel@redhat.com> References: <489fc47bfc70f844321e193aea7ffe627d0aa92c.camel@redhat.com> <2e36c3e6d0fbcd87eb56090bcf9aa59bcc39c7be.camel@redhat.com> Message-ID: <3ca7b4fa-0839-d2cc-e070-b30489580dd1@redhat.com> On 4/8/19 5:55 PM, Roman Kennke wrote: > Am Montag, den 08.04.2019, 17:54 +0200 schrieb Aleksey Shipilev: >> On 4/8/19 5:50 PM, Roman Kennke wrote: >>> Missing case CompareAndSwapN/P in get_barrier_strength() trips as >>> assert in shenadoahSupport.cpp. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8222129 >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8222129/webrev.00/ >> >> Case labels should be closer to other CompareAndSwaps, I think? > > Dunno. I put them closer to other non-Shenandoah* cases ;-) Yes, so Op_CompareAndSwap{L,I,B,S} _are_ those non-Shenandoah CAS cases ;) >> 3132 case Op_CompareAndSwapL: >> 3133 case Op_CompareAndSwapI: >> 3134 case Op_CompareAndSwapB: >> 3135 case Op_CompareAndSwapS: >> // should be here? >> 3136 case Op_ShenandoahCompareAndSwapN: >> 3137 case Op_ShenandoahCompareAndSwapP: >> 3138 case Op_ShenandoahWeakCompareAndSwapN: >> 3139 case Op_ShenandoahWeakCompareAndSwapP: >> 3140 case Op_ShenandoahCompareAndExchangeN: >> 3141 case Op_ShenandoahCompareAndExchangeP: >> 3142 case Op_CompareAndSwapN: // they are here >> 3143 case Op_CompareAndSwapP: ... >> CompareAndExchangeP/N are not affected by this? Right? -Aleksey From shade at redhat.com Mon Apr 8 16:08:09 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 18:08:09 +0200 Subject: RFR (S) 8222130: Shenandoah should verify roots after pre-evacuation Message-ID: <83c8f7cc-3aa3-4340-8ef0-9f785bc72f7d@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8222130 Shenandoah verifier usually does the checks when the pause is over, and everything is done. One notable exception is evacuation path, where we do the verify_before_evacuation() check, then pre-evac the roots, and unblock. We need to check those roots are still fine after pre-evac by doing another verification step. Fix: http://cr.openjdk.java.net/~shade/8222130/wevrev.01/ Testing: Linux x86_64 fastdebug hotspot_gc_shenandoah -Aleksey From gnu.andrew at redhat.com Mon Apr 8 16:07:32 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 8 Apr 2019 17:07:32 +0100 Subject: [RFR] [8u] 8u202 Upstream Sync In-Reply-To: References: <01082237-f8fb-40bf-3615-a2a3e790bbfb@redhat.com> Message-ID: <65d545ab-0266-f293-80c9-418208c3008d@redhat.com> On 08/04/2019 10:11, Aleksey Shipilev wrote: > On 4/8/19 6:53 AM, Andrew John Hughes wrote: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/corba/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/jaxp/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/jaxws/merge.changeset > > Looks trivially fine. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/jdk/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/hotspot/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/langtools/merge.changeset > > Looks fine. Hotspot/Shenandoah changes would need to be tested right after the integration, I think. > They look fine, but might surprise us. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/nashorn/merge.changeset > > Looks trivially fine. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u202/root/merge.changeset > > Looks fine. > > Thumbs up. > > -Aleksey > Thanks. Pushed. The only merge issue was in hotspot/src/share/vm/opto/library_call.cpp, where a conditional is inverted: - if (type != T_OBJECT ) { - (void) store_to_memory(control(), adr, val, type, adr_type, mo, is_volatile, unaligned, mismatched); + if (type == T_OBJECT ) { + val = shenandoah_read_barrier_storeval(val); + (void) store_oop_to_unknown(control(), heap_base_oop, adr, adr_type, val, type, mo, mismatched); } else { - // Possibly an oop being stored to Java heap or native memory - if (!can_access_non_heap) { - // oop to Java heap. - val = shenandoah_read_barrier_storeval(val); - (void) store_oop_to_unknown(control(), heap_base_oop, adr, adr_type, val, type, mo, mismatched); - } else { - // We can't tell at compile time if we are storing in the Java heap or outside - // of it. So we need to emit code to conditionally do the proper type of - // store. - - IdealKit ideal(this); -#define __ ideal. - // QQQ who knows what probability is here?? - __ if_then(heap_base_oop, BoolTest::ne, null(), PROB_UNLIKELY(0.999)); { - // Sync IdealKit and graphKit. - sync_kit(ideal); - Node* rb = shenandoah_read_barrier_storeval(val); - Node* st = store_oop_to_unknown(control(), heap_base_oop, adr, adr_type, rb, type, mo, mismatched); - // Update IdealKit memory. - __ sync_kit(this); - } __ else_(); { - __ store(__ ctrl(), adr, val, type, alias_type->index(), mo, is_volatile, mismatched); - } __ end_if(); - // Final sync IdealKit and GraphKit. - final_sync(ideal); -#undef __ - } + (void) store_to_memory(control(), adr, val, type, adr_type, mo, is_volatile, unaligned, mismatched); so I moved the val = shenandoah_read_barrier_storeval(val) with the store_oop_to_unknown it previously guarded. The other Node *rb = shenandoah_read_barrier_storeval(val) was discarded along with the rest of that else block. This is part of 8155635: C2: Mixed unsafe accesses break alias analysis. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Mon Apr 8 16:12:46 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 18:12:46 +0200 Subject: [RFR] [8u] 8u202 Upstream Sync In-Reply-To: <65d545ab-0266-f293-80c9-418208c3008d@redhat.com> References: <01082237-f8fb-40bf-3615-a2a3e790bbfb@redhat.com> <65d545ab-0266-f293-80c9-418208c3008d@redhat.com> Message-ID: <118e1dc9-66eb-62bb-b03c-7bd75aa53767@redhat.com> On 4/8/19 6:07 PM, Andrew John Hughes wrote: > so I moved the val = shenandoah_read_barrier_storeval(val) with the > store_oop_to_unknown it previously guarded. The other Node *rb = > shenandoah_read_barrier_storeval(val) was discarded along with the rest > of that else block. > > This is part of 8155635: C2: Mixed unsafe accesses break alias analysis. Yes, I figured as much. I think that merge was correct. Testing would show how wrong we are about assuming stuff in C2 :) I kicked off the test run. -Aleksey From rkennke at redhat.com Mon Apr 8 16:12:49 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 18:12:49 +0200 Subject: RFR: JDK-8222125: Shenandoah: Crash when running with ShenandoahParallelSafepointThreads=1 In-Reply-To: References: Message-ID: > On 4/8/19 5:54 PM, Roman Kennke wrote: > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8222125 > > Webrev: > > http://cr.openjdk.java.net/~rkennke/JDK-8222125/webrev.00/ > > Looks fine. > > Would you mind adding a simple "options" test, for example by copy- > pastng > gc/shenandoah/options/TestAlwaysPreTouch.java, or maybe > TestParallelRegionStride, if it needs to > have at least one GC cycle to expose the bug. Right. Like this? http://cr.openjdk.java.net/~rkennke/JDK-8222125/webrev.01/ It fails without and passes with the change. Roman From rkennke at redhat.com Mon Apr 8 16:15:33 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 18:15:33 +0200 Subject: RFR: JDK-8222129: Shenandoah: Missing CompareAndSwapP/N case in get_barrier_strength() In-Reply-To: <3ca7b4fa-0839-d2cc-e070-b30489580dd1@redhat.com> References: <489fc47bfc70f844321e193aea7ffe627d0aa92c.camel@redhat.com> <2e36c3e6d0fbcd87eb56090bcf9aa59bcc39c7be.camel@redhat.com> <3ca7b4fa-0839-d2cc-e070-b30489580dd1@redhat.com> Message-ID: <572e324c131577db83c039a8e47ba55fb8beb72f.camel@redhat.com> > On 4/8/19 5:55 PM, Roman Kennke wrote: > > Am Montag, den 08.04.2019, 17:54 +0200 schrieb Aleksey Shipilev: > > > On 4/8/19 5:50 PM, Roman Kennke wrote: > > > > Missing case CompareAndSwapN/P in get_barrier_strength() trips > > > > as > > > > assert in shenadoahSupport.cpp. > > > > > > > > Bug: > > > > https://bugs.openjdk.java.net/browse/JDK-8222129 > > > > Webrev: > > > > http://cr.openjdk.java.net/~rkennke/JDK-8222129/webrev.00/ > > > > > > Case labels should be closer to other CompareAndSwaps, I think? > > > > Dunno. I put them closer to other non-Shenandoah* cases ;-) > > Yes, so Op_CompareAndSwap{L,I,B,S} _are_ those non-Shenandoah CAS > cases ;) > Ha, right: http://cr.openjdk.java.net/~rkennke/JDK-8222129/webrev.01/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp.udiff.html Good now? Roman > > > 3132 case Op_CompareAndSwapL: > > > 3133 case Op_CompareAndSwapI: > > > 3134 case Op_CompareAndSwapB: > > > 3135 case Op_CompareAndSwapS: > > > // should be here? > > > 3136 case Op_ShenandoahCompareAndSwapN: > > > 3137 case Op_ShenandoahCompareAndSwapP: > > > 3138 case Op_ShenandoahWeakCompareAndSwapN: > > > 3139 case Op_ShenandoahWeakCompareAndSwapP: > > > 3140 case Op_ShenandoahCompareAndExchangeN: > > > 3141 case Op_ShenandoahCompareAndExchangeP: > > > 3142 case Op_CompareAndSwapN: // they are here > > > 3143 case Op_CompareAndSwapP: > > ... > > > > CompareAndExchangeP/N are not affected by this? > > Right? > > -Aleksey > From shade at redhat.com Mon Apr 8 16:15:29 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 18:15:29 +0200 Subject: RFR: JDK-8222125: Shenandoah: Crash when running with ShenandoahParallelSafepointThreads=1 In-Reply-To: References: Message-ID: <1fc56bf5-2bea-4b1d-2799-cf806737b40f@redhat.com> On 4/8/19 6:12 PM, Roman Kennke wrote: >> On 4/8/19 5:54 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/JDK-8222125/webrev.01/ Yes. Just make it more generic? E.g. TestSafepointWorkers.java with two cases, "-XX:ShPST=1" and "-XX:ShPST=2". Thanks, -Aleksey From shade at redhat.com Mon Apr 8 16:16:18 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 18:16:18 +0200 Subject: RFR: JDK-8222129: Shenandoah: Missing CompareAndSwapP/N case in get_barrier_strength() In-Reply-To: <572e324c131577db83c039a8e47ba55fb8beb72f.camel@redhat.com> References: <489fc47bfc70f844321e193aea7ffe627d0aa92c.camel@redhat.com> <2e36c3e6d0fbcd87eb56090bcf9aa59bcc39c7be.camel@redhat.com> <3ca7b4fa-0839-d2cc-e070-b30489580dd1@redhat.com> <572e324c131577db83c039a8e47ba55fb8beb72f.camel@redhat.com> Message-ID: <5b8e64f5-9316-715c-670d-993b46f8fbb6@redhat.com> On 4/8/19 6:15 PM, Roman Kennke wrote: > Ha, right: > http://cr.openjdk.java.net/~rkennke/JDK-8222129/webrev.01/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp.udiff.html Yes, looks good. -Aleksey From rkennke at redhat.com Mon Apr 8 16:27:25 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 18:27:25 +0200 Subject: RFR: JDK-8222125: Shenandoah: Crash when running with ShenandoahParallelSafepointThreads=1 In-Reply-To: <1fc56bf5-2bea-4b1d-2799-cf806737b40f@redhat.com> References: <1fc56bf5-2bea-4b1d-2799-cf806737b40f@redhat.com> Message-ID: <1ffd07cafdad0fa9bfd899c6494261f120fb1cfa.camel@redhat.com> > On 4/8/19 6:12 PM, Roman Kennke wrote: > > > On 4/8/19 5:54 PM, Roman Kennke wrote: > > http://cr.openjdk.java.net/~rkennke/JDK-8222125/webrev.01/ > > Yes. Just make it more generic? E.g. TestSafepointWorkers.java with > two cases, "-XX:ShPST=1" and > "-XX:ShPST=2". > Good point. http://cr.openjdk.java.net/~rkennke/JDK-8222125/webrev.02/ Ok? Roman From rkennke at redhat.com Mon Apr 8 16:28:11 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 18:28:11 +0200 Subject: RFR (S) 8222130: Shenandoah should verify roots after pre-evacuation In-Reply-To: <83c8f7cc-3aa3-4340-8ef0-9f785bc72f7d@redhat.com> References: <83c8f7cc-3aa3-4340-8ef0-9f785bc72f7d@redhat.com> Message-ID: <30b0200513193d4a36b74a2c0b7754291a9088b7.camel@redhat.com> > RFE: > https://bugs.openjdk.java.net/browse/JDK-8222130 > > Shenandoah verifier usually does the checks when the pause is over, > and everything is done. One > notable exception is evacuation path, where we do the > verify_before_evacuation() check, then > pre-evac the roots, and unblock. We need to check those roots are > still fine after pre-evac by doing > another verification step. > > Fix: > http://cr.openjdk.java.net/~shade/8222130/wevrev.01/ > > Testing: Linux x86_64 fastdebug hotspot_gc_shenandoah Looks good! Thanks! Roman From shade at redhat.com Mon Apr 8 16:29:10 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 18:29:10 +0200 Subject: RFR: JDK-8222125: Shenandoah: Crash when running with ShenandoahParallelSafepointThreads=1 In-Reply-To: <1ffd07cafdad0fa9bfd899c6494261f120fb1cfa.camel@redhat.com> References: <1fc56bf5-2bea-4b1d-2799-cf806737b40f@redhat.com> <1ffd07cafdad0fa9bfd899c6494261f120fb1cfa.camel@redhat.com> Message-ID: On 4/8/19 6:27 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/JDK-8222125/webrev.02/ Nice, good to go. Consider eliminating excess white-space here before pushing: "-XX:ShenandoahParallelSafepointThreads=1 -Xmx128m" -Aleksey From zgu at redhat.com Mon Apr 8 16:54:01 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 8 Apr 2019 12:54:01 -0400 Subject: RFR(T) 8222086: CodeCache::UnloadingScope needs to preserve and restore previous IsUnloadingBehavior In-Reply-To: References: <4aee03db-ad25-23b9-04a9-1c4c72f7165c@redhat.com> Message-ID: Thank you, Erik. -Zhengyu On 4/8/19 8:58 AM, Erik ?sterlund wrote: > Hi Zhengyu, > > Looks good. > > /Erik > > On 2019-04-08 02:57, Zhengyu Gu wrote: >> Shenandoah can (will) do concurrent class unloading, but also unloads >> classes at pauses, e.g. during full gc. >> >> Currently, CodeCache::UnloadingScope's destructor resets >> IsUnloadingBehaviour that is setup for concurrent class unloading, >> which results fatal crash during next concurrent unloading cycle. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222086 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222086/webrev.00/ >> >> >> Test: >> ? hotspot_gc on Linux x64 (fastdebug and release) >> ? Submit tests. >> >> Thanks, >> >> -Zhengyu > From zgu at redhat.com Mon Apr 8 17:42:21 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 8 Apr 2019 13:42:21 -0400 Subject: RFR (S) 8222130: Shenandoah should verify roots after pre-evacuation In-Reply-To: <83c8f7cc-3aa3-4340-8ef0-9f785bc72f7d@redhat.com> References: <83c8f7cc-3aa3-4340-8ef0-9f785bc72f7d@redhat.com> Message-ID: <24374fa8-6a50-b4e3-889e-3d148a25702e@redhat.com> Looks good. -Zhengyu On 4/8/19 12:08 PM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8222130 > > Shenandoah verifier usually does the checks when the pause is over, and everything is done. One > notable exception is evacuation path, where we do the verify_before_evacuation() check, then > pre-evac the roots, and unblock. We need to check those roots are still fine after pre-evac by doing > another verification step. > > Fix: > http://cr.openjdk.java.net/~shade/8222130/wevrev.01/ > > Testing: Linux x86_64 fastdebug hotspot_gc_shenandoah > > -Aleksey > From shade at redhat.com Mon Apr 8 18:31:48 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 20:31:48 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: Message-ID: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> On 4/7/19 2:41 PM, Simone Bordet wrote: > I will happily re-run the benchmark with your suggestions. After running the benchmark myself, at least one trouble I see is here: > -XX:InitialHeapSize=17179869184 -XX:MaxHeapSize=51539607552 > -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 > -XX:+SegmentedCodeCache -XX:+UnlockExperimentalVMOptions > -XX:+UseShenandoahGC The benchmark calls System.gc() between benchmark rounds, which uncommits almost entire Shenandoah heap, which is intentional, because Shenandoah treats System.gc() as the command to compact the heap as densely as possible. But this also means the next benchmarking round has to commit all that memory back. This gives you the latency hit, which probably manifests as timeouts/lost packets too? The timing distribution had improved very significantly after either -XX:-ShenandoahUncommit or -XX:+AlwaysPreTouch is supplied. For comparison across GCs and OSes that have different takes on heap management, I would run with "-Xms${H}g -Xmx${H}g -XX:+AlwaysPreTouch" to stick the heap at max capacity and wired up at all times. This advice applies to Shenandoah [1], as well as other OpenJDK collectors. I also note the workload is fully-young, so differences between current GCs would probably be small. -Aleksey [1] See "Other recommended JVM options": https://wiki.openjdk.java.net/display/shenandoah/Main#Main-PerformanceGuidelinesandDiagnostics From rkennke at redhat.com Mon Apr 8 19:01:17 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 21:01:17 +0200 Subject: Troubles with Shenandoah In-Reply-To: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> Message-ID: This seems particularily bad, considering that this benchmark doesn't seem to do very much allocations to begin with. I can run it with 16GB without significant GC activity, I suspect it can easily run in 8GB or 4GB and actual GC still wouldn't matter much. Running it in several dozens of GB seems not useful. Roman > On 4/7/19 2:41 PM, Simone Bordet wrote: > > I will happily re-run the benchmark with your suggestions. > > After running the benchmark myself, at least one trouble I see is > here: > > > -XX:InitialHeapSize=17179869184 -XX:MaxHeapSize=51539607552 > > -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 > > -XX:+SegmentedCodeCache -XX:+UnlockExperimentalVMOptions > > -XX:+UseShenandoahGC > > The benchmark calls System.gc() between benchmark rounds, which > uncommits almost entire Shenandoah > heap, which is intentional, because Shenandoah treats System.gc() as > the command to compact the heap > as densely as possible. But this also means the next benchmarking > round has to commit all that > memory back. This gives you the latency hit, which probably manifests > as timeouts/lost packets too? > The timing distribution had improved very significantly after either > -XX:-ShenandoahUncommit or > -XX:+AlwaysPreTouch is supplied. > > For comparison across GCs and OSes that have different takes on heap > management, I would run with > "-Xms${H}g -Xmx${H}g -XX:+AlwaysPreTouch" to stick the heap at max > capacity and wired up at all > times. This advice applies to Shenandoah [1], as well as other > OpenJDK collectors. > > I also note the workload is fully-young, so differences between > current GCs would probably be small. > > -Aleksey > > [1] See "Other recommended JVM options": > https://wiki.openjdk.java.net/display/shenandoah/Main#Main-PerformanceGuidelinesandDiagnostics > From shade at redhat.com Mon Apr 8 19:11:01 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 21:11:01 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> Message-ID: <386e1b79-f864-b422-d786-a0b4d146b635@redhat.com> On 4/8/19 9:01 PM, Roman Kennke wrote: > This seems particularily bad, considering that this benchmark doesn't > seem to do very much allocations to begin with. I can run it with 16GB > without significant GC activity, I suspect it can easily run in 8GB or > 4GB and actual GC still wouldn't matter much. Running it in several > dozens of GB seems not useful. +1. I managed to run the workload in 1G heap with Shenandoah, with only some minor loss in latency. Larger heaps would be beneficial for concurrent collectors anyway, as they would do less cycles. But that would probably not matter past some decently sized heap, because the cycles themselves are short, given the workload is mostly-young. -Aleksey From simone.bordet at gmail.com Mon Apr 8 19:21:57 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 21:21:57 +0200 Subject: Troubles with Shenandoah In-Reply-To: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> Message-ID: Hi, On Mon, Apr 8, 2019 at 8:31 PM Aleksey Shipilev wrote: > > On 4/7/19 2:41 PM, Simone Bordet wrote: > > I will happily re-run the benchmark with your suggestions. > > After running the benchmark myself, at least one trouble I see is here: > > > -XX:InitialHeapSize=17179869184 -XX:MaxHeapSize=51539607552 > > -XX:+PrintCommandLineFlags -XX:ReservedCodeCacheSize=251658240 > > -XX:+SegmentedCodeCache -XX:+UnlockExperimentalVMOptions > > -XX:+UseShenandoahGC > > The benchmark calls System.gc() between benchmark rounds, which uncommits almost entire Shenandoah > heap, which is intentional, because Shenandoah treats System.gc() as the command to compact the heap > as densely as possible. But this also means the next benchmarking round has to commit all that > memory back. This gives you the latency hit, which probably manifests as timeouts/lost packets too? Timeouts and lost packets would only happen if the latency/pause is quite long, 5+ seconds. Could recommitting the memory cause pauses this long? With the default configuration and at least 2 GiB of heap, I expect the failures to be very unlikely, especially if there is no network (e.g. run via loopback). > The timing distribution had improved very significantly after either -XX:-ShenandoahUncommit or > -XX:+AlwaysPreTouch is supplied. Nice. > For comparison across GCs and OSes that have different takes on heap management, I would run with > "-Xms${H}g -Xmx${H}g -XX:+AlwaysPreTouch" to stick the heap at max capacity and wired up at all > times. This advice applies to Shenandoah [1], as well as other OpenJDK collectors. Thanks for this tip. > I also note the workload is fully-young, so differences between current GCs would probably be small. Indeed. The client connections and session objects are long lived, so the case is a lot of objects that die young, referenced by objects that are long lived. Not explicitly a GC benchmark, but for me just a litmus test for the JVM behavior (GC, JIT, etc.) as well as Jetty and CometD behavior. The benchmark is pretty close to a real application (rather than being synthetic code) and we use it to flamegraph Jetty, CometD, etc. It's what I had handy :) -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From shade at redhat.com Mon Apr 8 19:27:53 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 21:27:53 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> Message-ID: <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> On 4/8/19 9:21 PM, Simone Bordet wrote: > On Mon, Apr 8, 2019 at 8:31 PM Aleksey Shipilev wrote: >> On 4/7/19 2:41 PM, Simone Bordet wrote: >> The benchmark calls System.gc() between benchmark rounds, which uncommits almost entire Shenandoah >> heap, which is intentional, because Shenandoah treats System.gc() as the command to compact the heap >> as densely as possible. But this also means the next benchmarking round has to commit all that >> memory back. This gives you the latency hit, which probably manifests as timeouts/lost packets too? > > Timeouts and lost packets would only happen if the latency/pause is > quite long, 5+ seconds. > Could recommitting the memory cause pauses this long? Yes. Here's a taste when nothing else is happening, and only memory commit is done: $ time java -Xms100g -Xmx100g -XX:+AlwaysPreTouch -XX:+UseSerialGC -version openjdk version "13-internal" 2019-09-17 OpenJDK Runtime Environment (build 13-internal+0-adhoc.shade.jdk-jdk) OpenJDK 64-Bit Server VM (build 13-internal+0-adhoc.shade.jdk-jdk, mixed mode) real 0m33.461s user 0m4.733s sys 0m28.600s ...when other things happen concurrently, the whole thing might take a while to satisfy even a small one-off request. >> I also note the workload is fully-young, so differences between current GCs would probably be small. > > Indeed. The client connections and session objects are long lived, so > the case is a lot of objects that die young, referenced by objects > that are long lived. Yes. Just don't be surprised when concurrent collectors do not give the latency boost there :) -- Thanks, -Aleksey From simone.bordet at gmail.com Mon Apr 8 19:32:06 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 21:32:06 +0200 Subject: Troubles with Shenandoah In-Reply-To: <386e1b79-f864-b422-d786-a0b4d146b635@redhat.com> References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <386e1b79-f864-b422-d786-a0b4d146b635@redhat.com> Message-ID: Hi, On Mon, Apr 8, 2019 at 9:11 PM Aleksey Shipilev wrote: > > On 4/8/19 9:01 PM, Roman Kennke wrote: > > This seems particularily bad, considering that this benchmark doesn't > > seem to do very much allocations to begin with. I can run it with 16GB > > without significant GC activity, I suspect it can easily run in 8GB or > > 4GB and actual GC still wouldn't matter much. Running it in several > > dozens of GB seems not useful. > > +1. > > I managed to run the workload in 1G heap with Shenandoah, with only some minor loss in latency. > Larger heaps would be beneficial for concurrent collectors anyway, as they would do fewer cycles. But > that would probably not matter past some decently sized heap, because the cycles themselves are > short, given the workload is mostly-young. I agree with your observations: with default configuration and 1 client machine (or same machine) the load is not much. I am actually running this benchmark with 4 client machines against 1 server. With my configuration, I saw 10-20 ms pauses in ZGC due to allocation stalls with 2 GiB heap on the server. I expect Shenandoah to have similar behavior, but have not been able to perform a full run with Shenandoah yet. All of that playing with GCs, and heap sizes, etc. to understand better these new GCs. FYI I will present them (an introductive talk - in Italian) to Voxxed Milan (https://vxdmilan2019.confinabox.com/talk/WES-2204/Concurrent_Garbage_Collectors:_ZGC_&_Shenandoah). The idea is to get people to know they exist, so they start playing with them. -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From simone.bordet at gmail.com Mon Apr 8 19:46:28 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 21:46:28 +0200 Subject: Troubles with Shenandoah In-Reply-To: <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> Message-ID: Hi, On Mon, Apr 8, 2019 at 9:28 PM Aleksey Shipilev wrote: > Yes. Here's a taste when nothing else is happening, and only memory commit is done: > > $ time java -Xms100g -Xmx100g -XX:+AlwaysPreTouch -XX:+UseSerialGC -version > openjdk version "13-internal" 2019-09-17 > OpenJDK Runtime Environment (build 13-internal+0-adhoc.shade.jdk-jdk) > OpenJDK 64-Bit Server VM (build 13-internal+0-adhoc.shade.jdk-jdk, mixed mode) > > real 0m33.461s > user 0m4.733s > sys 0m28.600s > > ...when other things happen concurrently, the whole thing might take a while to satisfy even a small > one-off request. Holy cow! > Yes. Just don't be surprised when concurrent collectors do not give the latency boost there :) I'm not expecting a median latency boost here. I actually had no expectations and was just curious as to what could have happened when running the CometD benchmark with ZGC and Shenandoah. But we have people interested in reducing max latency as much as possible, even sacrificing some throughput and median latency, so ZGC and Shenandoah are worth exploring. We (as the Jetty team) take the hit of trying these new GCs early so at least we have some knowledge when people ask us about them :) Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From rkennke at redhat.com Mon Apr 8 19:59:40 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 08 Apr 2019 21:59:40 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> Message-ID: <1389e8ffb357fb494e014c200ba80a2467422ef5.camel@redhat.com> > On Mon, Apr 8, 2019 at 9:28 PM Aleksey Shipilev > wrote: > > Yes. Here's a taste when nothing else is happening, and only memory > > commit is done: > > > > $ time java -Xms100g -Xmx100g -XX:+AlwaysPreTouch -XX:+UseSerialGC > > -version > > openjdk version "13-internal" 2019-09-17 > > OpenJDK Runtime Environment (build 13-internal+0-adhoc.shade.jdk- > > jdk) > > OpenJDK 64-Bit Server VM (build 13-internal+0-adhoc.shade.jdk-jdk, > > mixed mode) > > > > real 0m33.461s > > user 0m4.733s > > sys 0m28.600s > > > > ...when other things happen concurrently, the whole thing might > > take a while to satisfy even a small > > one-off request. > > Holy cow! > > > Yes. Just don't be surprised when concurrent collectors do not give > > the latency boost there :) > > I'm not expecting a median latency boost here. > I actually had no expectations and was just curious as to what could > have happened when running the CometD benchmark with ZGC and > Shenandoah. > > But we have people interested in reducing max latency as much as > possible, even sacrificing some throughput and median latency, so ZGC > and Shenandoah are worth exploring. > We (as the Jetty team) take the hit of trying these new GCs early so > at least we have some knowledge when people ask us about them :) > Good thing: it did uncover some bugs, even though not related to your original request: https://bugs.openjdk.java.net/browse/JDK-8222125 https://bugs.openjdk.java.net/browse/JDK-8222129 then we see a crash in C2 compiler when running the client with Shenandoah. Plus the crash that you observed with jdk12. I call that a win :-) Roman From shade at redhat.com Mon Apr 8 20:00:57 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 22:00:57 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> Message-ID: <40f3c786-0ddf-7c77-30ad-bec7c90fadf5@redhat.com> On 4/8/19 9:46 PM, Simone Bordet wrote: > Holy cow! Yes, and also consider there are lots of threads that already bash kernel with scheduling requests. On my machine, there is ~18% sys time and 500K ctxsw/sec. Kernel probably has not time to deal with committing stuff on top of that storm. >> Yes. Just don't be surprised when concurrent collectors do not give the latency boost there :) > > I'm not expecting a median latency boost here. > I actually had no expectations and was just curious as to what could > have happened when running the CometD benchmark with ZGC and > Shenandoah. You're not likely to get the max latency improvements either, as generational STW GCs would be able to hit the similar 1..3ms pauses consistently. > But we have people interested in reducing max latency as much as > possible, even sacrificing some throughput and median latency, so ZGC > and Shenandoah are worth exploring. > We (as the Jetty team) take the hit of trying these new GCs early so > at least we have some knowledge when people ask us about them :) Sure, appreciated. Looking forward for results with always-fully-committed memory! I have just tried with the latest jdk12 release binary with -Xmx10g -Xms10g -XX:+AlwaysPreTouch, and there are no apparent troubles on server side: Average CPU Load: 672.1718/1600 ======================================== @ _ 502 ?s (8410972, 99.96%) ^50% ^85% ^95% ^99% ^99.9% @ _ 1,004 ?s (2223, 0.03%) @ _ 1,506 ?s (504, 0.01%) @ _ 2,008 ?s (160, 0.00%) @ _ 2,510 ?s (93, 0.00%) @ _ 3,012 ?s (71, 0.00%) @ _ 3,514 ?s (51, 0.00%) @ _ 4,016 ?s (52, 0.00%) @ _ 4,518 ?s (27, 0.00%) @ _ 5,020 ?s (23, 0.00%) @ _ 5,522 ?s (11, 0.00%) @ _ 6,024 ?s (9, 0.00%) @ _ 6,526 ?s (11, 0.00%) @ _ 7,028 ?s (1, 0.00%) @ _ 7,530 ?s (1, 0.00%) @ _ 8,033 ?s (0, 0.00%) @ _ 8,535 ?s (0, 0.00%) @ _ 9,037 ?s (4, 0.00%) @ _ 9,539 ?s (1, 0.00%) @ _ 10,041 ?s (2, 0.00%) Requests - Latency: 8414216 samples | min/avg/50th%/99th%/max = 2/8/6/23/10,043 ?s Requests times (total/avg/max - stddev): 77669/0/10 ms - 0 Requests (total/failed/max - rate): 8414218/0/39 - 81772 requests/s ======================================== @ _ 2,276 ?s (4842264, 48.40%) @ _ 4,553 ?s (2615535, 26.14%) ^50% @ _ 6,830 ?s (1591673, 15.91%) ^85% @ _ 9,106 ?s (725789, 7.25%) ^95% @ _ 11,383 ?s (159531, 1.59%) ^99% @ _ 13,660 ?s (49446, 0.49%) @ _ 15,936 ?s (12426, 0.12%) ^99.9% @ _ 18,213 ?s (3629, 0.04%) @ _ 20,490 ?s (1939, 0.02%) @ _ 22,767 ?s (985, 0.01%) @ _ 25,043 ?s (665, 0.01%) @ _ 27,320 ?s (493, 0.00%) @ _ 29,597 ?s (251, 0.00%) @ _ 31,873 ?s (78, 0.00%) @ _ 34,150 ?s (39, 0.00%) @ _ 36,427 ?s (10, 0.00%) @ _ 38,704 ?s (44, 0.00%) @ _ 40,980 ?s (4, 0.00%) @ _ 43,257 ?s (0, 0.00%) @ _ 45,534 ?s (1, 0.00%) Messages - Processing: 10004802 samples | min/avg/50th%/99th%/max = 13/3,072/2,383/10,698/45,547 ?s ======================================== Jetty Thread Pool - Tasks = 4640206 | Concurrent Threads max = 113 | Queue Size max = 684 | Queue Latency avg/max = 1/23 ms | Task Latency avg/max = 0/1097 ms ...but I don't know how to properly interpret the results. The whole exercise was the source of interesting bugs, we already fixed a few, and other fixes are in pipeline. Cheers, -Aleksey From simone.bordet at gmail.com Mon Apr 8 20:30:08 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 22:30:08 +0200 Subject: Troubles with Shenandoah In-Reply-To: <40f3c786-0ddf-7c77-30ad-bec7c90fadf5@redhat.com> References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> <40f3c786-0ddf-7c77-30ad-bec7c90fadf5@redhat.com> Message-ID: Hi, On Mon, Apr 8, 2019 at 10:01 PM Aleksey Shipilev wrote: > You're not likely to get the max latency improvements either, as generational STW GCs would be able > to hit the similar 1..3ms pauses consistently. Well, G1 is in the 15-25 ms range, while ZGC is < 2 ms. > Sure, appreciated. Looking forward for results with always-fully-committed memory! > > I have just tried with the latest jdk12 release binary with -Xmx10g -Xms10g -XX:+AlwaysPreTouch, and > there are no apparent troubles on server side: > > Average CPU Load: 672.1718/1600 > ======================================== > @ _ 502 ?s (8410972, 99.96%) ^50% ^85% ^95% ^99% ^99.9% > @ _ 1,004 ?s (2223, 0.03%) > @ _ 1,506 ?s (504, 0.01%) > @ _ 2,008 ?s (160, 0.00%) > @ _ 2,510 ?s (93, 0.00%) > @ _ 3,012 ?s (71, 0.00%) > @ _ 3,514 ?s (51, 0.00%) > @ _ 4,016 ?s (52, 0.00%) > @ _ 4,518 ?s (27, 0.00%) > @ _ 5,020 ?s (23, 0.00%) > @ _ 5,522 ?s (11, 0.00%) > @ _ 6,024 ?s (9, 0.00%) > @ _ 6,526 ?s (11, 0.00%) > @ _ 7,028 ?s (1, 0.00%) > @ _ 7,530 ?s (1, 0.00%) > @ _ 8,033 ?s (0, 0.00%) > @ _ 8,535 ?s (0, 0.00%) > @ _ 9,037 ?s (4, 0.00%) > @ _ 9,539 ?s (1, 0.00%) > @ _ 10,041 ?s (2, 0.00%) > Requests - Latency: 8414216 samples | min/avg/50th%/99th%/max = 2/8/6/23/10,043 ?s > Requests times (total/avg/max - stddev): 77669/0/10 ms - 0 > Requests (total/failed/max - rate): 8414218/0/39 - 81772 requests/s > ======================================== > @ _ 2,276 ?s (4842264, 48.40%) > @ _ 4,553 ?s (2615535, 26.14%) ^50% > @ _ 6,830 ?s (1591673, 15.91%) ^85% > @ _ 9,106 ?s (725789, 7.25%) ^95% > @ _ 11,383 ?s (159531, 1.59%) ^99% > @ _ 13,660 ?s (49446, 0.49%) > @ _ 15,936 ?s (12426, 0.12%) ^99.9% > @ _ 18,213 ?s (3629, 0.04%) > @ _ 20,490 ?s (1939, 0.02%) > @ _ 22,767 ?s (985, 0.01%) > @ _ 25,043 ?s (665, 0.01%) > @ _ 27,320 ?s (493, 0.00%) > @ _ 29,597 ?s (251, 0.00%) > @ _ 31,873 ?s (78, 0.00%) > @ _ 34,150 ?s (39, 0.00%) > @ _ 36,427 ?s (10, 0.00%) > @ _ 38,704 ?s (44, 0.00%) > @ _ 40,980 ?s (4, 0.00%) > @ _ 43,257 ?s (0, 0.00%) > @ _ 45,534 ?s (1, 0.00%) > Messages - Processing: 10004802 samples | min/avg/50th%/99th%/max = 13/3,072/2,383/10,698/45,547 ?s > ======================================== > Jetty Thread Pool - Tasks = 4640206 | Concurrent Threads max = 113 | Queue Size max = 684 | Queue > Latency avg/max = 1/23 ms | Task Latency avg/max = 0/1097 ms Did you run with the default benchmark configuration? If so, can you try to increase the "batch count" to 10_000 or more? Shenandoah was ok for me for short runs, but not for longer runs. > ...but I don't know how to properly interpret the results. The first graph is the request _dispatch_ time - but because requests are asynchronous the major part of the work is done outside the request dispatching (that's why the times are smaller than the other graph). The second graph is the actual application (CometD) processing time. We have another option where the requests are not asynchronous so the first graph would always show Jetty processing time + CometD processing time, so we can derive the Jetty overhead. > The whole exercise was the source of interesting bugs, we already fixed a few, and other fixes are > in pipeline. So what exact version can I use to run this benchmark with Shenandoah? The latest 13? Should I wait for the fixes in the pipeline? I can build Shenandoah from the sources. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From shade at redhat.com Mon Apr 8 20:43:17 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 22:43:17 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> <40f3c786-0ddf-7c77-30ad-bec7c90fadf5@redhat.com> Message-ID: <5468f498-fee5-d5ce-472b-c44fab2235a1@redhat.com> On 4/8/19 10:30 PM, Simone Bordet wrote: > On Mon, Apr 8, 2019 at 10:01 PM Aleksey Shipilev wrote: >> You're not likely to get the max latency improvements either, as generational STW GCs would be able >> to hit the similar 1..3ms pauses consistently. > > Well, G1 is in the 15-25 ms range, while ZGC is < 2 ms. Aha, cool. G1 performs better for me here, at about 5ms; but that's probably I don't run with huge heaps and on moderate load. > Did you run with the default benchmark configuration? > If so, can you try to increase the "batch count" to 10_000 or more? > Shenandoah was ok for me for short runs, but not for longer runs. This was with batch-count=10K. I did run several iterations of it, spanning around an hour (lots of [Enters] pressed), and there are no lost messages. It used to be every 5-th run ending with lost msgs. What would be a good stress test to run overnight? batch-count=10M? >> The whole exercise was the source of interesting bugs, we already fixed a few, and other fixes are >> in pipeline. > > So what exact version can I use to run this benchmark with Shenandoah? > The latest 13? Should I wait for the fixes in the pipeline? > I can build Shenandoah from the sources. I'd say for evaluation use, you can continue with jdk12u binary and always-committed-heap, unless you experience another problem. If you are feeling adventurous, then build from jdk/jdk source. That is JDK development dumping ground^W^W mainline, which is *really* bleeding edge and might have surprising bugs. Otherwise, the patches should land in jdk12u within a week, as our CIs clear them for backporting, and we fix other problems too. -- Thanks, -Aleksey From simone.bordet at gmail.com Mon Apr 8 20:54:18 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Mon, 8 Apr 2019 22:54:18 +0200 Subject: Troubles with Shenandoah In-Reply-To: <5468f498-fee5-d5ce-472b-c44fab2235a1@redhat.com> References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> <40f3c786-0ddf-7c77-30ad-bec7c90fadf5@redhat.com> <5468f498-fee5-d5ce-472b-c44fab2235a1@redhat.com> Message-ID: Hi, On Mon, Apr 8, 2019 at 10:43 PM Aleksey Shipilev wrote: > This was with batch-count=10K. I did run several iterations of it, spanning around an hour (lots of > [Enters] pressed), and there are no lost messages. It used to be every 5-th run ending with lost > msgs. What would be a good stress test to run overnight? batch-count=10M? Just to be clear, you had no problems with heap locked at max size and always pre-touch with 12+33? batch count = 1_000 runs for ~10s. 8 hrs -> batch count = 2_880_000 Make it 2_500_00 and you should be good overnight (I once did precise math and the "circa" 10s, when multiplied, yielded hours more :) > I'd say for evaluation use, you can continue with jdk12u binary and always-committed-heap, unless > you experience another problem. Do you mean the tip of http://hg.openjdk.java.net/jdk-updates/jdk12u/? Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From shade at redhat.com Mon Apr 8 21:05:44 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Apr 2019 23:05:44 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> <40f3c786-0ddf-7c77-30ad-bec7c90fadf5@redhat.com> <5468f498-fee5-d5ce-472b-c44fab2235a1@redhat.com> Message-ID: On 4/8/19 10:54 PM, Simone Bordet wrote: > On Mon, Apr 8, 2019 at 10:43 PM Aleksey Shipilev wrote: >> This was with batch-count=10K. I did run several iterations of it, spanning around an hour (lots of >> [Enters] pressed), and there are no lost messages. It used to be every 5-th run ending with lost >> msgs. What would be a good stress test to run overnight? batch-count=10M? > > Just to be clear, you had no problems with heap locked at max size and > always pre-touch with 12+33? Correct. I used jdk12 binary [1] for testing: 12-testing+0-builds.shipilev.net-openjdk-jdk12-b158-20190406-jdk-1233jdk-12-ga. Locking the heap resolved the latency and lost messages problems for me. YMMV, so please try yourself. > batch count = 1_000 runs for ~10s. > 8 hrs -> batch count = 2_880_000 > > Make it 2_500_00 and you should be good overnight (I once did precise > math and the "circa" 10s, when multiplied, yielded hours more :) Okay! >> I'd say for evaluation use, you can continue with jdk12u binary and always-committed-heap, unless >> you experience another problem. > > Do you mean the tip of http://hg.openjdk.java.net/jdk-updates/jdk12u/? Yes. Our jdk12u nightlies [1] are built from there. You can build it yourself, or just use the existing binary. -Aleksey [1] https://builds.shipilev.net/openjdk-jdk12/ From shade at redhat.com Tue Apr 9 08:20:24 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 9 Apr 2019 10:20:24 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> <40f3c786-0ddf-7c77-30ad-bec7c90fadf5@redhat.com> <5468f498-fee5-d5ce-472b-c44fab2235a1@redhat.com> Message-ID: <55366e5f-2e8b-e2c8-7e54-a76f6f148803@redhat.com> On 4/8/19 11:05 PM, Aleksey Shipilev wrote: > On 4/8/19 10:54 PM, Simone Bordet wrote: >> Just to be clear, you had no problems with heap locked at max size and >> always pre-touch with 12+33? > > Correct. I used jdk12 binary [1] for testing: > 12-testing+0-builds.shipilev.net-openjdk-jdk12-b158-20190406-jdk-1233jdk-12-ga. Locking the heap > resolved the latency and lost messages problems for me. YMMV, so please try yourself. > >> batch count = 1_000 runs for ~10s. >> 8 hrs -> batch count = 2_880_000 >> >> Make it 2_500_00 and you should be good overnight (I once did precise >> math and the "circa" 10s, when multiplied, yielded hours more :) > > Okay! I ran 2_500_000 batches overnight with jdk12 fastdebug build and full verification, without any trouble. -Aleksey From shade at redhat.com Tue Apr 9 13:55:51 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 9 Apr 2019 15:55:51 +0200 Subject: RFR (S) 8222185: Shenandoah should report "committed" as capacity Message-ID: <9e287c0e-20fa-cc87-8d7c-a4ceaed39e07@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8222185 Fix: http://cr.openjdk.java.net/~shade/8222185/webrev.01/ Shenandoah resizes the heap by (un)committing the individual regions. Therefore, the true heap capacity is the "committed" size, not the maximum possible capacity. Currently, gc logs misreport the heap size, for example with -Xms1g -Xmx4g: GC(2) Concurrent marking 183M->183M(4096M) 2.243ms Notice "(4096M)", which is not the actual memory taken by committed heap. With this patch, we properly report the current capacity: GC(5) Concurrent marking (process weakrefs) 137M->137M(138M) 2.750ms I had to rewrite current uses: "capacity" -> "max_capacity" in heuristics, and "committed" -> "capacity" in monitoring code. Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey From shade at redhat.com Tue Apr 9 13:55:59 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 9 Apr 2019 15:55:59 +0200 Subject: RFR (S) 8222186: Shenandoah should not uncommit below minimum heap size Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8222186 Fix: http://cr.openjdk.java.net/~shade/8222186/webrev.01/ There is some confusion what -Xms really means. Current code assumes it only means "initial" heap size, which allows it to uncommit the heap below -Xms. However, users expect -Xms to mean "minimum heap size" to set the low watermark for heap shrinkage. We need to amend Shenandoah to avoid uncommitting below that watermark. Testing: hotspot_gc_shenandoah (includes new test cases), eyeballing gc logs -- Thanks, -Aleksey From zgu at redhat.com Tue Apr 9 14:00:52 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 9 Apr 2019 10:00:52 -0400 Subject: RFR (S) 8222185: Shenandoah should report "committed" as capacity In-Reply-To: <9e287c0e-20fa-cc87-8d7c-a4ceaed39e07@redhat.com> References: <9e287c0e-20fa-cc87-8d7c-a4ceaed39e07@redhat.com> Message-ID: <1ef0349a-6221-2675-ce87-f09c475df3e8@redhat.com> Good to me. -Zhengyu On 4/9/19 9:55 AM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8222185 > > Fix: > http://cr.openjdk.java.net/~shade/8222185/webrev.01/ > > Shenandoah resizes the heap by (un)committing the individual regions. Therefore, the true heap > capacity is the "committed" size, not the maximum possible capacity. Currently, gc logs misreport > the heap size, for example with -Xms1g -Xmx4g: > > GC(2) Concurrent marking 183M->183M(4096M) 2.243msGoo > > Notice "(4096M)", which is not the actual memory taken by committed heap. With this patch, we > properly report the current capacity: > > GC(5) Concurrent marking (process weakrefs) 137M->137M(138M) 2.750ms > > I had to rewrite current uses: "capacity" -> "max_capacity" in heuristics, and "committed" -> > "capacity" in monitoring code. > > Testing: hotspot_gc_shenandoah, eyeballing gc logs > From zgu at redhat.com Tue Apr 9 14:06:19 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 9 Apr 2019 10:06:19 -0400 Subject: RFR (S) 8222186: Shenandoah should not uncommit below minimum heap size In-Reply-To: References: Message-ID: <87c895ea-c4db-666b-2591-e83ff7e4006a@redhat.com> ShenandoahHeap.hpp L#200 : indents Otherwise, looks good. -Zhengyu On 4/9/19 9:55 AM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8222186 > > Fix: > http://cr.openjdk.java.net/~shade/8222186/webrev.01/ > > There is some confusion what -Xms really means. Current code assumes it only means "initial" heap > size, which allows it to uncommit the heap below -Xms. However, users expect -Xms to mean "minimum > heap size" to set the low watermark for heap shrinkage. We need to amend Shenandoah to avoid > uncommitting below that watermark. > > Testing: hotspot_gc_shenandoah (includes new test cases), eyeballing gc logs > From shade at redhat.com Tue Apr 9 14:07:38 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 9 Apr 2019 16:07:38 +0200 Subject: RFR (S) 8222186: Shenandoah should not uncommit below minimum heap size In-Reply-To: <87c895ea-c4db-666b-2591-e83ff7e4006a@redhat.com> References: <87c895ea-c4db-666b-2591-e83ff7e4006a@redhat.com> Message-ID: <17f29128-7b41-e7b5-bbda-36a5ef15fa5b@redhat.com> On 4/9/19 4:06 PM, Zhengyu Gu wrote: > ShenandoahHeap.hpp L#200 : indents These are indented to align "size_t" with optional "volatile": 199 private: 200 size_t _initial_size; 201 size_t _minimum_size; 202 DEFINE_PAD_MINUS_SIZE(0, DEFAULT_CACHE_LINE_SIZE, sizeof(volatile size_t)); 203 volatile size_t _used; 204 volatile size_t _committed; 205 volatile size_t _bytes_allocated_since_gc_start; 206 DEFINE_PAD_MINUS_SIZE(1, DEFAULT_CACHE_LINE_SIZE, 0); -Aleksey From zgu at redhat.com Tue Apr 9 14:12:39 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 9 Apr 2019 10:12:39 -0400 Subject: RFR (S) 8222186: Shenandoah should not uncommit below minimum heap size In-Reply-To: <17f29128-7b41-e7b5-bbda-36a5ef15fa5b@redhat.com> References: <87c895ea-c4db-666b-2591-e83ff7e4006a@redhat.com> <17f29128-7b41-e7b5-bbda-36a5ef15fa5b@redhat.com> Message-ID: <46465f5b-771b-3d01-500a-edcefc5088bf@redhat.com> On 4/9/19 10:07 AM, Aleksey Shipilev wrote: > On 4/9/19 4:06 PM, Zhengyu Gu wrote: >> ShenandoahHeap.hpp L#200 : indents > > These are indented to align "size_t" with optional "volatile": > > 199 private: > 200 size_t _initial_size; > 201 size_t _minimum_size; > 202 DEFINE_PAD_MINUS_SIZE(0, DEFAULT_CACHE_LINE_SIZE, sizeof(volatile size_t)); > 203 volatile size_t _used; > 204 volatile size_t _committed; > 205 volatile size_t _bytes_allocated_since_gc_start; > 206 DEFINE_PAD_MINUS_SIZE(1, DEFAULT_CACHE_LINE_SIZE, 0); > Okay. Seems we don't do that elsewhere. Your choice. -Zhengyu > -Aleksey > From zgu at redhat.com Tue Apr 9 14:13:00 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 9 Apr 2019 10:13:00 -0400 Subject: RFR(XXS) 8222188: Shenandoah: Adjust Shenandoah work gang types Message-ID: This is a cleanup in preparation for concurrent class unloading. Bug: https://bugs.openjdk.java.net/browse/JDK-8222188 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222188/webrev.00/index.html Test: hotspot_gc_shenandoah on Linux 64 (fastdebug and release) Thanks, -Zhengyu From shade at redhat.com Tue Apr 9 14:19:05 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 9 Apr 2019 16:19:05 +0200 Subject: RFR(XXS) 8222188: Shenandoah: Adjust Shenandoah work gang types In-Reply-To: References: Message-ID: <171ed193-bc57-13ef-cf3b-63b60ab5426b@redhat.com> On 4/9/19 4:13 PM, Zhengyu Gu wrote: > This is a cleanup in preparation for concurrent class unloading. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222188 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222188/webrev.00/index.html OK. Changing _safepoint_workers to be GC_Task_threads does not violate correctness? Nits: *) Changeset synopsis is odd? "1. cleanup for concurrent class unloading" *) Whitespace missing after "*/" at L453 here: 452 _workers = new ShenandoahWorkGang("Shenandoah GC Threads", _max_workers, 453 /* are_GC_task_threads */true, 454 /* are_ConcurrentGC_threads */ true); *) Better indenting maybe, like this? assert(!Thread::current()->is_Worker_thread() && (Thread::current()->is_VM_thread() || Thread::current()->is_ConcurrentGC_thread()) Thanks, -Aleksey From shade at redhat.com Tue Apr 9 14:19:45 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 9 Apr 2019 16:19:45 +0200 Subject: [RFR] [8u] 8u202 Upstream Sync In-Reply-To: <118e1dc9-66eb-62bb-b03c-7bd75aa53767@redhat.com> References: <01082237-f8fb-40bf-3615-a2a3e790bbfb@redhat.com> <65d545ab-0266-f293-80c9-418208c3008d@redhat.com> <118e1dc9-66eb-62bb-b03c-7bd75aa53767@redhat.com> Message-ID: On 4/8/19 6:12 PM, Aleksey Shipilev wrote: > On 4/8/19 6:07 PM, Andrew John Hughes wrote: >> so I moved the val = shenandoah_read_barrier_storeval(val) with the >> store_oop_to_unknown it previously guarded. The other Node *rb = >> shenandoah_read_barrier_storeval(val) was discarded along with the rest >> of that else block. >> >> This is part of 8155635: C2: Mixed unsafe accesses break alias analysis. > > Yes, I figured as much. I think that merge was correct. Testing would show how wrong we are about > assuming stuff in C2 :) I kicked off the test run. Shenandoah testing seems happy. -Aleksey From rkennke at redhat.com Tue Apr 9 14:31:12 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 09 Apr 2019 16:31:12 +0200 Subject: RFR(XXS) 8222188: Shenandoah: Adjust Shenandoah work gang types In-Reply-To: References: Message-ID: <1ad8448907c15bd2e9146cb79f889294b5aff9be.camel@redhat.com> I'd be careful with this, and not change it unless we really have to. Have you checked if we use any of is_ConcurrentGC_thread(), is_Worker_thread(), is_GC_task_thread() anywhere? I believe the OOM handler might use this to differenciate different types of threads. Roman > Am Dienstag, den 09.04.2019, 10:13 -0400 schrieb Zhengyu Gu: > This is a cleanup in preparation for concurrent class unloading. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222188 > Webrev: > http://cr.openjdk.java.net/~zgu/JDK-8222188/webrev.00/index.html > > Test: > hotspot_gc_shenandoah on Linux 64 (fastdebug and release) > > Thanks, > > -Zhengyu From zgu at redhat.com Tue Apr 9 14:59:37 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 9 Apr 2019 10:59:37 -0400 Subject: RFR(XXS) 8222188: Shenandoah: Adjust Shenandoah work gang types In-Reply-To: <171ed193-bc57-13ef-cf3b-63b60ab5426b@redhat.com> References: <171ed193-bc57-13ef-cf3b-63b60ab5426b@redhat.com> Message-ID: <0b4c69bd-eab9-2dfc-cd4c-aacd85448669@redhat.com> On 4/9/19 10:19 AM, Aleksey Shipilev wrote: > On 4/9/19 4:13 PM, Zhengyu Gu wrote: >> This is a cleanup in preparation for concurrent class unloading. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222188 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222188/webrev.00/index.html > > OK. Changing _safepoint_workers to be GC_Task_threads does not violate correctness? Reverted this part. Was following G1, but ZGC setup the same way as we do. I guess that shared code does not depends on this property. > > Nits: > > *) Changeset synopsis is odd? > "1. cleanup for concurrent class unloading" This just my local mq message. > > *) Whitespace missing after "*/" at L453 here: > > 452 _workers = new ShenandoahWorkGang("Shenandoah GC Threads", _max_workers, > 453 /* are_GC_task_threads */true, > 454 /* are_ConcurrentGC_threads */ true); > > *) Better indenting maybe, like this? > > assert(!Thread::current()->is_Worker_thread() && > (Thread::current()->is_VM_thread() || > Thread::current()->is_ConcurrentGC_thread()) Missed another occurrence in shenandoah/shenandoahTimingTracker.cpp Updated: http://cr.openjdk.java.net/~zgu/JDK-8222188/webrev.01/ Thanks, -Zhengyu > > Thanks, > -Aleksey > From zgu at redhat.com Tue Apr 9 15:02:28 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 9 Apr 2019 11:02:28 -0400 Subject: RFR(XXS) 8222188: Shenandoah: Adjust Shenandoah work gang types In-Reply-To: <1ad8448907c15bd2e9146cb79f889294b5aff9be.camel@redhat.com> References: <1ad8448907c15bd2e9146cb79f889294b5aff9be.camel@redhat.com> Message-ID: <6ae0fc36-d7e9-4e8b-2453-45e6a6e655d4@redhat.com> Hi Roman, On 4/9/19 10:31 AM, Roman Kennke wrote: > I'd be careful with this, and not change it unless we really have to. > Have you checked if we use any of is_ConcurrentGC_thread(), > is_Worker_thread(), is_GC_task_thread() anywhere? I believe the OOM > handler might use this to differenciate different types of threads. I reverted safepoint_workers change. There are only two is_ConcurrentGC_thread() checks, both are in assertion code, updated accordingly. New webrev: http://cr.openjdk.java.net/~zgu/JDK-8222188/webrev.01/ Thanks, -Zhengyu > > Roman > >> Am Dienstag, den 09.04.2019, 10:13 -0400 schrieb Zhengyu Gu: >> This is a cleanup in preparation for concurrent class unloading. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222188 >> Webrev: >> http://cr.openjdk.java.net/~zgu/JDK-8222188/webrev.00/index.html >> >> Test: >> hotspot_gc_shenandoah on Linux 64 (fastdebug and release) >> >> Thanks, >> >> -Zhengyu From shade at redhat.com Tue Apr 9 15:35:14 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 9 Apr 2019 17:35:14 +0200 Subject: RFR(XXS) 8222188: Shenandoah: Adjust Shenandoah work gang types In-Reply-To: <0b4c69bd-eab9-2dfc-cd4c-aacd85448669@redhat.com> References: <171ed193-bc57-13ef-cf3b-63b60ab5426b@redhat.com> <0b4c69bd-eab9-2dfc-cd4c-aacd85448669@redhat.com> Message-ID: On 4/9/19 4:59 PM, Zhengyu Gu wrote: > Updated: http://cr.openjdk.java.net/~zgu/JDK-8222188/webrev.01/ OK. I think it still makes sense to add parameter comments to _safepoint_workers, just not change the actual passed values? -Aleksey From zgu at redhat.com Tue Apr 9 15:44:39 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 9 Apr 2019 11:44:39 -0400 Subject: RFR(XXS) 8222188: Shenandoah: Adjust Shenandoah work gang types In-Reply-To: References: <171ed193-bc57-13ef-cf3b-63b60ab5426b@redhat.com> <0b4c69bd-eab9-2dfc-cd4c-aacd85448669@redhat.com> Message-ID: <4c8cd992-b469-53c6-04c9-aedf53acf589@redhat.com> On 4/9/19 11:35 AM, Aleksey Shipilev wrote: > On 4/9/19 4:59 PM, Zhengyu Gu wrote: >> Updated: http://cr.openjdk.java.net/~zgu/JDK-8222188/webrev.01/ > OK. I think it still makes sense to add parameter comments to _safepoint_workers, just not change > the actual passed values? Okay, will update before push. Thanks, -Zhengyu > > -Aleksey > From rkennke at redhat.com Tue Apr 9 16:14:55 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 09 Apr 2019 18:14:55 +0200 Subject: RFR (S) 8222185: Shenandoah should report "committed" as capacity In-Reply-To: <9e287c0e-20fa-cc87-8d7c-a4ceaed39e07@redhat.com> References: <9e287c0e-20fa-cc87-8d7c-a4ceaed39e07@redhat.com> Message-ID: <6de686bd8befa388e148f3552ab1b70f31464e4f.camel@redhat.com> RFE: > https://bugs.openjdk.java.net/browse/JDK-8222185 > > Fix: > http://cr.openjdk.java.net/~shade/8222185/webrev.01/ > > Shenandoah resizes the heap by (un)committing the individual regions. > Therefore, the true heap > capacity is the "committed" size, not the maximum possible capacity. > Currently, gc logs misreport > the heap size, for example with -Xms1g -Xmx4g: > > GC(2) Concurrent marking 183M->183M(4096M) 2.243ms > > Notice "(4096M)", which is not the actual memory taken by committed > heap. With this patch, we > properly report the current capacity: > > GC(5) Concurrent marking (process weakrefs) 137M->137M(138M) > 2.750ms > > I had to rewrite current uses: "capacity" -> "max_capacity" in > heuristics, and "committed" -> > "capacity" in monitoring code. > > Testing: hotspot_gc_shenandoah, eyeballing gc logs Patch looks ok. I wonder if it would make sense to report max_capacity too? On the other hand, it would then be sufficient to report it once because it never changes. Roman From shade at redhat.com Tue Apr 9 16:19:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 9 Apr 2019 18:19:58 +0200 Subject: RFR (S) 8222185: Shenandoah should report "committed" as capacity In-Reply-To: <6de686bd8befa388e148f3552ab1b70f31464e4f.camel@redhat.com> References: <9e287c0e-20fa-cc87-8d7c-a4ceaed39e07@redhat.com> <6de686bd8befa388e148f3552ab1b70f31464e4f.camel@redhat.com> Message-ID: On 4/9/19 6:14 PM, Roman Kennke wrote: > Patch looks ok. I wonder if it would make sense to report max_capacity > too? On the other hand, it would then be sufficient to report it once > because it never changes. This GC log is shared code, and it prints capacity() for all GCs; which is the capacity at current heap sizing. Shenandoah now reports something that matches other collectors. It makes little sense to print max_capacity() there anyway, as it would come as configuration setting, and can be printed with -Xlog:gc+init. -Aleksey From rkennke at redhat.com Tue Apr 9 16:28:56 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 09 Apr 2019 18:28:56 +0200 Subject: RFR (S) 8222185: Shenandoah should report "committed" as capacity In-Reply-To: References: <9e287c0e-20fa-cc87-8d7c-a4ceaed39e07@redhat.com> <6de686bd8befa388e148f3552ab1b70f31464e4f.camel@redhat.com> Message-ID: <3EF31C2B-94CC-4D83-8616-C2A50A55C670@redhat.com> OK. Go! Roman Am 9. April 2019 18:19:58 MESZ schrieb Aleksey Shipilev : >On 4/9/19 6:14 PM, Roman Kennke wrote: >> Patch looks ok. I wonder if it would make sense to report >max_capacity >> too? On the other hand, it would then be sufficient to report it once >> because it never changes. > >This GC log is shared code, and it prints capacity() for all GCs; which >is the capacity at current >heap sizing. Shenandoah now reports something that matches other >collectors. It makes little sense >to print max_capacity() there anyway, as it would come as configuration >setting, and can be printed >with -Xlog:gc+init. > >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From rkennke at redhat.com Tue Apr 9 18:51:13 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 09 Apr 2019 20:51:13 +0200 Subject: RFR (S) 8222186: Shenandoah should not uncommit below minimum heap size In-Reply-To: References: Message-ID: <1f9c7819d0c9a1acb0c129662aa2024ea5cc5fce.camel@redhat.com> Looks good to me, thanks! Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8222186 > > Fix: > http://cr.openjdk.java.net/~shade/8222186/webrev.01/ > > There is some confusion what -Xms really means. Current code assumes > it only means "initial" heap > size, which allows it to uncommit the heap below -Xms. However, users > expect -Xms to mean "minimum > heap size" to set the low watermark for heap shrinkage. We need to > amend Shenandoah to avoid > uncommitting below that watermark. > > Testing: hotspot_gc_shenandoah (includes new test cases), eyeballing > gc logs > From rkennke at redhat.com Tue Apr 9 19:58:28 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 09 Apr 2019 21:58:28 +0200 Subject: RFR(XXS) 8222188: Shenandoah: Adjust Shenandoah work gang types In-Reply-To: <6ae0fc36-d7e9-4e8b-2453-45e6a6e655d4@redhat.com> References: <1ad8448907c15bd2e9146cb79f889294b5aff9be.camel@redhat.com> <6ae0fc36-d7e9-4e8b-2453-45e6a6e655d4@redhat.com> Message-ID: <9ee126d82aec0c2eeb73944587d1a589956d35bf.camel@redhat.com> Looks good, thanks! > Hi Roman, > > On 4/9/19 10:31 AM, Roman Kennke wrote: > > I'd be careful with this, and not change it unless we really have > > to. > > Have you checked if we use any of is_ConcurrentGC_thread(), > > is_Worker_thread(), is_GC_task_thread() anywhere? I believe the OOM > > handler might use this to differenciate different types of threads. > > I reverted safepoint_workers change. > > There are only two is_ConcurrentGC_thread() checks, both are in > assertion code, updated accordingly. > > New webrev: http://cr.openjdk.java.net/~zgu/JDK-8222188/webrev.01/ > > Thanks, > > -Zhengyu > > > Roman > > > > > Am Dienstag, den 09.04.2019, 10:13 -0400 schrieb Zhengyu Gu: > > > This is a cleanup in preparation for concurrent class unloading. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222188 > > > Webrev: > > > http://cr.openjdk.java.net/~zgu/JDK-8222188/webrev.00/index.html > > > > > > Test: > > > hotspot_gc_shenandoah on Linux 64 (fastdebug and release) > > > > > > Thanks, > > > > > > -Zhengyu From rkennke at redhat.com Tue Apr 9 20:30:42 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 9 Apr 2019 22:30:42 +0200 Subject: RFR: JDK-8222227: Shenandoah: Fix Traversal GC weak roots handling in final-traversal pause Message-ID: <2d07dcdb-48a6-147b-aea6-e6a3e146b196@redhat.com> We currently clean weak roots only when weak-references are processed in Traversal GC. This is wrong, because it should be independent whether or not it's doing reference-processing. Also, (weak) roots need to be updated and cleaned before classes get unloaded (currently), because this is how class-unloaded detects unreachable classes. With all this, we no longer need to run class-unloading and reference-processing every cycle, which covered up those bugs. Bug: https://bugs.openjdk.java.net/browse/JDK-8222227 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8222227/webrev.02/ Testing: hotspot_gc_shenandoah Roman From shade at redhat.com Tue Apr 9 20:43:22 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 9 Apr 2019 22:43:22 +0200 Subject: RFR: JDK-8222227: Shenandoah: Fix Traversal GC weak roots handling in final-traversal pause In-Reply-To: <2d07dcdb-48a6-147b-aea6-e6a3e146b196@redhat.com> References: <2d07dcdb-48a6-147b-aea6-e6a3e146b196@redhat.com> Message-ID: <06432a9f-4c0d-535b-c9c4-c12a916b799c@redhat.com> On 4/9/19 10:30 PM, Roman Kennke wrote: > We currently clean weak roots only when weak-references are processed in > Traversal GC. This is wrong, because it should be independent whether or > not it's doing reference-processing. Not sure I can cross-reference it with the current code. Where do we clean weak roots with Traversal now? > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8222227/webrev.02/ Looks good, modulo the thing above. -Aleksey From rkennke at redhat.com Tue Apr 9 20:47:33 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 09 Apr 2019 22:47:33 +0200 Subject: RFR: JDK-8222227: Shenandoah: Fix Traversal GC weak roots handling in final-traversal pause In-Reply-To: <06432a9f-4c0d-535b-c9c4-c12a916b799c@redhat.com> References: <2d07dcdb-48a6-147b-aea6-e6a3e146b196@redhat.com> <06432a9f-4c0d-535b-c9c4-c12a916b799c@redhat.com> Message-ID: <0eb6f473d5e66e4cc3063f777d3ae88cd50bc10c.camel@redhat.com> Am Dienstag, den 09.04.2019, 22:43 +0200 schrieb Aleksey Shipilev: > On 4/9/19 10:30 PM, Roman Kennke wrote: > > We currently clean weak roots only when weak-references are > > processed in > > Traversal GC. This is wrong, because it should be independent > > whether or > > not it's doing reference-processing. > > Not sure I can cross-reference it with the current code. Where do we > clean weak roots with Traversal > now? > Ah oops, forgot to mention: it happens as part of fixup_roots(). > > Webrev: > > http://cr.openjdk.java.net/~rkennke/JDK-8222227/webrev.02/ > > Looks good, modulo the thing above. From shade at redhat.com Tue Apr 9 20:49:23 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 9 Apr 2019 22:49:23 +0200 Subject: RFR: JDK-8222227: Shenandoah: Fix Traversal GC weak roots handling in final-traversal pause In-Reply-To: <0eb6f473d5e66e4cc3063f777d3ae88cd50bc10c.camel@redhat.com> References: <2d07dcdb-48a6-147b-aea6-e6a3e146b196@redhat.com> <06432a9f-4c0d-535b-c9c4-c12a916b799c@redhat.com> <0eb6f473d5e66e4cc3063f777d3ae88cd50bc10c.camel@redhat.com> Message-ID: <7e44d03d-5cb6-61db-779d-827a9f1bc7de@redhat.com> On 4/9/19 10:47 PM, Roman Kennke wrote: > Am Dienstag, den 09.04.2019, 22:43 +0200 schrieb Aleksey Shipilev: >> On 4/9/19 10:30 PM, Roman Kennke wrote: >>> We currently clean weak roots only when weak-references are >>> processed in Traversal GC. This is wrong, because it should be independent >>> whether or not it's doing reference-processing. >> >> Not sure I can cross-reference it with the current code. Where do we >> clean weak roots with Traversal now? > > Ah oops, forgot to mention: it happens as part of fixup_roots(). I see. Okay then! -Aleksey From zgu at redhat.com Tue Apr 9 21:02:01 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 9 Apr 2019 17:02:01 -0400 Subject: RFR: JDK-8222227: Shenandoah: Fix Traversal GC weak roots handling in final-traversal pause In-Reply-To: <2d07dcdb-48a6-147b-aea6-e6a3e146b196@redhat.com> References: <2d07dcdb-48a6-147b-aea6-e6a3e146b196@redhat.com> Message-ID: <57582f3d-c47c-8963-fc4b-791020365a4a@redhat.com> Looks good. -Zhengyu On 4/9/19 4:30 PM, Roman Kennke wrote: > We currently clean weak roots only when weak-references are processed in > Traversal GC. This is wrong, because it should be independent whether or > not it's doing reference-processing. > Also, (weak) roots need to be updated and cleaned before classes get > unloaded (currently), because this is how class-unloaded detects > unreachable classes. > With all this, we no longer need to run class-unloading and > reference-processing every cycle, which covered up those bugs. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8222227 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8222227/webrev.02/ > > Testing: hotspot_gc_shenandoah > > Roman > From simone.bordet at gmail.com Tue Apr 9 21:09:10 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 9 Apr 2019 23:09:10 +0200 Subject: Troubles with Shenandoah In-Reply-To: <55366e5f-2e8b-e2c8-7e54-a76f6f148803@redhat.com> References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> <40f3c786-0ddf-7c77-30ad-bec7c90fadf5@redhat.com> <5468f498-fee5-d5ce-472b-c44fab2235a1@redhat.com> <55366e5f-2e8b-e2c8-7e54-a76f6f148803@redhat.com> Message-ID: Hi, On Tue, Apr 9, 2019 at 10:20 AM Aleksey Shipilev wrote: > > On 4/8/19 11:05 PM, Aleksey Shipilev wrote: > > On 4/8/19 10:54 PM, Simone Bordet wrote: > >> Just to be clear, you had no problems with heap locked at max size and > >> always pre-touch with 12+33? > > > > Correct. I used jdk12 binary [1] for testing: > > 12-testing+0-builds.shipilev.net-openjdk-jdk12-b158-20190406-jdk-1233jdk-12-ga. Locking the heap > > resolved the latency and lost messages problems for me. YMMV, so please try yourself. > > > >> batch count = 1_000 runs for ~10s. > >> 8 hrs -> batch count = 2_880_000 > >> > >> Make it 2_500_00 and you should be good overnight (I once did precise > >> math and the "circa" 10s, when multiplied, yielded hours more :) > > > > Okay! > > I ran 2_500_000 batches overnight with jdk12 fastdebug build and full verification, without any trouble. Ran 12+33 with -Xms==-Xmx and -XX+AlwaysPreTouch for 20+ mins without issues. Now I'm just curious about what the previous settings triggered. How come https://bugs.openjdk.java.net/browse/JDK-8222129 is not triggered with this setup, but was with the previous? Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From shade at redhat.com Tue Apr 9 21:13:17 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 9 Apr 2019 23:13:17 +0200 Subject: Troubles with Shenandoah In-Reply-To: References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> <40f3c786-0ddf-7c77-30ad-bec7c90fadf5@redhat.com> <5468f498-fee5-d5ce-472b-c44fab2235a1@redhat.com> <55366e5f-2e8b-e2c8-7e54-a76f6f148803@redhat.com> Message-ID: <1e4b8505-c5c6-2336-bbf6-dad5edce0d33@redhat.com> On 4/9/19 11:09 PM, Simone Bordet wrote: > Ran 12+33 with -Xms==-Xmx and -XX+AlwaysPreTouch for 20+ mins without issues. > > Now I'm just curious about what the previous settings triggered. My bet is on long commits after full uncommit triggered by System.gc() wrecked up everything. Maybe it is not a GC bug, but rather application layer loses the messages with timeouts? It would be a bit better for your -Xms16g (if I recall correctly?) setting after this lands: https://bugs.openjdk.java.net/browse/JDK-8222186 ...but -Xms = -Xmx and AlwaysPreTouch is also good. > How come https://bugs.openjdk.java.net/browse/JDK-8222129 is not > triggered with this setup, but was with the previous? This failure is about the feature (load-reference-barriers) not backported to 12u yet. Either way, it is not fatal, and release build would just take a safe default. -Aleksey From simone.bordet at gmail.com Tue Apr 9 21:44:26 2019 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 9 Apr 2019 23:44:26 +0200 Subject: Troubles with Shenandoah In-Reply-To: <1e4b8505-c5c6-2336-bbf6-dad5edce0d33@redhat.com> References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> <40f3c786-0ddf-7c77-30ad-bec7c90fadf5@redhat.com> <5468f498-fee5-d5ce-472b-c44fab2235a1@redhat.com> <55366e5f-2e8b-e2c8-7e54-a76f6f148803@redhat.com> <1e4b8505-c5c6-2336-bbf6-dad5edce0d33@redhat.com> Message-ID: Hi, On Tue, Apr 9, 2019 at 11:13 PM Aleksey Shipilev wrote: > My bet is on long commits after full uncommit triggered by System.gc() wrecked up everything. Maybe > it is not a GC bug, but rather application layer loses the messages with timeouts? Definitely, after seeing how long it takes. The application timeout is 5 seconds so it could have tripped. FYI, in my Shenandoah run (1 server, 48g heap, 4 client machines at each 1k clients at 10k messages/s) the max pause was about 4ms. The ZGC run had a max pause of about 2 ms. The G1 run had a max pause of about 33 ms (all young collections). I'll try now with smaller and smaller heaps. I have to say that after the initial struggle with Shenandoah, I'm impressed by both Shenandoah and ZGC. As a user, I get the feeling that one can kind of "forget" the GC as pauses will be super low. Also, tuning seems to be reduced to "increase heap size if you have problems" - no more generation sizing, survivor age tuning, etc. and with that no need to know what a generation is, what a survivor is, etc. Congrats so far and thanks for the help! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From shade at redhat.com Tue Apr 9 22:24:29 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 10 Apr 2019 00:24:29 +0200 Subject: Shenandoah and cometd testing In-Reply-To: References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> <40f3c786-0ddf-7c77-30ad-bec7c90fadf5@redhat.com> <5468f498-fee5-d5ce-472b-c44fab2235a1@redhat.com> <55366e5f-2e8b-e2c8-7e54-a76f6f148803@redhat.com> <1e4b8505-c5c6-2336-bbf6-dad5edce0d33@redhat.com> Message-ID: <7e3b5443-7655-fe69-a578-3a9b2f543a9a@redhat.com> On 4/9/19 11:44 PM, Simone Bordet wrote: > On Tue, Apr 9, 2019 at 11:13 PM Aleksey Shipilev wrote: > FYI, in my Shenandoah run (1 server, 48g heap, 4 client machines at > each 1k clients at 10k messages/s) the max pause was about 4ms. Cool. If you pass -Xlog:gc+stats, you might see the dissection of those pauses at the end of the run. For example, in a short run, -Xlog:gc+stats:file=stats.log gives this on cometd-server side: http://cr.openjdk.java.net/~shade/shenandoah/cometd-server-gc-stats.log Seems to me that until we finish the pending refactoring and/or concurrent class unloading story, -XX:-ClassUnloading might be beneficial for this workload. -Aleksey From rkennke at redhat.com Tue Apr 9 22:45:10 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 10 Apr 2019 00:45:10 +0200 Subject: Shenandoah and cometd testing In-Reply-To: <7e3b5443-7655-fe69-a578-3a9b2f543a9a@redhat.com> References: <4557c2ef-dd61-2cb6-d21f-89bcaff8037d@redhat.com> <38aa7403-2525-4524-c0c2-4b21c8faff82@redhat.com> <40f3c786-0ddf-7c77-30ad-bec7c90fadf5@redhat.com> <5468f498-fee5-d5ce-472b-c44fab2235a1@redhat.com> <55366e5f-2e8b-e2c8-7e54-a76f6f148803@redhat.com> <1e4b8505-c5c6-2336-bbf6-dad5edce0d33@redhat.com> <7e3b5443-7655-fe69-a578-3a9b2f543a9a@redhat.com> Message-ID: <50b4c454fafe1d8d92194529550177307cde87d7.camel@redhat.com> > On 4/9/19 11:44 PM, Simone Bordet wrote: > > On Tue, Apr 9, 2019 at 11:13 PM Aleksey Shipilev > > wrote: > > FYI, in my Shenandoah run (1 server, 48g heap, 4 client machines at > > each 1k clients at 10k messages/s) the max pause was about 4ms. > > Cool. If you pass -Xlog:gc+stats, you might see the dissection of > those pauses at the end of the > run. For example, in a short run, -Xlog:gc+stats:file=stats.log gives > this on cometd-server side: > > http://cr.openjdk.java.net/~shade/shenandoah/cometd-server-gc-stats.log > > Seems to me that until we finish the pending refactoring and/or > concurrent class unloading story, > -XX:-ClassUnloading might be beneficial for this workload. > > -Aleksey > -XX:-ClassUnloadingWithConcurrentMark is default, so it is not actually unloading any classes, except at full-gc. Or am I missing something? I see the 'System Purge' happened 2x. Is that full-gc-as-concurrent-gc, which also does class unloading? It looks like an accounting mistake. Roman From rkennke at redhat.com Wed Apr 10 11:28:22 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 10 Apr 2019 13:28:22 +0200 Subject: RFR: JDK-8222259: Shenandoah: Pre-evacuate string-dedup roots in Traversal GC Message-ID: <64d3e32f-075a-208d-fa3b-c9fb2d69af49@redhat.com> We need to pre-evacuate string-dedup roots in Traversal GC, just like we do in conc-mark-GC, otherwise we might get from-space objects there, and hit asserts later: # Internal Error (/home/jenkins/workspace/nightly/jdk-jdk/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp:168), pid=78715, tid=78721 # Error: Shenandoah assert_not_in_cset_loc failed; Interior location should not be in collection set More details in the bug: https://bugs.openjdk.java.net/browse/JDK-8222259 Fix: http://cr.openjdk.java.net/~rkennke/JDK-8222259/webrev.00/ Testing: hotspot_gc_shenandoah I'm doing this somewhat blindly because I couldn't reproduce it locally, but I'm fairly certain that this is the fix. From shade at redhat.com Wed Apr 10 12:31:06 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 10 Apr 2019 14:31:06 +0200 Subject: RFR: JDK-8222259: Shenandoah: Pre-evacuate string-dedup roots in Traversal GC In-Reply-To: <64d3e32f-075a-208d-fa3b-c9fb2d69af49@redhat.com> References: <64d3e32f-075a-208d-fa3b-c9fb2d69af49@redhat.com> Message-ID: <17aa6eb6-900e-0a8c-f8ad-44d2abcc3ba9@redhat.com> On 4/10/19 1:28 PM, Roman Kennke wrote: > Fix: > http://cr.openjdk.java.net/~rkennke/JDK-8222259/webrev.00/ It looks okay, but I would have expected the call to ShenandoahRootProcessor, rather than naked root walk. Isn't there a path into SRP that does it for traversal? -Aleksey From rkennke at redhat.com Wed Apr 10 12:34:58 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 10 Apr 2019 14:34:58 +0200 Subject: RFR: JDK-8222259: Shenandoah: Pre-evacuate string-dedup roots in Traversal GC In-Reply-To: <17aa6eb6-900e-0a8c-f8ad-44d2abcc3ba9@redhat.com> References: <64d3e32f-075a-208d-fa3b-c9fb2d69af49@redhat.com> <17aa6eb6-900e-0a8c-f8ad-44d2abcc3ba9@redhat.com> Message-ID: <65d497d53555dfe1fd06c44abb10ed1df6dcab4d.camel@redhat.com> > On 4/10/19 1:28 PM, Roman Kennke wrote: > > Fix: > > http://cr.openjdk.java.net/~rkennke/JDK-8222259/webrev.00/ > > It looks okay, but I would have expected the call to > ShenandoahRootProcessor, rather than naked root > walk. Isn't there a path into SRP that does it for traversal? Currently not, and the whole idea of pre-evacing anything from traversal is a bit of a cludge currently. For example, we need to pre- evac everything from code-roots currently, even if we stricly only want strong stuff marked. The solution would be to pre-evac strong code roots via stacks, and then let nmethod barrier pre-evac everything ever entered during the cycle. All of this requires deeper looking into it, but probably later when we're seriously into stabilizing traversal GC. Roman From shade at redhat.com Wed Apr 10 12:44:08 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 10 Apr 2019 14:44:08 +0200 Subject: RFR: JDK-8222259: Shenandoah: Pre-evacuate string-dedup roots in Traversal GC In-Reply-To: <65d497d53555dfe1fd06c44abb10ed1df6dcab4d.camel@redhat.com> References: <64d3e32f-075a-208d-fa3b-c9fb2d69af49@redhat.com> <17aa6eb6-900e-0a8c-f8ad-44d2abcc3ba9@redhat.com> <65d497d53555dfe1fd06c44abb10ed1df6dcab4d.camel@redhat.com> Message-ID: On 4/10/19 2:34 PM, Roman Kennke wrote: >> On 4/10/19 1:28 PM, Roman Kennke wrote: >>> Fix: >>> http://cr.openjdk.java.net/~rkennke/JDK-8222259/webrev.00/ >> >> It looks okay, but I would have expected the call to >> ShenandoahRootProcessor, rather than naked root >> walk. Isn't there a path into SRP that does it for traversal? > > Currently not, and the whole idea of pre-evacing anything from > traversal is a bit of a cludge currently. For example, we need to pre- > evac everything from code-roots currently, even if we stricly only want > strong stuff marked. The solution would be to pre-evac strong code > roots via stacks, and then let nmethod barrier pre-evac everything ever > entered during the cycle. All of this requires deeper looking into it, > but probably later when we're seriously into stabilizing traversal GC. Okay then. -Aleksey From rkennke at redhat.com Thu Apr 11 09:48:23 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 11 Apr 2019 11:48:23 +0200 Subject: RFR: Upstream merge to jdk-13+16 Message-ID: <7ae87b7c-4b9a-afd7-5da9-4fc3aaeb5829@redhat.com> This brings in lots of goodies from jdk/jdk: http://cr.openjdk.java.net/~rkennke/upstream-jdk13-merge-2019-04-11/changes.txt It required some manual merging in few places, but nothing tricky (basically, always selecting whatever comes from upstream). It passes hotspot_gc_shenandoah locally. Ok? Roman From shade at redhat.com Thu Apr 11 09:52:48 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 11 Apr 2019 11:52:48 +0200 Subject: RFR: Upstream merge to jdk-13+16 In-Reply-To: <7ae87b7c-4b9a-afd7-5da9-4fc3aaeb5829@redhat.com> References: <7ae87b7c-4b9a-afd7-5da9-4fc3aaeb5829@redhat.com> Message-ID: <6083cfc4-c125-a421-0ba8-a1c323a7226f@redhat.com> On 4/11/19 11:48 AM, Roman Kennke wrote: > This brings in lots of goodies from jdk/jdk: > > http://cr.openjdk.java.net/~rkennke/upstream-jdk13-merge-2019-04-11/changes.txt OK, let's do it. -Aleksey From rkennke at redhat.com Thu Apr 11 10:01:38 2019 From: rkennke at redhat.com (rkennke at redhat.com) Date: Thu, 11 Apr 2019 10:01:38 +0000 Subject: hg: shenandoah/jdk: 79 new changesets Message-ID: <201904111001.x3BA1h4S018010@aojmv0008.oracle.com> Changeset: 00fda51e28cf Author: erikj Date: 2019-04-03 12:52 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/00fda51e28cf 8221764: Reduce make Init.gmk logging overhead Reviewed-by: tbell ! make/Init.gmk ! make/InitSupport.gmk Changeset: b788c494aa46 Author: dholmes Date: 2019-04-03 22:03 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b788c494aa46 8218483: Crash in "assert(_daemon_threads_count->get_value() > daemon_count) failed: thread count mismatch 5 : 5" Reviewed-by: dcubed, stuefe ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! test/hotspot/gtest/threadHelper.inline.hpp Changeset: f87041131515 Author: xuelei Date: 2019-04-03 16:23 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f87041131515 8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11 Reviewed-by: valeriep ! src/java.base/share/classes/sun/security/ssl/CertificateVerify.java ! src/java.base/share/classes/sun/security/ssl/DHServerKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/ECDHKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java ! src/java.base/share/classes/sun/security/ssl/SignatureScheme.java ! src/java.base/share/classes/sun/security/ssl/X509Authentication.java Changeset: e998c9effb37 Author: jwilhelm Date: 2019-04-04 01:46 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/e998c9effb37 Added tag jdk-13+15 for changeset f855ec13aa25 ! .hgtags Changeset: 5c7418757bad Author: coleenp Date: 2019-04-03 20:39 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/5c7418757bad 8221872: Remove uses of ClassLoaderWeakHandle typedef in protection domain table Summary: Make consistent with StringTable and ResolvedMethodTable Reviewed-by: dholmes ! src/hotspot/share/classfile/protectionDomainCache.cpp ! src/hotspot/share/classfile/protectionDomainCache.hpp ! src/hotspot/share/utilities/hashtable.cpp Changeset: 724b9e361cb6 Author: rschmelter Date: 2019-03-26 01:46 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/724b9e361cb6 8221325: Add information about swap space to print_memory_info() on MacOS Reviewed-by: stuefe, dholmes ! src/hotspot/os/bsd/os_bsd.cpp Changeset: a7df0de0835a Author: weijun Date: 2019-04-04 20:22 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a7df0de0835a 8219861: Add new keytool -showinfo -tls command for displaying TLS configuration information Reviewed-by: mullan ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources.java + src/java.base/share/classes/sun/security/tools/keytool/ShowInfo.java Changeset: f562f8318ebd Author: erikj Date: 2019-04-04 07:43 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f562f8318ebd 8217728: Speed up incremental rerun of "make hotspot" Reviewed-by: tbell ! make/Main.gmk ! make/common/NativeCompilation.gmk Changeset: 6c0ab8bd8da5 Author: rkennke Date: 2019-04-02 23:00 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/6c0ab8bd8da5 8221766: Load-reference barriers for Shenandoah Reviewed-by: kvn, erikj, aph, shade ! make/hotspot/lib/JvmFeatures.gmk ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetC1_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoah_aarch64.ad ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetC1_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoah_x86_64.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahEvacOOMHandler.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRuntime.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/node.hpp ! test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java ! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierDisable.java Changeset: b354ffb03ae4 Author: mseledtsov Date: 2019-04-04 12:29 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b354ffb03ae4 8221710: [TESTBUG] more configurable parameters for docker testing Summary: Introduced docker test config properties Reviewed-by: lmesnik, iignatyev, egahlin ! test/hotspot/jtreg/runtime/containers/docker/DockerBasicTest.java ! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java Changeset: 13c02cc7a6e5 Author: rkennke Date: 2019-04-04 21:29 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/13c02cc7a6e5 8221848: Shenandoah: ArrayCopy post-barrier improvements Reviewed-by: zgu ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: 2da3b1a3942f Author: erikj Date: 2019-04-04 13:56 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/2da3b1a3942f 8221996: Bootcycle build broken Reviewed-by: tbell ! make/Main.gmk Changeset: 6aa05983e9d3 Author: redestad Date: 2019-04-04 23:19 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/6aa05983e9d3 8221980: Simplify Optional implementation Reviewed-by: smarks, clanger ! src/java.base/share/classes/java/util/Optional.java Changeset: 6aedb80a6fd4 Author: redestad Date: 2019-04-04 23:21 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/6aedb80a6fd4 8221981: Simplify Map/List/Set.of() implementation Reviewed-by: smarks ! src/java.base/share/classes/java/util/ImmutableCollections.java ! src/java.base/share/classes/java/util/List.java ! src/java.base/share/classes/java/util/Map.java ! src/java.base/share/classes/java/util/Set.java Changeset: 82f41fb55b63 Author: redestad Date: 2019-04-04 23:21 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/82f41fb55b63 8221921: Implement size() / isEmpty() in immutable collections Reviewed-by: smarks ! src/java.base/share/classes/java/util/ImmutableCollections.java Changeset: fb25cd198a10 Author: xuelei Date: 2019-04-04 14:19 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/fb25cd198a10 8163326: Update the default enabled cipher suites preference Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/CipherSuite.java ! test/jdk/javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java Changeset: ad9fa99fa48e Author: coleenp Date: 2019-04-04 17:23 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/ad9fa99fa48e 8221992: Fix old method replacement in ResolvedMethodTable Summary: Use method get_new_method() which is used in other call sites. Reviewed-by: sspitsyn ! src/hotspot/share/prims/resolvedMethodTable.cpp Changeset: 532e88de77eb Author: goetz Date: 2019-04-04 09:39 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/532e88de77eb 8221470: Print methods in exception messages in java-like Syntax. Reviewed-by: dholmes, mdoerr, coleenp ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/klassVtable.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/oops/method.hpp ! src/hotspot/share/oops/symbol.cpp ! src/hotspot/share/oops/symbol.hpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/prims/stackwalk.cpp ! src/hotspot/share/runtime/reflection.cpp ! test/hotspot/jtreg/runtime/LoaderConstraints/itableLdrConstraint/Test.java ! test/hotspot/jtreg/runtime/LoaderConstraints/vtableLdrConstraint/Test.java ! test/hotspot/jtreg/runtime/Nestmates/membership/TestNestmateMembership.java ! test/hotspot/jtreg/runtime/Nestmates/privateConstructors/TestConstructorHierarchy.java ! test/hotspot/jtreg/runtime/exceptionMsgs/AbstractMethodError/AbstractMethodErrorTest.java ! test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IllegalAccessErrorTest.java + test/hotspot/jtreg/runtime/exceptionMsgs/methodPrinting/TeMe3_C.jasm + test/hotspot/jtreg/runtime/exceptionMsgs/methodPrinting/TestPrintingMethods.java ! test/hotspot/jtreg/runtime/modules/AccessCheck/ExpQualToM1PrivateMethodIAE.java Changeset: b34bcfbcc2fd Author: goetz Date: 2019-04-05 07:59 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b34bcfbcc2fd 8219918: ProblemList hotspot tests failing in SAP testing. Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList.txt Changeset: dad2c80ae0b2 Author: mbaesken Date: 2019-04-02 13:54 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/dad2c80ae0b2 8218547: Simplify JLI_Open on Windows in native code (libjli) Reviewed-by: alanb, clanger ! src/java.base/windows/native/libjli/java_md.c ! test/jdk/tools/launcher/Arrrghs.java Changeset: 776b261dff84 Author: shade Date: 2019-04-05 09:06 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/776b261dff84 8221918: runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java fails: Shared archive not found Reviewed-by: jiangli, dholmes ! test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java Changeset: d5fb27646df4 Author: mdoerr Date: 2019-04-05 09:18 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/d5fb27646df4 8221833: Readability check in Symbol::is_valid not performed for some addresses Reviewed-by: zgu, coleenp ! src/hotspot/share/runtime/os.cpp Changeset: 2ae93028bef3 Author: stuefe Date: 2019-03-27 14:13 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/2ae93028bef3 8221539: [metaspace] Improve MetaspaceObj::is_metaspace_obj() and friends Reviewed-by: adinn, coleenp, mdoerr ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/arm/frame_arm.cpp ! src/hotspot/cpu/sparc/frame_sparc.cpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/os_cpu/linux_ppc/thread_linux_ppc.cpp ! src/hotspot/os_cpu/linux_s390/thread_linux_s390.cpp ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.hpp ! src/hotspot/share/memory/metaspace/virtualSpaceNode.hpp ! src/hotspot/share/oops/instanceKlass.cpp + test/hotspot/gtest/memory/test_is_metaspace_obj.cpp Changeset: f2c23221bbd5 Author: gadams Date: 2019-04-05 07:10 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f2c23221bbd5 8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3 Reviewed-by: cjplummer, jcbeyler ! test/lib/jdk/test/lib/apps/LingeredApp.java Changeset: d9b46b7de028 Author: adinn Date: 2019-04-05 10:01 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/d9b46b7de028 8221477: Inject os/cpu-specific constants into Unsafe from JVM Summary: Initialize Unsafe os/cpu-specific constants using injection instead of native callouts Reviewed-by: stuefe, coleenp, dholmes, plevart ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/systemDictionary.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/prims/unsafe.cpp ! src/hotspot/share/runtime/thread.cpp ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java + src/java.base/share/classes/jdk/internal/misc/UnsafeConstants.java ! test/jdk/java/lang/reflect/AccessibleObject/CanAccessTest.java Changeset: 23a04fe2aca2 Author: aph Date: 2019-04-05 09:53 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/23a04fe2aca2 8219993: AArch64: Compiled CI stubs are unsafely modified Reviewed-by: adinn ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp Changeset: 03ea2b6428f0 Author: bpb Date: 2019-04-05 08:37 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/03ea2b6428f0 8221597: A typo in the Java API doc for File.getUsableSpace() Reviewed-by: lancea, darcy ! src/java.base/share/classes/java/io/File.java Changeset: 172f929786ea Author: jjg Date: 2019-04-05 11:17 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/172f929786ea 8221997: fix headings in jdk.javadoc Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/doclet/package-info.java Changeset: dfba4e321ab3 Author: xuelei Date: 2019-04-05 11:28 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/dfba4e321ab3 8221882: Use fiber-friendly java.util.concurrent.locks in JSSE Reviewed-by: alanb, dfuchs ! src/java.base/share/classes/javax/net/ssl/SSLContext.java ! src/java.base/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/java.base/share/classes/javax/net/ssl/SSLSocketFactory.java ! src/java.base/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java ! src/java.base/share/classes/sun/security/ssl/BaseSSLSocketImpl.java ! src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java ! src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/EphemeralKeyManager.java ! src/java.base/share/classes/sun/security/ssl/HelloCookieManager.java ! src/java.base/share/classes/sun/security/ssl/InputRecord.java ! src/java.base/share/classes/sun/security/ssl/OutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/java.base/share/classes/sun/security/ssl/TransportContext.java ! src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java ! src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: 259b40b4d473 Author: jjg Date: 2019-04-05 15:57 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/259b40b4d473 8221871: javadoc should not set role=region on
elements Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java ! test/langtools/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testUseOption/TestUseOption.java Changeset: a5da0277d9bb Author: mchung Date: 2019-04-06 21:05 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a5da0277d9bb 8220282: Add MethodHandle tests on accessing final fields Reviewed-by: lancea ! test/jdk/java/lang/invoke/MethodHandlesGeneralTest.java ! test/jdk/java/lang/invoke/MethodHandlesTest.java Changeset: b16e8a886fc3 Author: mchung Date: 2019-04-06 21:16 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b16e8a886fc3 8221530: Caller sensitive methods not handling caller = null when invoked by JNI code with no java frames on stack Reviewed-by: alanb, dholmes, sundar ! make/test/JtregNativeJdk.gmk ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java ! src/java.base/share/classes/jdk/internal/reflect/Reflection.java + test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java + test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c Changeset: cfe96d1d0715 Author: mchung Date: 2019-04-07 03:00 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/cfe96d1d0715 8222078: test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c build fails after 8221530 Reviewed-by: lancea, dholmes ! test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c Changeset: cd2879e0c165 Author: mchung Date: 2019-04-07 18:09 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/cd2879e0c165 8222082: Build of test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c still failing on Windows Reviewed-by: alanb, dholmes ! make/test/JtregNativeJdk.gmk Changeset: ac4b327623f6 Author: shade Date: 2019-04-07 13:28 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/ac4b327623f6 8221917: serviceability/sa/TestPrintMdo.java fails on 32-bit platforms Reviewed-by: cjplummer, dholmes ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/DataLayout.java Changeset: 8d51a40fbd23 Author: shade Date: 2019-04-07 13:28 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/8d51a40fbd23 8222032: x86_32 fails with "wrong size of mach node" on AVX-512 machine Reviewed-by: kvn, vlivanov ! src/hotspot/cpu/x86/x86_32.ad Changeset: 40658cb7f47a Author: ngasson Date: 2019-04-08 09:31 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/40658cb7f47a 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 Reviewed-by: aph, sgehwolf, mseledtsov ! test/lib/jdk/test/lib/containers/docker/DockerfileConfig.java Changeset: 0d7fb7f07134 Author: clanger Date: 2019-04-08 06:56 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/0d7fb7f07134 8221880: Better customization for Windows RC properties FileDescription and ProductName Reviewed-by: erikj ! make/autoconf/flags-other.m4 ! make/autoconf/jdk-version.m4 ! make/autoconf/spec.gmk.in Changeset: 7b5e2bc79e68 Author: dpochepk Date: 2019-04-08 15:54 +0300 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/7b5e2bc79e68 8221995: AARCH64: problems with CAS instructions encoding Reviewed-by: aph ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp Changeset: 22ee881e6a74 Author: shade Date: 2019-04-08 15:25 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/22ee881e6a74 8222111: exeCallerAccessTest.c fails to build: control reaches end of non-void function Reviewed-by: alanb, dholmes ! test/jdk/java/lang/reflect/exeCallerAccessTest/exeCallerAccessTest.c Changeset: 542735f2a53e Author: erikj Date: 2019-04-05 06:48 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/542735f2a53e 8221907: make reconfigure breaks when configured with relative paths Reviewed-by: dholmes ! make/Init.gmk ! make/autoconf/basics.m4 ! make/autoconf/basics_windows.m4 ! make/autoconf/spec.gmk.in ! make/autoconf/toolchain_windows.m4 Changeset: a8db7fd22fd1 Author: mullan Date: 2019-04-08 12:19 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a8db7fd22fd1 8222089: [TESTBUG] sun/security/lib/cacerts/VerifyCACerts.java fails due to cert within 90-day expiry window Reviewed-by: xuelei ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: 40dc805f4709 Author: rkennke Date: 2019-04-08 18:42 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/40dc805f4709 8222125: Shenandoah: Crash when running with ShenandoahParallelSafepointThreads=1 Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp + test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java Changeset: 0608ef3a7740 Author: rkennke Date: 2019-04-08 18:42 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/0608ef3a7740 8222129: Shenandoah: Missing CompareAndSwapP/N case in get_barrier_strength() Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Changeset: e5713cefcf41 Author: sgroeger Date: 2019-04-08 15:01 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/e5713cefcf41 8222027: java/util/logging/LogManager/TestLoggerNames.java generates intermittent ClassCastException Summary: Make a strong reference to TestLogger and dont fetch it from LogManager Reviewed-by: dfuchs ! test/jdk/java/util/logging/LogManager/TestLoggerNames.java Changeset: 6733a9176cce Author: dtitov Date: 2019-04-08 17:09 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/6733a9176cce 8221730: jcmd process name matching broken Reviewed-by: jcbeyler, dholmes, cjplummer ! src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java ! test/hotspot/jtreg/serviceability/dcmd/framework/HelpTest.java ! test/hotspot/jtreg/serviceability/dcmd/framework/InvalidCommandTest.java - test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java + test/hotspot/jtreg/serviceability/dcmd/framework/TestProcessJarLauncher.java ! test/hotspot/jtreg/serviceability/dcmd/framework/TestProcessLauncher.java + test/hotspot/jtreg/serviceability/dcmd/framework/TestProcessModuleLauncher.java ! test/hotspot/jtreg/serviceability/dcmd/framework/VMVersionTest.java + test/hotspot/jtreg/serviceability/dcmd/framework/process/TestJavaProcess.java ! test/jdk/sun/tools/jcmd/TestProcessHelper.java Changeset: ba0d64652b86 Author: zgu Date: 2019-04-08 13:22 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/ba0d64652b86 8222086: CodeCache::UnloadingScope needs to preserve and restore previous IsUnloadingBehavior Reviewed-by: eosterlund ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp Changeset: 2020eaa9ca9f Author: mullan Date: 2019-04-08 13:33 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/2020eaa9ca9f 8222133: Add temporary exceptions for root certs that are due to expire soon Reviewed-by: xuelei ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: b9c461c02f7c Author: shade Date: 2019-04-08 19:43 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b9c461c02f7c 8222130: Shenandoah should verify roots after pre-evacuation Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.hpp Changeset: 1f8938ce8564 Author: epavlova Date: 2019-04-08 11:11 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/1f8938ce8564 8216551: GraalUnitTestLauncher should be executed as '@run driver' Reviewed-by: dlong, kvn ! test/hotspot/jtreg/ProblemList-graal.txt ! test/hotspot/jtreg/compiler/graalunit/ApiDirectivesTest.java ! test/hotspot/jtreg/compiler/graalunit/ApiTest.java ! test/hotspot/jtreg/compiler/graalunit/AsmAarch64Test.java ! test/hotspot/jtreg/compiler/graalunit/AsmAmd64Test.java ! test/hotspot/jtreg/compiler/graalunit/AsmSparcTest.java ! test/hotspot/jtreg/compiler/graalunit/CollectionsTest.java ! test/hotspot/jtreg/compiler/graalunit/CoreAmd64Test.java ! test/hotspot/jtreg/compiler/graalunit/CoreTest.java ! test/hotspot/jtreg/compiler/graalunit/DebugTest.java ! test/hotspot/jtreg/compiler/graalunit/EA9Test.java ! test/hotspot/jtreg/compiler/graalunit/EATest.java ! test/hotspot/jtreg/compiler/graalunit/GraphTest.java ! test/hotspot/jtreg/compiler/graalunit/HotspotAmd64Test.java ! test/hotspot/jtreg/compiler/graalunit/HotspotJdk9Test.java ! test/hotspot/jtreg/compiler/graalunit/HotspotLirTest.java ! test/hotspot/jtreg/compiler/graalunit/HotspotSparcTest.java ! test/hotspot/jtreg/compiler/graalunit/HotspotTest.java ! test/hotspot/jtreg/compiler/graalunit/Jtt.MicroTest.java ! test/hotspot/jtreg/compiler/graalunit/JttBackendTest.java ! test/hotspot/jtreg/compiler/graalunit/JttBytecodeTest.java ! test/hotspot/jtreg/compiler/graalunit/JttExceptTest.java ! test/hotspot/jtreg/compiler/graalunit/JttHotpathTest.java ! test/hotspot/jtreg/compiler/graalunit/JttHotspotTest.java ! test/hotspot/jtreg/compiler/graalunit/JttJdkTest.java ! test/hotspot/jtreg/compiler/graalunit/JttLangALTest.java ! test/hotspot/jtreg/compiler/graalunit/JttLangMathALTest.java ! test/hotspot/jtreg/compiler/graalunit/JttLangMathMZTest.java ! test/hotspot/jtreg/compiler/graalunit/JttLangNZTest.java ! test/hotspot/jtreg/compiler/graalunit/JttLoopTest.java ! test/hotspot/jtreg/compiler/graalunit/JttOptimizeTest.java ! test/hotspot/jtreg/compiler/graalunit/JttReflectAETest.java ! test/hotspot/jtreg/compiler/graalunit/JttReflectFieldGetTest.java ! test/hotspot/jtreg/compiler/graalunit/JttReflectFieldSetTest.java ! test/hotspot/jtreg/compiler/graalunit/JttReflectGZTest.java ! test/hotspot/jtreg/compiler/graalunit/JttThreadsTest.java ! test/hotspot/jtreg/compiler/graalunit/LirJttTest.java ! test/hotspot/jtreg/compiler/graalunit/LirTest.java ! test/hotspot/jtreg/compiler/graalunit/LoopTest.java ! test/hotspot/jtreg/compiler/graalunit/NodesTest.java ! test/hotspot/jtreg/compiler/graalunit/OptionsTest.java ! test/hotspot/jtreg/compiler/graalunit/PhasesCommonTest.java ! test/hotspot/jtreg/compiler/graalunit/Replacements12Test.java ! test/hotspot/jtreg/compiler/graalunit/Replacements9Test.java ! test/hotspot/jtreg/compiler/graalunit/ReplacementsTest.java ! test/hotspot/jtreg/compiler/graalunit/TestPackages.txt ! test/hotspot/jtreg/compiler/graalunit/UtilTest.java ! test/hotspot/jtreg/compiler/graalunit/generateTests.sh ! test/jdk/ProblemList-graal.txt Changeset: c4f16445675a Author: tschatzl Date: 2019-04-08 20:37 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/c4f16445675a 8218668: Clean up evacuation of optional collection set Summary: Better integrate optional collection set evacuation into the existing evacuation scheme, fixing a few minor issues with the initial implementation. Reviewed-by: kbarrett, sangheki ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1CollectionSet.hpp ! src/hotspot/share/gc/g1/g1CollectionSetCandidates.cpp ! src/hotspot/share/gc/g1/g1CollectionSetCandidates.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp ! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1OopStarChunkedList.cpp ! src/hotspot/share/gc/g1/g1OopStarChunkedList.hpp ! src/hotspot/share/gc/g1/g1OopStarChunkedList.inline.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1RemSet.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/shared/workerDataArray.hpp ! src/hotspot/share/gc/shared/workerDataArray.inline.hpp Changeset: 58751415d5f8 Author: tschatzl Date: 2019-04-08 21:01 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/58751415d5f8 8222105: Add "use_" prefix to G1Policy::adaptive_young_list_length Summary: Improve naming of G1Policy::adaptive_young_list_length to improve readability. Reviewed-by: kbarrett ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp ! src/hotspot/share/gc/g1/g1Policy.cpp ! src/hotspot/share/gc/g1/g1Policy.hpp ! src/hotspot/share/gc/g1/g1YoungGenSizer.cpp ! src/hotspot/share/gc/g1/g1YoungGenSizer.hpp ! src/hotspot/share/gc/g1/g1YoungRemSetSamplingThread.cpp Changeset: 0c5d713cf43f Author: sangheki Date: 2019-04-08 12:15 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/0c5d713cf43f 8218049: Survivor MemoryMXBean used() size granularity is region based Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1EdenRegions.hpp ! src/hotspot/share/gc/g1/g1MonitoringSupport.cpp ! src/hotspot/share/gc/g1/g1MonitoringSupport.hpp ! src/hotspot/share/gc/g1/g1SurvivorRegions.cpp ! src/hotspot/share/gc/g1/g1SurvivorRegions.hpp ! src/hotspot/share/gc/g1/vmStructs_g1.hpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/gc/survivorAlignment/TestAllocationInEden.java ! test/hotspot/jtreg/gc/survivorAlignment/TestPromotionFromEdenToTenured.java ! test/hotspot/jtreg/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterFullGC.java ! test/hotspot/jtreg/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java ! test/hotspot/jtreg/gc/survivorAlignment/TestPromotionLABLargeSurvivorAlignment.java ! test/hotspot/jtreg/gc/survivorAlignment/TestPromotionToSurvivor.java Changeset: b02d1d829b09 Author: dholmes Date: 2019-04-08 17:30 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b02d1d829b09 8218458: [TESTBUG] runtime/NMT/CheckForProperDetailStackTrace.java fails with Expected stack trace missing from output Reviewed-by: cjplummer, zgu ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java Changeset: 8592226f5cd3 Author: dholmes Date: 2019-04-08 21:39 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/8592226f5cd3 8221584: SIGSEGV in os::PlatformEvent::unpark() in JvmtiRawMonitor::raw_exit while posting method exit event Reviewed-by: dholmes, dcubed Contributed-by: robbin.ehn at oracle.com, stefan.karlsson at oracle.com ! src/hotspot/share/prims/jvmtiRawMonitor.cpp Changeset: 14986fb09d9a Author: mbaesken Date: 2019-04-08 14:36 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/14986fb09d9a 8221535: add steal tick related information to hs_error file [linux] Reviewed-by: dholmes, goetz ! src/hotspot/os/aix/os_perf_aix.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp ! src/hotspot/os/linux/os_perf_linux.cpp Changeset: f22759e92191 Author: redestad Date: 2019-04-09 11:40 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f22759e92191 8222144: BuiltinClassLoader should create the CodeSource for jrt URLs lazily Reviewed-by: alanb ! src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java Changeset: 89295131e353 Author: mullan Date: 2019-04-09 08:56 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/89295131e353 8020637: Permissions.readObject doesn't enforce proper Class to PermissionCollection mappings Reviewed-by: weijun ! src/java.base/share/classes/java/security/Permissions.java + test/jdk/java/security/Permissions/DeserializeInvalidPermissions.java Changeset: e437ad5643d6 Author: jiefu Date: 2019-04-09 06:11 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/e437ad5643d6 8221894: Add comments for docker tests in the test doc Reviewed-by: erikj, dholmes ! doc/testing.html ! doc/testing.md Changeset: 0fa2903fb272 Author: fyang Date: 2019-04-08 14:40 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/0fa2903fb272 8221658: aarch64: add necessary predicate for ubfx patterns Reviewed-by: aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_ad.m4 Changeset: 805584336738 Author: smarks Date: 2019-04-09 09:49 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/805584336738 8221924: get(null) on single-entry unmodifiable Map returns null instead of throwing NPE Reviewed-by: redestad, lancea ! src/java.base/share/classes/java/util/ImmutableCollections.java ! test/jdk/java/util/Map/MapFactories.java Changeset: 20f7bbfc61d3 Author: bpb Date: 2019-04-09 12:17 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/20f7bbfc61d3 8221852: SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE should be selected at runtime, not build time Reviewed-by: alanb, shade ! src/java.base/windows/classes/sun/nio/fs/WindowsConstants.java ! src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c Changeset: 511be32f3863 Author: shade Date: 2019-04-09 21:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/511be32f3863 8222185: Shenandoah should report "committed" as capacity Reviewed-by: zgu, rkennke ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMonitoringSupport.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp Changeset: cdc54443fee5 Author: shade Date: 2019-04-09 21:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/cdc54443fee5 8222186: Shenandoah should not uncommit below minimum heap size Reviewed-by: zgu, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestMemoryMXBeans.java Changeset: 6ad0281a654e Author: rkennke Date: 2019-04-09 23:36 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/6ad0281a654e 8222227: Shenandoah: Fix Traversal GC weak roots handling in final-traversal pause Reviewed-by: shade, zgu ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp Changeset: 625f49b603f0 Author: dcubed Date: 2019-04-09 18:26 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/625f49b603f0 8222229: ProblemList compiler/jsr292/InvokerSignatureMismatch.java Reviewed-by: iignatyev ! test/hotspot/jtreg/ProblemList-graal.txt Changeset: f847a42ddc01 Author: igerasim Date: 2019-04-09 16:32 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f847a42ddc01 8221430: StringBuffer(CharSequence) constructor truncates when -XX:-CompactStrings specified Reviewed-by: igerasim, rriggs Contributed-by: Andrew Leonard , Ivan Gerasimov ! src/java.base/share/classes/java/lang/AbstractStringBuilder.java ! src/java.base/share/classes/java/lang/StringBuffer.java ! src/java.base/share/classes/java/lang/StringBuilder.java ! test/jdk/java/lang/StringBuffer/CompactStringBuffer.java ! test/micro/org/openjdk/bench/java/lang/StringBuilders.java Changeset: c914170817d4 Author: jcbeyler Date: 2019-04-09 19:34 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/c914170817d4 8221853: Data race in compile broker (set_last_compile) Summary: Remove the debug code provoking it Reviewed-by: kvn, thartmann ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp Changeset: ac20c3bdc55d Author: valeriep Date: 2019-04-10 02:35 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/ac20c3bdc55d 8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange Summary: Add internal Signature init methods to select provider based on both key and parameter Reviewed-by: xuelei ! src/java.base/share/classes/java/security/Signature.java ! src/java.base/share/classes/java/security/SignatureSpi.java ! src/java.base/share/classes/java/security/cert/X509CRL.java ! src/java.base/share/classes/java/security/cert/X509Certificate.java + src/java.base/share/classes/jdk/internal/access/JavaSecuritySignatureAccess.java ! src/java.base/share/classes/jdk/internal/access/SharedSecrets.java ! src/java.base/share/classes/sun/security/pkcs/SignerInfo.java ! src/java.base/share/classes/sun/security/pkcs10/PKCS10.java ! src/java.base/share/classes/sun/security/ssl/SignatureScheme.java ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/util/SignatureUtil.java ! src/java.base/share/classes/sun/security/x509/X509CRLImpl.java ! src/java.base/share/classes/sun/security/x509/X509CertImpl.java + test/jdk/java/security/Signature/SignatureGetInstance.java ! test/jdk/sun/security/util/misc/SetNullSigParams.java Changeset: 72f05350b4b3 Author: valeriep Date: 2019-04-10 02:41 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/72f05350b4b3 Merge Changeset: ddc19ea5059c Author: mbaesken Date: 2019-04-10 08:51 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/ddc19ea5059c 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 Reviewed-by: dholmes, mdoerr ! src/hotspot/cpu/ppc/vm_version_ppc.cpp ! src/hotspot/cpu/ppc/vm_version_ppc.hpp ! src/hotspot/cpu/s390/vm_version_s390.cpp ! src/hotspot/cpu/s390/vm_version_s390.hpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/runtime/vm_version.cpp ! src/hotspot/share/runtime/vm_version.hpp Changeset: 7fd299216e97 Author: redestad Date: 2019-04-10 12:05 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/7fd299216e97 8221836: Avoid recalculating String.hash when zero Reviewed-by: jrose, adinn Contributed-by: peter.levart at gmail.com, claes.redestad at oracle.com ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/javaClasses.inline.hpp ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp ! src/java.base/share/classes/java/lang/String.java Changeset: 4fa1fd8bc21e Author: smonteith Date: 2019-04-09 12:47 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/4fa1fd8bc21e 8222180: ZGC: ZForwarding::verify() failing when checking for duplicates Reviewed-by: pliden, eosterlund ! src/hotspot/share/gc/z/zForwarding.cpp Changeset: 25199b48f34f Author: pliden Date: 2019-04-10 12:45 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/25199b48f34f 8221984: ZGC: Clean up ZOop Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/z/zBarrier.cpp ! src/hotspot/share/gc/z/zBarrier.inline.hpp ! src/hotspot/share/gc/z/zHeap.inline.hpp ! src/hotspot/share/gc/z/zLiveMap.inline.hpp ! src/hotspot/share/gc/z/zMark.cpp ! src/hotspot/share/gc/z/zOop.hpp ! src/hotspot/share/gc/z/zOop.inline.hpp ! src/hotspot/share/gc/z/zOopClosures.cpp ! src/hotspot/share/gc/z/zUtils.inline.hpp Changeset: a84fefde0543 Author: rkennke Date: 2019-04-10 13:21 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a84fefde0543 8222259: Shenandoah: Pre-evacuate string-dedup roots in Traversal GC Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp Changeset: bf07e140c49c Author: erikj Date: 2019-04-10 07:04 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/bf07e140c49c 8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC Reviewed-by: tbell, ysuenaga ! make/autoconf/basics.m4 ! make/autoconf/flags-cflags.m4 ! make/autoconf/spec.gmk.in ! make/common/NativeCompilation.gmk ! make/hotspot/gensrc/GensrcAdlc.gmk ! make/hotspot/gensrc/GensrcDtrace.gmk ! make/hotspot/lib/CompileDtraceLibraries.gmk ! make/hotspot/lib/CompileGtest.gmk ! make/hotspot/lib/CompileJvm.gmk ! src/hotspot/share/utilities/exceptions.hpp Changeset: a805bf992bf1 Author: rschmelter Date: 2019-04-10 05:15 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a805bf992bf1 8222264: Windows incremental build is broken with JDK-8217728 Reviewed-by: erikj, clanger ! make/common/NativeCompilation.gmk Changeset: 9d0ae9508d53 Author: redestad Date: 2019-04-10 20:03 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/9d0ae9508d53 8222029: Optimize Math.floorMod Reviewed-by: aph, darcy ! src/java.base/share/classes/java/lang/Math.java ! test/jdk/java/lang/Math/DivModTests.java + test/micro/org/openjdk/bench/java/lang/MathBench.java Changeset: db8467d25e8b Author: rkennke Date: 2019-04-11 11:40 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/db8467d25e8b Merge ! .hgtags ! make/hotspot/lib/JvmFeatures.gmk ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetC1_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp ! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetC1_x86.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp ! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahEvacOOMHandler.hpp ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMonitoringSupport.cpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRuntime.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRuntime.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.hpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! src/hotspot/share/gc/z/zForwarding.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestMemoryMXBeans.java ! test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java ! test/hotspot/jtreg/gc/survivorAlignment/TestAllocationInEden.java ! test/hotspot/jtreg/gc/survivorAlignment/TestPromotionFromEdenToTenured.java ! test/hotspot/jtreg/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterFullGC.java ! test/hotspot/jtreg/gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java ! test/hotspot/jtreg/gc/survivorAlignment/TestPromotionToSurvivor.java - test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java From shade at redhat.com Thu Apr 11 10:21:12 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 11 Apr 2019 12:21:12 +0200 Subject: RFR: Clean up differences against upstream Message-ID: <2694197e-e776-9890-9d89-5060fec5265c@redhat.com> I see the post-merge differences here: https://builds.shipilev.net/patch-openjdk-shenandoah-jdk/ Strdedup tests are still in quarantine, and there is a minor whitespace difference. I basically "patch -p1 -R"-ed the webrev above, omitting .hgtags change: diff -r db8467d25e8b src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp --- a/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp Thu Apr 11 11:40:30 2019 +0200 +++ b/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp Thu Apr 11 12:20:10 2019 +0200 @@ -47,4 +47,5 @@ ShenandoahNone, }; + static bool verify_helper(Node* in, Node_Stack& phis, VectorSet& visited, verify_type t, bool trace, Unique_Node_List& barriers_used); static void report_verify_failure(const char* msg, Node* n1 = NULL, Node* n2 = NULL); diff -r db8467d25e8b test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt Thu Apr 11 11:40:30 2019 +0200 +++ b/test/hotspot/jtreg/ProblemList.txt Thu Apr 11 12:20:10 2019 +0200 @@ -138,11 +138,4 @@ ############################################################################# -# :hotspot_gc_shenandoah - -gc/shenandoah/TestStringDedup.java 8220671,8221102 generic-all -gc/shenandoah/TestStringDedupStress.java 8220671,8221102 generic-all - -############################################################################# - # :hotspot_misc Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Thu Apr 11 10:26:18 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 11 Apr 2019 12:26:18 +0200 Subject: RFR: Clean up differences against upstream In-Reply-To: <2694197e-e776-9890-9d89-5060fec5265c@redhat.com> References: <2694197e-e776-9890-9d89-5060fec5265c@redhat.com> Message-ID: Yes, thanks! Roman > I see the post-merge differences here: > https://builds.shipilev.net/patch-openjdk-shenandoah-jdk/ > > Strdedup tests are still in quarantine, and there is a minor > whitespace difference. I basically > "patch -p1 -R"-ed the webrev above, omitting .hgtags change: > > diff -r db8467d25e8b > src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp > --- a/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp Thu > Apr 11 11:40:30 2019 +0200 > +++ b/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp Thu > Apr 11 12:20:10 2019 +0200 > @@ -47,4 +47,5 @@ > ShenandoahNone, > }; > + > static bool verify_helper(Node* in, Node_Stack& phis, VectorSet& > visited, verify_type t, bool > trace, Unique_Node_List& barriers_used); > static void report_verify_failure(const char* msg, Node* n1 = > NULL, Node* n2 = NULL); > diff -r db8467d25e8b test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt Thu Apr 11 11:40:30 > 2019 +0200 > +++ b/test/hotspot/jtreg/ProblemList.txt Thu Apr 11 12:20:10 > 2019 +0200 > @@ -138,11 +138,4 @@ > #################################################################### > ######### > > -# :hotspot_gc_shenandoah > - > -gc/shenandoah/TestStringDedup.java 822067 > 1,8221102 generic-all > -gc/shenandoah/TestStringDedupStress.java 822067 > 1,8221102 generic-all > - > -#################################################################### > ######### > - > # :hotspot_misc > > > Testing: hotspot_gc_shenandoah > From shade at redhat.com Thu Apr 11 11:09:11 2019 From: shade at redhat.com (shade at redhat.com) Date: Thu, 11 Apr 2019 11:09:11 +0000 Subject: hg: shenandoah/jdk: Clean up differences against upstream Message-ID: <201904111109.x3BB9BTK005138@aojmv0008.oracle.com> Changeset: 054ecf96a44f Author: shade Date: 2019-04-11 12:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/054ecf96a44f Clean up differences against upstream ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp ! test/hotspot/jtreg/ProblemList.txt From zgu at redhat.com Fri Apr 12 13:43:25 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 12 Apr 2019 09:43:25 -0400 Subject: RFR(T) 8222403: Shenandoah: Remove ShenandoahAlwaysTrueClosure, use AlwaysTrueClosure instead Message-ID: <7bc1d63e-68a6-3875-07c8-197cd9ec6974@redhat.com> Please review this trivial cleanup, to remove deplicated closure. Bug: https://bugs.openjdk.java.net/browse/JDK-8222403 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222403/webrev.00/ Test: hotspot_gc_shenandoah: Linux 64 (fastdebug and release) Thanks, -Zhengyu From shade at redhat.com Fri Apr 12 13:44:43 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 12 Apr 2019 15:44:43 +0200 Subject: RFR(T) 8222403: Shenandoah: Remove ShenandoahAlwaysTrueClosure, use AlwaysTrueClosure instead In-Reply-To: <7bc1d63e-68a6-3875-07c8-197cd9ec6974@redhat.com> References: <7bc1d63e-68a6-3875-07c8-197cd9ec6974@redhat.com> Message-ID: <43e0b435-e968-eec1-25a9-b95d95f91c50@redhat.com> On 4/12/19 3:43 PM, Zhengyu Gu wrote: > Please review this trivial cleanup, to remove deplicated closure. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222403 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222403/webrev.00/ > > Test: > ? hotspot_gc_shenandoah: Linux 64 (fastdebug and release) Looks good! -Aleksey From zgu at redhat.com Fri Apr 12 20:18:54 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 12 Apr 2019 16:18:54 -0400 Subject: RFR(T) 8222419: Shenandoah: Remove unused _par_state_string in ShenandoahRootProcessor Message-ID: <491676bc-7b1a-4405-a9bc-970c23eee884@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8222419 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222419/webrev.00/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu From rkennke at redhat.com Fri Apr 12 20:27:36 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 12 Apr 2019 22:27:36 +0200 Subject: RFR(T) 8222419: Shenandoah: Remove unused _par_state_string in ShenandoahRootProcessor In-Reply-To: <491676bc-7b1a-4405-a9bc-970c23eee884@redhat.com> References: <491676bc-7b1a-4405-a9bc-970c23eee884@redhat.com> Message-ID: <81405daee0cf5dfe7bb06daa945bcfe69545b71c.camel@redhat.com> Ok, looks good! Thanks, Roman > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222419 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222419/webrev.00/ > > > Test: > hotspot_gc_shenandoah > > Thanks, > > -Zhengyu > From zgu at redhat.com Fri Apr 12 23:16:01 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 12 Apr 2019 19:16:01 -0400 Subject: RFR(S) 8222425: Shenandoah: Move commonly used closures to separate files Message-ID: Please review this patch that refactors some shared closures to separate files. Bug: https://bugs.openjdk.java.net/browse/JDK-8222425 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222425/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu From zgu at redhat.com Mon Apr 15 14:53:43 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 15 Apr 2019 10:53:43 -0400 Subject: RFR(T) 8222490: Shenandoah: Remove unused _par_state_string in ShenandoahRootEvacuator Message-ID: Missed in early cleanup. Bug: https://bugs.openjdk.java.net/browse/JDK-8222490 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222490/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu From shade at redhat.com Mon Apr 15 16:15:26 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 15 Apr 2019 18:15:26 +0200 Subject: RFR(T) 8222490: Shenandoah: Remove unused _par_state_string in ShenandoahRootEvacuator In-Reply-To: References: Message-ID: <5480f95a-64bc-e960-d484-8578748ad250@redhat.com> On 4/15/19 4:53 PM, Zhengyu Gu wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8222490 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222490/webrev.00/ Looks good. -Aleksey From shade at redhat.com Mon Apr 15 16:20:30 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 15 Apr 2019 18:20:30 +0200 Subject: RFR(S) 8222425: Shenandoah: Move commonly used closures to separate files In-Reply-To: References: Message-ID: <6a5a8863-990b-56b2-5851-3cfa428390d1@redhat.com> On 4/13/19 1:16 AM, Zhengyu Gu wrote: > Please review this patch that refactors some shared closures to separate files. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222425 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222425/webrev.00/ Looks okay. Have you tested this without PCH? Are they actually used somewhere outside of ShenandoahHeap, e.g. in shConcurrentMark/shTraversalGC? -Aleksey From zgu at redhat.com Mon Apr 15 17:05:55 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 15 Apr 2019 13:05:55 -0400 Subject: RFR(S) 8222425: Shenandoah: Move commonly used closures to separate files In-Reply-To: <6a5a8863-990b-56b2-5851-3cfa428390d1@redhat.com> References: <6a5a8863-990b-56b2-5851-3cfa428390d1@redhat.com> Message-ID: On 4/15/19 12:20 PM, Aleksey Shipilev wrote: > On 4/13/19 1:16 AM, Zhengyu Gu wrote: >> Please review this patch that refactors some shared closures to separate files. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222425 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222425/webrev.00/ > > Looks okay. Have you tested this without PCH? Are they actually used somewhere outside of > ShenandoahHeap, e.g. in shConcurrentMark/shTraversalGC? Yes, I always configure fastdebug with PCH and release without it. Thanks, -Zhengyu > > -Aleksey > From shade at redhat.com Tue Apr 16 22:41:16 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 17 Apr 2019 00:41:16 +0200 Subject: RFC/RFR: Pick up jdk-11.0.3+7 to sh/jdk11 Message-ID: <03589cbb-abdd-dcd6-6ff5-ddecfbd8b647@redhat.com> Upstream^W We have pushed the jdk-11.0.3+7 tag upstream to jdk-updates/jdk11u. Let's pick it up to sh/jdk11. The merge is trivial, and includes all outstanding patches that landed in recently released 11u. Summary of changes: http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b7/changesets.txt Webrev (closely matches the one pushed to upstream 11u): http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b7/webrev.01/ Changeset graph: http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b7/hg-graph-log.txt Some explanation here: we have Shenandoah patches pushed after +6, which did not end up in +7 RPMs. Therefore, we merge +7 from +6, and then merge outstanding Shenandoah head with +7. This would match the tags with what was actually shipped. Testing: tier1_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From gnu.andrew at redhat.com Tue Apr 16 23:06:19 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 17 Apr 2019 00:06:19 +0100 Subject: [RFR] [8u] 8u212 Upstream Sync Message-ID: <89da01a7-8f94-c39c-2caa-da42684c58c8@redhat.com> I propose to merge: jdk8u212-b02 to create aarch64-shenandoah-jdk8u212-b02 jdk8u212-b03 to create aarch64-shenandoah-jdk8u212-b03 jdk8u212-b04 to create aarch64-shenandoah-jdk8u212-b04 Of particular note is "S8213419: [AArch64] C2 may hang in MulLNode::Ideal()/MulINode::Ideal() with gcc 8.2.1", which had to be added to the 8u upstream base and is taken from the original 11u version of the same fix. As webrevs for such merges tend not to illustrate the actual changes taking place very well, I have instead just include the merge changesets this time and saved on uploading about a gigabyte of largely useless data... b02: http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/root/merge.changeset b03: http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/root/merge.changeset b04: http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/root/merge.changeset Changes in aarch64-shenandoah-jdk8u212-b02: - S7127191: SA JSDB does not display native symbols correctly for transported Linux cores - S8027434: "-XX:OnOutOfMemoryError" uses fork instead of vfork - S8028254: gc/arguments/TestMinInitialErgonomics.java failed with unexpected initial heap size - S8029661: Support TLS v1.2 algorithm in SunPKCS11 provider - S8043387: java/time/test/java/util/TestFormatter.java failed. - S8044047: Missing null pointer checks for streams - S8059038: Create new launcher for SA tools - S8065749: [TESTBUG]: gc/arguments/TestG1HeapRegionSize.java fails at nightly - S8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases - S8076164: [JTextField] When input too long Thai character, cursor's behavior is odd - S8076274: [TESTBUG] Remove @ignore from runtime\NMT\JcmdDetailDiff.java - S8076458: java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java timeout - S8077608: [TESTBUG] Enable Hotspot jtreg tests to run in agentvm mode - S8080932: [TEST_BUG] Test java/awt/BasicStroke/DashStrokeTest.java fails with Bad script error due to improper @run notation - S8129822: Define "headful" jtreg keyword - S8132136: [PIT] RTL orientation in JEditorPane is broken - S8132985: Crash in freetypescaler.c due to double free - S8133108: [PIT] Container size is wrong in JEditorPane - S8133731: [TEST_BUG] Unmappable in ASCII character such as Thai should be escaped in the regtests targeted for a regular non-I18n runs - S8133802: replace some tags (obsolete in html5) in security-libs docs - S8133984: print_compressed_class_space() is only defined in 64-bit VM - S8139803: Fix for 8132985 breaks OpenJDK build on windows. - S8141491: Unaligned memory access in Bits.c - S8145096: Undefined behaviour in HotSpot - S8148928: java/util/stream/test/**/SequentialOpTest.java timed out intermittently - S8164656: krb5 does not retry if TCP connection timeouts - S8170681: Remove fontconfig header files from JDK source tree - S8175120: Remove old tests on kdc timeout policy - S8180469: Wrong short form text for supplemental Japanese era - S8180904: Hotspot tests running with -agentvm failing due to classpath - S8184309: Build warnings from GCC 7.1 on Fedora 26 - S8185975: PPC64: Fix vsldoi interface according to the ISA - S8187364: Unable to enter zero width non-joiner (ZWNJ) symbol in Swing text component - S8189761: COMPANY_NAME, IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag - S8193764: Cannot set COMPANY_NAME when configuring a build - S8195153: [test] runtime/6981737/Test6981737.java shouldn't check 'java.vendor' and 'java.vm.vendor' properties - S8197429: Increased stack guard causes segfaults on x86-32 - S8200109: NMT: diff_malloc_site assert(early->flags() == current->flags(), "Must be the same memory type") - S8200115: System property java.vm.vendor value includes quotation marks - S8202088: Japanese new era implementation - S8204142: AWT hang occurs when sequenced events arrive out of sequence in multiple AppContexts - S8206075: On x86, assert on unbound assembler Labels used as branch targets - S8206120: Add test cases for lenient Japanese era parsing - S8207070: Webstart app popup on wrong screen in a one-screen setup changing to multi-monitor - S8207152: Placeholder for Japanese new era should be two characters - S8207258: Distrust TLS server certificates anchored by Symantec Root CAs - S8208480: Test failure: assert(is_bound() || is_unused()) after JDK-8206075 in C1 - S8210647: libsaproc is being compiled without optimization - S8211106: [windows] Update OS detection code to recognize Windows Server 2019 - S8211231: BarrierSetC1::generate_referent_check() confuses register allocator - S8211382: ISO2022JP and GB18030 NIO converter issues - S8211398: Square character support for the Japanese new era - S8211435: Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException: null source - S8211926: Catastrophic size_t underflow in BitMap::*_large methods - S8212110: Build of saproc.dll broken on Windows 32 bit after JDK-8210647 - S8212178: Soft reference reclamation race in com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator - S8212914: Test javax/imageio/plugins/bmp/BMP8BPPLoadTest.java fails - S8212941: Support new Japanese era in java.time.chrono.JapaneseEra - S8213151: [AIX] Some class library files are missing the Classpath exception - S8213154: Update copyright headers of files in src tree that are missing Classpath exception - S8213419: [AArch64] C2 may hang in MulLNode::Ideal()/MulINode::Ideal() with gcc 8.2.1 - S8213419: C2 may hang in MulLNode::Ideal()/MulINode::Ideal() with gcc 8.2.1 - S8213583: Error while opening the JFileChooser when desktop contains shortcuts pointing to deleted files. - S8213952: Relax DNSName restriction as per RFC 1123 - S8213983: [macosx] Keyboard shortcut ?cmd +`? stops working properly if popup window is displayed - S8213992: Rename and make DieOnSafepointTimeout the diagnostic option - S8214059: Undefined behaviour in ADLC - S8214061: Buffer written into itself - S8214189: test/hotspot/jtreg/compiler/intrinsics/mathexact/MulExactLConstantTest.java fails on Windows x64 when run with -XX:-TieredCompilation - S8214206: Fix for JDK-8213419 is broken on 32-bit - S8215364: JavaFX crashes on Ubuntu 18.04 with Wayland while using Swing-FX interop - S8215934: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results - S8215976: Fix gmtime_r declaration conflicts in zip.cpp with linux header files - S8216037: Avoid calling vm_update with a NULL name - S8216058: [TESTBUG] tools/launcher/VersionCheck.java fails after JDK-8215992 - S8216396: Support new Japanese era and new currency code points in java.lang.Character for Java SE 8 - S8217305: Missing 0 in java.dll file version cause issues with patch management software - S8217432: MetaspaceGC::_capacity_until_GC exceeds MaxMetaspaceSize - S8217520: Remove vm.opt.MaxGCPauseMillis == "null" from TestOldGenCollectionUsage.java - S8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled after 8211883 - S8217609: New era placeholder not recognized by java.text.SimpleDateFormat - S8217710: Add 5 currency code points to Java SE 8uX - S8217753: Enable HotSpot builds on 5.x Linux kernels - S8218613: [TESTBUG] runtime/ErrorHandling tests are building incorrect testlibrary classes - S8218915: Change isJavaIdentifierStart and isJavaIdentifierPart to handle new code points - S8219636: Windows build failure after JDK-8207070 8u backport - S8219961: [ppc64] Increase code size for interpreter generation. - S8220397: REGRESSION: JDK-8036003 backport regresses no_strip builds - S8220641: [TESTBUG] New test KdcPolicy.java introduced by JDK-8164656 needs same change as JDK-8190690 Changes in aarch64-shenandoah-jdk8u212-b03: - S8042131: DateTimeFormatterBuilder Mapped-values do not work for JapaneseDate - S8205432: Replace the placeholder Japanese era name - S8208656: Move java/util/Calendar/CalendarTestScripts tests into OpenJDK - S8210633: Cannot parse JapaneseDate string with DateTimeFormatterBuilder Mapped-values - S8211936: Better String parsing - S8218453: More dynamic RMI interactions - S8219066: Fuzzing TrueType fonts: setCurrGlyphID() - S8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales Changes in aarch64-shenandoah-jdk8u212-b04: - S8221355: Performance regression after JDK-8155635 backport into 8u Build aarch64-shenandoah-jdk8u212-b02 diffstat for corba b/.hgtags | 11 +++++++++++ b/THIRD_PARTY_README | 27 --------------------------- 2 files changed, 11 insertions(+), 27 deletions(-) diffstat for jaxp b/.hgtags | 11 ++++ b/THIRD_PARTY_README | 27 ---------- b/src/com/sun/xml/internal/stream/util/ThreadLocalBufferAllocator.java | 24 +++++--- 3 files changed, 25 insertions(+), 37 deletions(-) diffstat for jaxws b/.hgtags | 11 +++++++++++ b/THIRD_PARTY_README | 27 --------------------------- 2 files changed, 11 insertions(+), 27 deletions(-) diffstat for langtools b/.hgtags | 11 +++++++++++ b/THIRD_PARTY_README | 27 --------------------------- 2 files changed, 11 insertions(+), 27 deletions(-) diffstat for nashorn b/.hgtags | 11 +++++++++++ b/THIRD_PARTY_README | 27 --------------------------- 2 files changed, 11 insertions(+), 27 deletions(-) diffstat for jdk a/src/solaris/native/sun/awt/fontconfig.h | 941 ---------- a/test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java | 119 - a/test/java/util/stream/test/org/openjdk/tests/java/util/stream/SummaryStatisticsTest.java | 88 a/test/sun/security/krb5/auto/BadKdc.java | 221 -- a/test/sun/security/krb5/auto/BadKdc1.java | 60 a/test/sun/security/krb5/auto/BadKdc2.java | 55 a/test/sun/security/krb5/auto/BadKdc3.java | 50 a/test/sun/security/krb5/auto/BadKdc4.java | 50 a/test/sun/security/krb5/auto/CommMatcher.java | 86 a/test/sun/security/krb5/auto/MaxRetries.java | 278 -- a/test/sun/security/krb5/auto/TcpTimeout.java | 107 - a/test/sun/security/krb5/auto/UdpTcp.java | 71 b/.hgtags | 11 b/THIRD_PARTY_README | 27 b/make/CompileLaunchers.gmk | 10 b/make/data/characterdata/CharacterData00.java.template | 12 b/make/data/unicodedata/UnicodeData.txt | 6 b/make/lib/Awt2dLibraries.gmk | 2 b/make/lib/CoreLibraries.gmk | 5 b/make/src/classes/build/tools/cldrconverter/CalendarType.java | 2 b/src/aix/porting/porting_aix.c | 6 b/src/aix/porting/porting_aix.h | 6 b/src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java | 23 b/src/share/back/debugInit.c | 4 b/src/share/classes/com/sun/jarsigner/package-info.java | 6 b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AgreementMethod.java | 56 b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherData.java | 30 b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherReference.java | 26 b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedData.java | 8 b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedKey.java | 44 b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedType.java | 56 b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java | 14 b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperties.java | 26 b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperty.java | 28 b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Reference.java | 32 b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/ReferenceList.java | 42 b/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Transforms.java | 6 b/src/share/classes/com/sun/security/sasl/CramMD5Base.java | 6 b/src/share/classes/com/sun/security/sasl/ExternalClient.java | 6 b/src/share/classes/com/sun/security/sasl/PlainClient.java | 6 b/src/share/classes/com/sun/security/sasl/digest/DigestMD5Client.java | 4 b/src/share/classes/java/awt/DefaultKeyboardFocusManager.java | 11 b/src/share/classes/java/awt/SequencedEvent.java | 48 b/src/share/classes/java/lang/Character.java | 84 b/src/share/classes/java/time/chrono/JapaneseEra.java | 57 b/src/share/classes/java/util/JapaneseImperialCalendar.java | 24 b/src/share/classes/java/util/stream/AbstractPipeline.java | 3 b/src/share/classes/java/util/stream/BaseStream.java | 2 b/src/share/classes/java/util/stream/DoublePipeline.java | 2 b/src/share/classes/java/util/stream/DoubleStream.java | 2 b/src/share/classes/java/util/stream/IntPipeline.java | 2 b/src/share/classes/java/util/stream/IntStream.java | 2 b/src/share/classes/java/util/stream/LongPipeline.java | 4 b/src/share/classes/java/util/stream/LongStream.java | 2 b/src/share/classes/java/util/stream/PipelineHelper.java | 2 b/src/share/classes/java/util/stream/SliceOps.java | 2 b/src/share/classes/java/util/stream/Stream.java | 2 b/src/share/classes/java/util/stream/StreamOpFlag.java | 2 b/src/share/classes/javax/crypto/Cipher.java | 390 ++-- b/src/share/classes/javax/crypto/KeyAgreement.java | 78 b/src/share/classes/javax/crypto/KeyGenerator.java | 56 b/src/share/classes/javax/crypto/Mac.java | 140 - b/src/share/classes/javax/crypto/SecretKeyFactory.java | 50 b/src/share/classes/javax/crypto/spec/RC2ParameterSpec.java | 24 b/src/share/classes/javax/crypto/spec/RC5ParameterSpec.java | 36 b/src/share/classes/javax/swing/plaf/basic/BasicTextFieldUI.java | 10 b/src/share/classes/javax/swing/text/DefaultEditorKit.java | 9 b/src/share/classes/javax/swing/text/GlyphView.java | 2 b/src/share/classes/javax/xml/crypto/KeySelectorException.java | 48 b/src/share/classes/javax/xml/crypto/MarshalException.java | 48 b/src/share/classes/javax/xml/crypto/NoSuchMechanismException.java | 46 b/src/share/classes/javax/xml/crypto/URIReferenceException.java | 68 b/src/share/classes/javax/xml/crypto/dsig/TransformException.java | 46 b/src/share/classes/javax/xml/crypto/dsig/XMLSignatureException.java | 46 b/src/share/classes/sun/nio/cs/ext/GB18030.java | 2 b/src/share/classes/sun/nio/cs/ext/ISO2022_JP.java | 4 b/src/share/classes/sun/security/krb5/KdcComm.java | 38 b/src/share/classes/sun/security/krb5/Realm.java | 6 b/src/share/classes/sun/security/pkcs/PKCS7.java | 6 b/src/share/classes/sun/security/pkcs10/PKCS10Attributes.java | 14 b/src/share/classes/sun/security/pkcs11/P11TlsKeyMaterialGenerator.java | 38 b/src/share/classes/sun/security/pkcs11/P11TlsMasterSecretGenerator.java | 42 b/src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java | 42 b/src/share/classes/sun/security/pkcs11/P11TlsRsaPremasterSecretGenerator.java | 9 b/src/share/classes/sun/security/pkcs11/SunPKCS11.java | 39 b/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java | 14 b/src/share/classes/sun/security/pkcs11/wrapper/CK_TLS12_KEY_MAT_PARAMS.java | 151 + b/src/share/classes/sun/security/pkcs11/wrapper/CK_TLS12_MASTER_KEY_DERIVE_PARAMS.java | 65 b/src/share/classes/sun/security/pkcs11/wrapper/CK_TLS_MAC_PARAMS.java | 64 b/src/share/classes/sun/security/pkcs11/wrapper/Functions.java | 24 b/src/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java | 10 b/src/share/classes/sun/security/ssl/ExtendedMasterSecretExtension.java | 7 b/src/share/classes/sun/security/ssl/SSLAlgorithmDecomposer.java | 5 b/src/share/classes/sun/security/tools/jarsigner/TimestampedSigner.java | 6 b/src/share/classes/sun/security/validator/CADistrustPolicy.java | 105 + b/src/share/classes/sun/security/validator/EndEntityChecker.java | 27 b/src/share/classes/sun/security/validator/SymantecTLSPolicy.java | 199 ++ b/src/share/classes/sun/security/validator/Validator.java | 4 b/src/share/classes/sun/security/x509/CRLExtensions.java | 12 b/src/share/classes/sun/security/x509/CertificateExtensions.java | 12 b/src/share/classes/sun/security/x509/DNSName.java | 75 b/src/share/classes/sun/security/x509/GeneralName.java | 2 b/src/share/classes/sun/security/x509/RFC822Name.java | 2 b/src/share/classes/sun/security/x509/URIName.java | 6 b/src/share/classes/sun/security/x509/X500Name.java | 2 b/src/share/classes/sun/text/resources/FormatData.java | 4 b/src/share/classes/sun/text/resources/JavaTimeSupplementary.java | 4 b/src/share/classes/sun/text/resources/ja/FormatData_ja.java | 3 b/src/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java | 4 b/src/share/classes/sun/util/calendar/Era.java | 3 b/src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ja.xml | 1 b/src/share/classes/sun/util/cldr/resources/21_0_1/common/main/root.xml | 2 b/src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java | 52 b/src/share/lib/calendars.properties | 4 b/src/share/lib/security/java.security-aix | 30 b/src/share/lib/security/java.security-linux | 30 b/src/share/lib/security/java.security-macosx | 30 b/src/share/lib/security/java.security-solaris | 30 b/src/share/lib/security/java.security-windows | 30 b/src/share/native/com/sun/java/util/jar/pack/zip.cpp | 8 b/src/share/native/java/lang/System.c | 9 b/src/share/native/sun/font/freetypeScaler.c | 26 b/src/share/native/sun/security/pkcs11/wrapper/p11_convert.c | 421 +++- b/src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c | 296 ++- b/src/share/native/sun/security/pkcs11/wrapper/pkcs11t.h | 36 b/src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h | 13 b/src/solaris/native/sun/awt/fontpath.c | 2 b/src/solaris/native/sun/xawt/XToolkit.c | 4 b/src/windows/classes/sun/awt/windows/WToolkit.java | 33 b/src/windows/classes/sun/awt/windows/WWindowPeer.java | 12 b/src/windows/native/java/lang/java_props_md.c | 17 b/src/windows/native/sun/windows/ShellFolder2.cpp | 4 b/test/TEST.ROOT | 5 b/test/java/awt/BasicStroke/DashStrokeTest.java | 8 b/test/java/awt/Focus/NullActiveWindowOnFocusLost/NullActiveWindowOnFocusLost.java | 82 b/test/java/awt/FontClass/FontDisposer/FontDisposeTest.java | 84 b/test/java/awt/Toolkit/DisplayChangesException/DisplayChangesException.java | 131 + b/test/java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java | 174 + b/test/java/awt/event/SequencedEvent/MultipleContextsUnitTest.java | 166 + b/test/java/lang/Character/Scripts.txt | 2 b/test/java/lang/Character/TestIsJavaIdentifierMethods.java | 309 +++ b/test/java/text/Format/DateFormat/WeekDateTest.java | 18 b/test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java | 13 b/test/java/time/tck/java/time/chrono/TCKJapaneseEra.java | 3 b/test/java/time/test/java/time/chrono/TestJapaneseChronology.java | 22 b/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java | 8 b/test/java/time/test/java/time/format/TestNonIsoFormatter.java | 31 b/test/java/time/test/java/util/TestFormatter.java | 12 b/test/java/util/Calendar/Bug8007038.java | 4 b/test/java/util/Calendar/Builder/BuilderTest.java | 7 b/test/java/util/Calendar/JapaneseEraNameTest.java | 65 b/test/java/util/Calendar/JapaneseLenientEraTest.java | 66 b/test/java/util/Calendar/NarrowNamesTest.java | 7 b/test/java/util/Calendar/SupplementalJapaneseEraTest.java | 39 b/test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestDataProvider.java | 18 b/test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java | 18 b/test/java/util/stream/bootlib/java/util/stream/LongStreamTestDataProvider.java | 18 b/test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java | 27 b/test/java/util/stream/bootlib/java/util/stream/ThowableHelper.java | 49 b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectAndSummaryStatisticsTest.java | 153 + b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java | 141 + b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java | 4 b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java | 20 b/test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamCloseTest.java | 19 b/test/javax/imageio/plugins/bmp/BMP8BPPLoadTest.java | 51 b/test/javax/swing/JTextField/I18NViewNoWrapMinSpan/I18NViewNoWrapMinSpan.java | 56 b/test/javax/swing/JTextPane/JTextPaneDocumentAlignment.java | 99 + b/test/javax/swing/JTextPane/JTextPaneDocumentWrapping.java | 101 + b/test/lib/security/SecurityUtils.java | 56 b/test/sun/nio/cs/TestGB18030.java | 82 b/test/sun/nio/cs/TestISO2022JP.java | 17 b/test/sun/security/krb5/auto/KdcPolicy.java | 366 +++ b/test/sun/security/pkcs11/fips/TestTLS12.java | 449 ++++ b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/Distrust.java | 273 ++ b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/appleistca2g1-chain.pem | 80 b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/appleistca8g1-chain.pem | 64 b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustglobalca-chain.pem | 66 b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustprimarycag2-chain.pem | 55 b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustprimarycag3-chain.pem | 67 b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/geotrustuniversalca-chain.pem | 71 b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootca-chain.pem | 66 b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootcag2-chain.pem | 51 b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/thawteprimaryrootcag3-chain.pem | 67 b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g3ca-chain.pem | 71 b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g4ca-chain.pem | 56 b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g5ca-chain.pem | 71 b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignclass3g5ca-codesigning-chain.pem | 170 + b/test/sun/security/ssl/com/sun/net/ssl/internal/ssl/X509TrustManagerImpl/Symantec/verisignuniversalrootca-chain.pem | 73 b/test/sun/security/ssl/sanity/ciphersuites/CheckCipherSuites.java | 335 +-- b/test/sun/security/tools/keytool/KeyToolTest.java | 1 b/test/sun/security/x509/GeneralName/DNSNameTest.java | 91 b/test/sun/tools/clhsdb/Basic.sh | 68 b/test/sun/tools/common/CommonSetup.sh | 4 b/test/sun/tools/hsdb/Basic.sh | 61 b/test/tools/launcher/VersionCheck.java | 2 195 files changed, 7270 insertions(+), 3717 deletions(-) diffstat for hotspot a/test/sanity/WhiteBox.java | 58 -- b/.hgtags | 11 b/THIRD_PARTY_README | 27 - b/agent/src/os/linux/libproc_impl.c | 79 +-- b/agent/src/share/classes/sun/jvm/hotspot/CLHSDB.java | 3 b/agent/src/share/classes/sun/jvm/hotspot/HSDB.java | 3 b/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java | 34 - b/agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js | 68 +- b/make/aix/makefiles/buildtree.make | 5 b/make/aix/makefiles/vm.make | 5 b/make/bsd/makefiles/buildtree.make | 5 b/make/bsd/makefiles/vm.make | 5 b/make/linux/Makefile | 15 b/make/linux/makefiles/buildtree.make | 5 b/make/linux/makefiles/saproc.make | 6 b/make/linux/makefiles/vm.make | 5 b/make/openjdk_distro | 2 b/make/solaris/makefiles/buildtree.make | 5 b/make/solaris/makefiles/vm.make | 5 b/make/windows/build.make | 5 b/make/windows/makefiles/sa.make | 23 b/make/windows/makefiles/vm.make | 5 b/src/cpu/ppc/vm/assembler_ppc.hpp | 6 b/src/cpu/ppc/vm/assembler_ppc.inline.hpp | 6 b/src/cpu/ppc/vm/macroAssembler_ppc.cpp | 10 b/src/cpu/ppc/vm/stubGenerator_ppc.cpp | 8 b/src/cpu/ppc/vm/templateInterpreter_ppc.hpp | 2 b/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp | 2 b/src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp | 4 b/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp | 4 b/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp | 4 b/src/cpu/x86/vm/interp_masm_x86_32.cpp | 6 b/src/cpu/x86/vm/interp_masm_x86_64.cpp | 6 b/src/cpu/x86/vm/templateTable_x86_32.cpp | 9 b/src/cpu/x86/vm/templateTable_x86_64.cpp | 9 b/src/os/aix/vm/os_aix.cpp | 4 b/src/os/bsd/vm/os_bsd.cpp | 4 b/src/os/linux/vm/os_linux.cpp | 16 b/src/os/linux/vm/os_linux.hpp | 2 b/src/os/posix/vm/os_posix.cpp | 6 b/src/os/solaris/vm/os_solaris.cpp | 4 b/src/os/windows/vm/os_windows.cpp | 12 b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp | 31 + b/src/share/vm/adlc/adlparse.cpp | 6 b/src/share/vm/adlc/dfa.cpp | 22 b/src/share/vm/adlc/formssel.cpp | 9 b/src/share/vm/asm/assembler.hpp | 10 b/src/share/vm/c1/c1_LIRAssembler.cpp | 5 b/src/share/vm/c1/c1_LIRGenerator.cpp | 8 b/src/share/vm/code/dependencies.cpp | 2 b/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp | 5 b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp | 5 b/src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp | 4 b/src/share/vm/memory/metaspace.cpp | 32 + b/src/share/vm/memory/metaspace.hpp | 7 b/src/share/vm/opto/addnode.cpp | 8 b/src/share/vm/opto/divnode.cpp | 2 b/src/share/vm/opto/loopTransform.cpp | 4 b/src/share/vm/opto/mulnode.cpp | 99 ++-- b/src/share/vm/opto/subnode.cpp | 8 b/src/share/vm/opto/type.cpp | 22 b/src/share/vm/prims/whitebox.cpp | 10 b/src/share/vm/runtime/advancedThresholdPolicy.cpp | 7 b/src/share/vm/runtime/arguments.cpp | 8 b/src/share/vm/runtime/compilationPolicy.cpp | 2 b/src/share/vm/runtime/fprofiler.cpp | 2 b/src/share/vm/runtime/globals.hpp | 4 b/src/share/vm/runtime/os.cpp | 2 b/src/share/vm/runtime/os.hpp | 4 b/src/share/vm/runtime/safepoint.cpp | 4 b/src/share/vm/runtime/simpleThresholdPolicy.cpp | 2 b/src/share/vm/runtime/vm_version.cpp | 2 b/src/share/vm/services/memReporter.cpp | 12 b/src/share/vm/services/memoryManager.cpp | 31 - b/src/share/vm/services/memoryManager.hpp | 20 b/src/share/vm/services/memoryService.cpp | 41 + b/src/share/vm/services/memoryService.hpp | 27 - b/src/share/vm/utilities/bitMap.cpp | 23 b/src/share/vm/utilities/bitMap.hpp | 6 b/src/share/vm/utilities/bitMap.inline.hpp | 2 b/src/share/vm/utilities/globalDefinitions.hpp | 79 +++ b/src/share/vm/utilities/hashtable.cpp | 2 b/src/share/vm/utilities/vmError.cpp | 4 b/test/Makefile | 2 b/test/compiler/integerArithmetic/MultiplyByConstantLongMax.java | 45 + b/test/compiler/integerArithmetic/MultiplyByIntegerMinHang.java | 64 ++ b/test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java | 2 b/test/compiler/rtm/locking/TestRTMTotalCountIncrRate.java | 24 - b/test/compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java | 3 b/test/gc/TestMemoryMXBeansAndPoolsPresence.java | 101 ++++ b/test/gc/arguments/TestG1HeapRegionSize.java | 17 b/test/gc/arguments/TestMaxHeapSizeTools.java | 16 b/test/gc/g1/mixedgc/TestOldGenCollectionUsage.java | 231 ++++++++++ b/test/runtime/6981737/Test6981737.java | 2 b/test/runtime/ErrorHandling/TestCrashOnOutOfMemoryError.java | 2 b/test/runtime/ErrorHandling/TestExitOnOutOfMemoryError.java | 2 b/test/runtime/NMT/JcmdDetailDiff.java | 1 b/test/runtime/NMT/MallocSiteTypeChange.java | 69 ++ b/test/runtime/StackGap/T.java | 33 + b/test/runtime/StackGap/exestack-gap.c | 82 +++ b/test/runtime/StackGap/testme.sh | 73 +++ b/test/sanity/MismatchedWhiteBox/WhiteBox.java | 58 ++ b/test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java | 3 b/test/testlibrary/whitebox/sun/hotspot/WhiteBox.java | 3 104 files changed, 1459 insertions(+), 460 deletions(-) diffstat for root b/.hgtags | 11 + b/THIRD_PARTY_README | 27 --- b/common/autoconf/configure.ac | 1 b/common/autoconf/flags.m4 | 2 b/common/autoconf/generated-configure.sh | 216 ++++++++++++++++++++++++++++++- b/common/autoconf/help.m4 | 4 b/common/autoconf/jdk-options.m4 | 54 +++++++ b/common/autoconf/libraries.m4 | 63 +++++++++ b/common/autoconf/spec.gmk.in | 46 +++++- b/make/common/NativeCompilation.gmk | 4 10 files changed, 386 insertions(+), 42 deletions(-) Build aarch64-shenandoah-jdk8u212-b03 diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 b/make/data/unicodedata/UnicodeData.txt | 2 b/src/share/classes/java/math/BigDecimal.java | 50 b/src/share/classes/java/time/chrono/JapaneseEra.java | 8 b/src/share/classes/java/time/format/DateTimeFormatterBuilder.java | 15 b/src/share/classes/java/util/JapaneseImperialCalendar.java | 16 b/src/share/classes/sun/rmi/registry/RegistryImpl_Skel.java | 22 b/src/share/classes/sun/rmi/server/UnicastServerRef.java | 23 b/src/share/classes/sun/text/resources/FormatData.java | 4 b/src/share/classes/sun/text/resources/JavaTimeSupplementary.java | 4 b/src/share/classes/sun/text/resources/ja/FormatData_ja.java | 2 b/src/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java | 4 b/src/share/classes/sun/util/calendar/Era.java | 2 b/src/share/classes/sun/util/cldr/resources/21_0_1/common/main/ja.xml | 2 b/src/share/classes/sun/util/cldr/resources/21_0_1/common/main/root.xml | 4 b/src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java | 4 b/src/share/lib/calendars.properties | 4 b/src/share/native/sun/font/layout/ContextualSubstSubtables.cpp | 5 b/src/share/native/sun/font/layout/GlyphIterator.cpp | 10 b/src/share/native/sun/font/layout/SubstitutionLookups.cpp | 5 b/test/java/text/Format/DateFormat/WeekDateTest.java | 4 b/test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java | 14 b/test/java/time/tck/java/time/chrono/TCKJapaneseEra.java | 2 b/test/java/time/test/java/time/chrono/TestJapaneseChronology.java | 41 b/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java | 6 b/test/java/time/test/java/time/format/TestDateTimeFormatterBuilderWithLocale.java | 137 + b/test/java/time/test/java/time/format/TestNonIsoFormatter.java | 2 b/test/java/util/Calendar/CalendarTestScripts/CalendarAdapter.java | 437 +++++ b/test/java/util/Calendar/CalendarTestScripts/CalendarTestEngine.java | 782 ++++++++++ b/test/java/util/Calendar/CalendarTestScripts/CalendarTestException.java | 36 b/test/java/util/Calendar/CalendarTestScripts/Exceptions.java | 46 b/test/java/util/Calendar/CalendarTestScripts/GregorianAdapter.java | 125 + b/test/java/util/Calendar/CalendarTestScripts/JapaneseRollDayOfWeekTestGenerator.java | 131 + b/test/java/util/Calendar/CalendarTestScripts/JapaneseRollTests.java | 88 + b/test/java/util/Calendar/CalendarTestScripts/JapaneseTests.java | 100 + b/test/java/util/Calendar/CalendarTestScripts/README | 566 +++++++ b/test/java/util/Calendar/CalendarTestScripts/Result.java | 53 b/test/java/util/Calendar/CalendarTestScripts/Symbol.java | 328 ++++ b/test/java/util/Calendar/CalendarTestScripts/Variable.java | 76 b/test/java/util/Calendar/CalendarTestScripts/japanese/japanese.cts | 331 ++++ b/test/java/util/Calendar/CalendarTestScripts/japanese/japanese_add.cts | 521 ++++++ b/test/java/util/Calendar/CalendarTestScripts/japanese/japanese_exceptions.cts | 204 ++ b/test/java/util/Calendar/CalendarTestScripts/japanese/japanese_minmax.cts | 336 ++++ b/test/java/util/Calendar/CalendarTestScripts/japanese/japanese_normalization.cts | 97 + b/test/java/util/Calendar/CalendarTestScripts/japanese/japanese_roll.cts | 556 +++++++ b/test/java/util/Calendar/CalendarTestScripts/params/lenient.cts | 5 b/test/java/util/Calendar/CalendarTestScripts/params/non-lenient.cts | 5 b/test/java/util/Calendar/CalendarTestScripts/timezones/tz_japan.cts | 5 b/test/java/util/Calendar/CalendarTestScripts/timezones/tz_novosibirsk.cts | 5 b/test/java/util/Calendar/CalendarTestScripts/timezones/tz_pst.cts | 5 b/test/java/util/Calendar/CalendarTestScripts/timezones/tz_sydney.cts | 5 b/test/java/util/Calendar/JapaneseEraNameTest.java | 12 b/test/java/util/Calendar/JapaneseLenientEraTest.java | 2 b/test/java/util/Calendar/NarrowNamesTest.java | 2 54 files changed, 5167 insertions(+), 85 deletions(-) diffstat for hotspot b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) Build aarch64-shenandoah-jdk8u212-b04 diffstat for corba b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for jaxp b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for jaxws b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for langtools b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for nashorn b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for jdk b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for hotspot b/.hgtags | 2 ++ b/src/share/vm/opto/library_call.cpp | 9 ++++----- 2 files changed, 6 insertions(+), 5 deletions(-) diffstat for root b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Tue Apr 16 23:14:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 17 Apr 2019 01:14:58 +0200 Subject: [RFR] [8u] 8u212 Upstream Sync In-Reply-To: <89da01a7-8f94-c39c-2caa-da42684c58c8@redhat.com> References: <89da01a7-8f94-c39c-2caa-da42684c58c8@redhat.com> Message-ID: On 4/17/19 1:06 AM, Andrew John Hughes wrote: > b02: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/corba/merge.changeset Trivially fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/jaxp/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/jaxws/merge.changeset Trivially fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/jdk/merge.changeset This seems to be the meat of update release. It looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/hotspot/merge.changeset Ditto, the Hotspot part of update release meat. Looks good. I don't see any Shenandoah-related oddities. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/nashorn/merge.changeset Trivially fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/root/merge.changeset Build system update release meat. Looks fine. > b03: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/jaxws/merge.changeset Trivially fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/jdk/merge.changeset This is critical patch update. Point-checked the 2 CVE patches with the versions pushed to 12u. Japanese era look fine on cursory look. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/root/merge.changeset Trivially fine. > b04: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/jaxws/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/jdk/merge.changeset Trivially fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/hotspot/merge.changeset Performance regression fix. Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/root/merge.changeset Trivially fine. -Aleksey From gnu.andrew at redhat.com Wed Apr 17 00:10:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 17 Apr 2019 01:10:48 +0100 Subject: RFC/RFR: Pick up jdk-11.0.3+7 to sh/jdk11 In-Reply-To: <03589cbb-abdd-dcd6-6ff5-ddecfbd8b647@redhat.com> References: <03589cbb-abdd-dcd6-6ff5-ddecfbd8b647@redhat.com> Message-ID: <6f4f7393-c5a5-4e61-c3c0-1a62b5434a46@redhat.com> On 16/04/2019 23:41, Aleksey Shipilev wrote: > Upstream^W We have pushed the jdk-11.0.3+7 tag upstream to jdk-updates/jdk11u. Let's pick it up to > sh/jdk11. The merge is trivial, and includes all outstanding patches that landed in recently > released 11u. > > Summary of changes: > http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b7/changesets.txt > > Webrev (closely matches the one pushed to upstream 11u): > http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b7/webrev.01/ > > Changeset graph: > http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b7/hg-graph-log.txt > > Some explanation here: we have Shenandoah patches pushed after +6, which did not end up in +7 > RPMs. Therefore, we merge +7 from +6, and then merge outstanding Shenandoah head with +7. This would > match the tags with what was actually shipped. > > Testing: tier1_gc_shenandoah {fastdebug, release} > I did a similar merge during the CPU, but I think we have the same thing, bar some ordering. This is the merge of 11.0.3+7 with Shenandoah: https://cr.openjdk.java.net/~andrew/shenandoah-11/11.0.3/11.0.3%2b7.merge and here is the merge with upstream: https://cr.openjdk.java.net/~andrew/shenandoah-11/11.0.3/upstream.merge Webrev: https://cr.openjdk.java.net/~andrew/shenandoah-11/11.0.3/webrev/ -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Wed Apr 17 00:12:22 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 17 Apr 2019 02:12:22 +0200 Subject: RFC/RFR: Pick up jdk-11.0.3+7 to sh/jdk11 In-Reply-To: <6f4f7393-c5a5-4e61-c3c0-1a62b5434a46@redhat.com> References: <03589cbb-abdd-dcd6-6ff5-ddecfbd8b647@redhat.com> <6f4f7393-c5a5-4e61-c3c0-1a62b5434a46@redhat.com> Message-ID: On 4/17/19 2:10 AM, Andrew John Hughes wrote: > On 16/04/2019 23:41, Aleksey Shipilev wrote: >> Upstream^W We have pushed the jdk-11.0.3+7 tag upstream to jdk-updates/jdk11u. Let's pick it up to >> sh/jdk11. The merge is trivial, and includes all outstanding patches that landed in recently >> released 11u. >> >> Summary of changes: >> http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b7/changesets.txt >> >> Webrev (closely matches the one pushed to upstream 11u): >> http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b7/webrev.01/ >> >> Changeset graph: >> http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b7/hg-graph-log.txt >> >> Some explanation here: we have Shenandoah patches pushed after +6, which did not end up in +7 >> RPMs. Therefore, we merge +7 from +6, and then merge outstanding Shenandoah head with +7. This would >> match the tags with what was actually shipped. >> >> Testing: tier1_gc_shenandoah {fastdebug, release} >> > > I did a similar merge during the CPU, but I think we have the same > thing, bar some ordering. > > This is the merge of 11.0.3+7 with Shenandoah: > > https://cr.openjdk.java.net/~andrew/shenandoah-11/11.0.3/11.0.3%2b7.merge > > and here is the merge with upstream: > > https://cr.openjdk.java.net/~andrew/shenandoah-11/11.0.3/upstream.merge > > Webrev: https://cr.openjdk.java.net/~andrew/shenandoah-11/11.0.3/webrev/ Okay, let's push your version. Looks good! -Aleksey From gnu.andrew at redhat.com Wed Apr 17 01:47:28 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 17 Apr 2019 02:47:28 +0100 Subject: [RFR] [8u] 8u212 Upstream Sync In-Reply-To: References: <89da01a7-8f94-c39c-2caa-da42684c58c8@redhat.com> Message-ID: On 17/04/2019 00:14, Aleksey Shipilev wrote: > On 4/17/19 1:06 AM, Andrew John Hughes wrote: >> b02: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/corba/merge.changeset > > Trivially fine. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/jaxp/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/jaxws/merge.changeset > > Trivially fine. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/jdk/merge.changeset > > This seems to be the meat of update release. It looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/hotspot/merge.changeset > > Ditto, the Hotspot part of update release meat. Looks good. I don't see any Shenandoah-related oddities. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/langtools/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/nashorn/merge.changeset > > Trivially fine. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b02/root/merge.changeset > > Build system update release meat. Looks fine. > > >> b03: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/corba/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/jaxp/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/jaxws/merge.changeset > > Trivially fine. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/jdk/merge.changeset > > This is critical patch update. Point-checked the 2 CVE patches with the versions pushed to 12u. > Japanese era look fine on cursory look. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/hotspot/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/langtools/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/nashorn/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212/root/merge.changeset > > Trivially fine. > >> b04: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/corba/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/jaxp/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/jaxws/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/jdk/merge.changeset > > Trivially fine. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/hotspot/merge.changeset > > Performance regression fix. Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/langtools/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/nashorn/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u212-b04/root/merge.changeset > > Trivially fine. > > -Aleksey > Pushed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From rkennke at redhat.com Wed Apr 17 07:10:10 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 17 Apr 2019 09:10:10 +0200 Subject: RFC/RFR: Pick up jdk-11.0.3+7 to sh/jdk11 In-Reply-To: <03589cbb-abdd-dcd6-6ff5-ddecfbd8b647@redhat.com> References: <03589cbb-abdd-dcd6-6ff5-ddecfbd8b647@redhat.com> Message-ID: Do it! Thanks! > Upstream^W We have pushed the jdk-11.0.3+7 tag upstream to jdk-updates/jdk11u. Let's pick it up to > sh/jdk11. The merge is trivial, and includes all outstanding patches that landed in recently > released 11u. > > Summary of changes: > http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b7/changesets.txt > > Webrev (closely matches the one pushed to upstream 11u): > http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b7/webrev.01/ > > Changeset graph: > http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.3%2b7/hg-graph-log.txt > > Some explanation here: we have Shenandoah patches pushed after +6, which did not end up in +7 > RPMs. Therefore, we merge +7 from +6, and then merge outstanding Shenandoah head with +7. This would > match the tags with what was actually shipped. > > Testing: tier1_gc_shenandoah {fastdebug, release} > From shade at redhat.com Wed Apr 17 17:21:04 2019 From: shade at redhat.com (shade at redhat.com) Date: Wed, 17 Apr 2019 17:21:04 +0000 Subject: hg: shenandoah/jdk11: 11 new changesets Message-ID: <201904171721.x3HHL5ru028667@aojmv0008.oracle.com> Changeset: 59610bddd37a Author: igerasim Date: 2019-04-03 02:07 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/59610bddd37a 8211936: Better String parsing Reviewed-by: aph ! src/java.base/share/classes/java/math/BigDecimal.java Changeset: c61b8801f0e4 Author: ccheung Date: 2019-04-03 02:10 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/c61b8801f0e4 8214809: CDS storage improvements Reviewed-by: aph ! src/hotspot/share/classfile/classFileParser.cpp ! test/hotspot/jtreg/runtime/appcds/OldClassTest.java Changeset: 1084d119236b Author: igerasim Date: 2019-04-03 02:13 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/1084d119236b 8218453: More dynamic RMI interactions Reviewed-by: aph ! src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl_Skel.java ! src/java.rmi/share/classes/sun/rmi/server/UnicastServerRef.java Changeset: f0d8b845de21 Author: xiaofeya Date: 2018-08-09 15:42 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/f0d8b845de21 8208656: Move java/util/Calendar/CalendarTestScripts tests into OpenJDK Reviewed-by: naoto + test/jdk/java/util/Calendar/CalendarTestScripts/CalendarAdapter.java + test/jdk/java/util/Calendar/CalendarTestScripts/CalendarTestEngine.java + test/jdk/java/util/Calendar/CalendarTestScripts/CalendarTestException.java + test/jdk/java/util/Calendar/CalendarTestScripts/Exceptions.java + test/jdk/java/util/Calendar/CalendarTestScripts/GregorianAdapter.java + test/jdk/java/util/Calendar/CalendarTestScripts/JapaneseRollDayOfWeekTestGenerator.java + test/jdk/java/util/Calendar/CalendarTestScripts/JapaneseRollTests.java + test/jdk/java/util/Calendar/CalendarTestScripts/JapaneseTests.java + test/jdk/java/util/Calendar/CalendarTestScripts/README + test/jdk/java/util/Calendar/CalendarTestScripts/Result.java + test/jdk/java/util/Calendar/CalendarTestScripts/Symbol.java + test/jdk/java/util/Calendar/CalendarTestScripts/Variable.java + test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese.cts + test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_add.cts + test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_exceptions.cts + test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_minmax.cts + test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_normalization.cts + test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_roll.cts + test/jdk/java/util/Calendar/CalendarTestScripts/params/lenient.cts + test/jdk/java/util/Calendar/CalendarTestScripts/params/non-lenient.cts + test/jdk/java/util/Calendar/CalendarTestScripts/timezones/tz_japan.cts + test/jdk/java/util/Calendar/CalendarTestScripts/timezones/tz_novosibirsk.cts + test/jdk/java/util/Calendar/CalendarTestScripts/timezones/tz_pst.cts + test/jdk/java/util/Calendar/CalendarTestScripts/timezones/tz_sydney.cts Changeset: 21de52677dee Author: naoto Date: 2018-09-25 13:57 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/21de52677dee 8210633: Cannot parse JapaneseDate string with DateTimeFormatterBuilder Mapped-values Reviewed-by: scolebourne, rriggs ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilderWithLocale.java Changeset: 2996b4523925 Author: naoto Date: 2019-02-28 14:03 -0800 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/2996b4523925 8219890: Calendar.getDisplayName() returns empty string for new Japanese Era on some locales Reviewed-by: lancea ! src/java.base/share/classes/java/util/JapaneseImperialCalendar.java ! test/jdk/java/util/Calendar/JapaneseEraNameTest.java Changeset: 175eb80c253a Author: naoto Date: 2019-04-03 02:25 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/175eb80c253a 8205432: Replace the placeholder Japanese era name Reviewed-by: rriggs, chegar ! make/data/unicodedata/UnicodeData.txt ! src/java.base/share/classes/java/time/chrono/JapaneseEra.java ! src/java.base/share/classes/java/util/JapaneseImperialCalendar.java ! src/java.base/share/classes/sun/text/resources/FormatData.java ! src/java.base/share/classes/sun/text/resources/JavaTimeSupplementary.java ! src/java.base/share/classes/sun/util/calendar/Era.java ! src/java.base/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ja.java ! src/jdk.localedata/share/classes/sun/text/resources/ext/JavaTimeSupplementary_ja.java ! src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ja.xml ! src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/root.xml ! test/jdk/java/lang/Character/UnicodeData.txt ! test/jdk/java/text/Format/DateFormat/WeekDateTest.java ! test/jdk/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/jdk/java/time/tck/java/time/chrono/TCKJapaneseEra.java ! test/jdk/java/time/test/java/time/chrono/TestJapaneseChronology.java ! test/jdk/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java ! test/jdk/java/time/test/java/time/format/TestNonIsoFormatter.java ! test/jdk/java/util/Calendar/CalendarTestScripts/CalendarAdapter.java ! test/jdk/java/util/Calendar/CalendarTestScripts/Symbol.java ! test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese.cts ! test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_add.cts ! test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_minmax.cts ! test/jdk/java/util/Calendar/CalendarTestScripts/japanese/japanese_roll.cts ! test/jdk/java/util/Calendar/JapaneseEraNameTest.java ! test/jdk/java/util/Calendar/JapaneseLenientEraTest.java ! test/jdk/java/util/Calendar/NarrowNamesTest.java ! test/jdk/java/util/Calendar/ZoneOffsets.java Changeset: 37666287e26b Author: andrew Date: 2019-04-03 02:57 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/37666287e26b Added tag jdk-11.0.3+7 for changeset 175eb80c253a ! .hgtags Changeset: 2a3bf47aa2b9 Author: andrew Date: 2019-04-04 17:17 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/2a3bf47aa2b9 Merge jdk-11.0.3+7 ! .hgtags Changeset: 75093e463529 Author: andrew Date: 2019-04-04 17:18 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/75093e463529 Added tag shenandoah-jdk-11.0.3+7 for changeset 2a3bf47aa2b9 ! .hgtags Changeset: 83fca29cec34 Author: andrew Date: 2019-04-17 00:27 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/83fca29cec34 Merge From shade at redhat.com Thu Apr 18 11:05:52 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 18 Apr 2019 13:05:52 +0200 Subject: CFV: New Shenandoah Committer: Andrew Hughes Message-ID: I hereby nominate Andrew Hughes to become a Shenandoah Committer. Andrew is a long time JDK contributor, with experience of gatekeeping and maintaining JDK update releases, which often includes resolving the conflicts and rewriting parts of Shenandoah-related code. He should be able to commit his changes to sh/jdk* repositories himself. Votes are due by May 2, 2019. Only current Shenandoah Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. -- Thanks, -Aleksey [1] http://openjdk.java.net/census#shenandoah [2] http://openjdk.java.net/projects/#committer-vote From shade at redhat.com Thu Apr 18 11:06:28 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 18 Apr 2019 13:06:28 +0200 Subject: CFV: New Shenandoah Committer: Andrew Hughes In-Reply-To: References: Message-ID: <06e2aa46-3904-4a76-a0a5-31bd834bd307@redhat.com> Vote: yes On 4/18/19 1:05 PM, Aleksey Shipilev wrote: > I hereby nominate Andrew Hughes to become a Shenandoah Committer. -Aleksey From zgu at redhat.com Thu Apr 18 11:36:52 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 18 Apr 2019 07:36:52 -0400 Subject: CFV: New Shenandoah Committer: Andrew Hughes In-Reply-To: References: Message-ID: <75ece984-f32e-9c85-47cb-789cfadca9f3@redhat.com> Vote: yes. -Zhengyu On 4/18/19 7:05 AM, Aleksey Shipilev wrote: > I hereby nominate Andrew Hughes to become a Shenandoah Committer. > > Andrew is a long time JDK contributor, with experience of gatekeeping and maintaining JDK update > releases, which often includes resolving the conflicts and rewriting parts of Shenandoah-related > code. He should be able to commit his changes to sh/jdk* repositories himself. > > Votes are due by May 2, 2019. > > Only current Shenandoah Committers [1] are eligible to vote on this nomination. Votes must be cast > in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > From rkennke at redhat.com Thu Apr 18 12:21:57 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 18 Apr 2019 14:21:57 +0200 Subject: CFV: New Shenandoah Committer: Andrew Hughes In-Reply-To: References: Message-ID: Vote: yes Am 18. April 2019 13:05:52 MESZ schrieb Aleksey Shipilev : >I hereby nominate Andrew Hughes to become a Shenandoah Committer. > >Andrew is a long time JDK contributor, with experience of gatekeeping >and maintaining JDK update >releases, which often includes resolving the conflicts and rewriting >parts of Shenandoah-related >code. He should be able to commit his changes to sh/jdk* repositories >himself. > >Votes are due by May 2, 2019. > >Only current Shenandoah Committers [1] are eligible to vote on this >nomination. Votes must be cast >in the open by replying to this mailing list. > >For Lazy Consensus voting instructions, see [2]. > >-- >Thanks, >-Aleksey > >[1] http://openjdk.java.net/census#shenandoah >[2] http://openjdk.java.net/projects/#committer-vote -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From shade at redhat.com Sat Apr 20 09:50:06 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 20 Apr 2019 11:50:06 +0200 Subject: RFR (S) 8222786: Shenandoah get_barrier_strength should accept all shapes of (Weak)CAS reference barriers Message-ID: <8924c326-9142-4ea7-ef92-356962ee993e@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8222786 Fix: http://cr.openjdk.java.net/~shade/8222786/webrev.01/ See bug for the example failures. I am puzzled why those were not covered before. Testing: hotspot_gc_shenandoah, jcstress -- Thanks, -Aleksey From shade at redhat.com Sat Apr 20 09:50:52 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 20 Apr 2019 11:50:52 +0200 Subject: RFR (S) 8222786: Shenandoah get_barrier_strength should accept all shapes of (Weak)CAS reference barriers In-Reply-To: <8924c326-9142-4ea7-ef92-356962ee993e@redhat.com> References: <8924c326-9142-4ea7-ef92-356962ee993e@redhat.com> Message-ID: <0a0981fa-3b08-86f0-f6ef-d6d21c64669e@redhat.com> (forgot to cc hotspot-gc-dev, doing so) On 4/20/19 11:50 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8222786 > > Fix: > http://cr.openjdk.java.net/~shade/8222786/webrev.01/ > > See bug for the example failures. I am puzzled why those were not covered before. > > Testing: hotspot_gc_shenandoah, jcstress -Aleksey From rwestrel at redhat.com Sat Apr 20 11:05:36 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Sat, 20 Apr 2019 13:05:36 +0200 Subject: CFV: New Shenandoah Committer: Andrew Hughes In-Reply-To: References: Message-ID: Vote: yes Roland. From rkennke at redhat.com Sat Apr 20 11:17:58 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 20 Apr 2019 13:17:58 +0200 Subject: RFR (S) 8222786: Shenandoah get_barrier_strength should accept all shapes of (Weak)CAS reference barriers In-Reply-To: <0a0981fa-3b08-86f0-f6ef-d6d21c64669e@redhat.com> References: <8924c326-9142-4ea7-ef92-356962ee993e@redhat.com> <0a0981fa-3b08-86f0-f6ef-d6d21c64669e@redhat.com> Message-ID: <3D964711-307F-4C2C-9520-6B5DC53F8295@redhat.com> OK. Am 20. April 2019 11:50:52 MESZ schrieb Aleksey Shipilev : >(forgot to cc hotspot-gc-dev, doing so) > >On 4/20/19 11:50 AM, Aleksey Shipilev wrote: >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8222786 >> >> Fix: >> http://cr.openjdk.java.net/~shade/8222786/webrev.01/ >> >> See bug for the example failures. I am puzzled why those were not >covered before. >> >> Testing: hotspot_gc_shenandoah, jcstress > >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From chf at redhat.com Mon Apr 22 13:54:19 2019 From: chf at redhat.com (Christine Flood) Date: Mon, 22 Apr 2019 09:54:19 -0400 Subject: CFV: New Shenandoah Committer: Andrew Hughes In-Reply-To: References: Message-ID: Vote Yes On Thu, Apr 18, 2019 at 7:07 AM Aleksey Shipilev wrote: > I hereby nominate Andrew Hughes to become a Shenandoah Committer. > > Andrew is a long time JDK contributor, with experience of gatekeeping and > maintaining JDK update > releases, which often includes resolving the conflicts and rewriting parts > of Shenandoah-related > code. He should be able to commit his changes to sh/jdk* repositories > himself. > > Votes are due by May 2, 2019. > > Only current Shenandoah Committers [1] are eligible to vote on this > nomination. Votes must be cast > in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > -- > Thanks, > -Aleksey > > [1] http://openjdk.java.net/census#shenandoah > [2] http://openjdk.java.net/projects/#committer-vote > > > > From shade at redhat.com Tue Apr 23 08:53:49 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 23 Apr 2019 10:53:49 +0200 Subject: RFR (S) 8222766: Shenandoah: streamline post-LRB CAS barrier Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8222766 Webrev: http://cr.openjdk.java.net/~shade/8222766/webrev.02/ Now that LRB switched Shenandoah to strong to-space invariant, we don't need the retry loop in CAS barrier. Instead, we can "just" fixup the memory pointer before retrying. Added more comments to explain how that works. Also, AArch64 snippet was synced up with x86_64 version, and switched to "macro" cmpxchg, which gives us cmpxchg instructions when LSE is enabled. Testing: Linux {x86_64, aarch64}: hotspot_gc_shenandoah, full jcstress -- Thanks, -Aleksey From rkennke at redhat.com Tue Apr 23 09:01:40 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 23 Apr 2019 11:01:40 +0200 Subject: RFR (S) 8222766: Shenandoah: streamline post-LRB CAS barrier In-Reply-To: References: Message-ID: <63ea1e7b-b8b2-eaba-acae-9e19e7a5557c@redhat.com> Hi Aleksey, This looks good to me. One minor nit: 609 // to-space, and memory pointer is to-space as well. Nothing is able to store 610 // to-space ptr into memory anymore. Should be: Nothing is able to store from-space ptr into memory anymore. Also: 626 // and promote the result. Note that we handle the flag from any the CASes 627 // either from fast-path or retries. 'from any *of* the CASes' I don't need to see it again for this. Thanks, Roman From rkennke at redhat.com Tue Apr 23 09:10:41 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 23 Apr 2019 11:10:41 +0200 Subject: RFR (S) 8222766: Shenandoah: streamline post-LRB CAS barrier In-Reply-To: References: Message-ID: Wait a second. We had this problem before: there *can* be from-space stores. Object-arraycopy can store from-space refs. It would only be temporary, because post-arraycopy would fix it, but I suspect that it can mess up the CAS. Right? I do have a patch that turns the arraycopy pre/copy/post sequence into a single arraycopy loop, that does indeed only ever store to-space refs. Maybe worth to finish it? Also, this is not really related to LRB. It would work just the same pre-LRB. Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8222766 > > Webrev: > http://cr.openjdk.java.net/~shade/8222766/webrev.02/ > > Now that LRB switched Shenandoah to strong to-space invariant, we don't need the retry loop in CAS > barrier. Instead, we can "just" fixup the memory pointer before retrying. Added more comments to > explain how that works. Also, AArch64 snippet was synced up with x86_64 version, and switched to > "macro" cmpxchg, which gives us cmpxchg instructions when LSE is enabled. > > Testing: Linux {x86_64, aarch64}: hotspot_gc_shenandoah, full jcstress > From shade at redhat.com Tue Apr 23 09:15:00 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 23 Apr 2019 11:15:00 +0200 Subject: RFR (XS) 8222843: Print Shenandoah cset map addresses in hs_err Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8222843 Fix: diff -r 8eae2646fed8 src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Tue Apr 23 10:58:24 2019 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Tue Apr 23 11:13:05 2019 +0200 @@ -89,4 +89,7 @@ private: + jbyte* map_address() const { + return _cset_map; + } jbyte* biased_map_address() const { return _biased_cset_map; diff -r 8eae2646fed8 src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 23 10:58:24 2019 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 23 11:13:05 2019 +0200 @@ -538,4 +538,13 @@ p2i(reserved_region().end())); + ShenandoahCollectionSet* cset = collection_set(); + st->print_cr("Collection set:"); + if (cset != NULL) { + st->print_cr(" - map (vanilla): " PTR_FORMAT, p2i(cset->map_address())); + st->print_cr(" - map (biased): " PTR_FORMAT, p2i(cset->biased_map_address())); + } else { + st->print_cr(" (NULL)"); + } + st->cr(); MetaspaceUtils::print_on(st); Testing: eyeballing hs_errs -- Thanks, -Aleksey From shade at redhat.com Tue Apr 23 09:21:28 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 23 Apr 2019 11:21:28 +0200 Subject: RFR (S) 8222766: Shenandoah: streamline post-LRB CAS barrier In-Reply-To: References: Message-ID: On 4/23/19 11:10 AM, Roman Kennke wrote: > Wait a second. We had this problem before: there *can* be from-space stores. Object-arraycopy can > store from-space refs. It would only be temporary, because post-arraycopy would fix it, but I > suspect that it can mess up the CAS. Right? > I do have a patch that turns the arraycopy pre/copy/post sequence into a single arraycopy loop, that > does indeed only ever store to-space refs. Maybe worth to finish it? Yes. Maybe a simpler version that does the array fixups in-place before copying it. Please link that RFE as the blocker for this one? > Also, this is not really related to LRB. It would work just the same pre-LRB. It kinda does. Before LRB we could store the to-space ptr on normal path: for example, storing the reference that slipped through store-val barriers due to the concurrent race with evacuation updaters. This new code relies on assumption that nothing ever stores to-space ptrs anywhere, as LRB makes sure nothing is able to get the from-space ptr. -Aleksey From shade at redhat.com Tue Apr 23 10:11:36 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 23 Apr 2019 12:11:36 +0200 Subject: RFR (S) 8222766: Shenandoah: streamline post-LRB CAS barrier In-Reply-To: <63ea1e7b-b8b2-eaba-acae-9e19e7a5557c@redhat.com> References: <63ea1e7b-b8b2-eaba-acae-9e19e7a5557c@redhat.com> Message-ID: <6f7d8f32-78c1-40d6-26f2-0e40999b9b8b@redhat.com> On 4/23/19 11:01 AM, Roman Kennke wrote: > This looks good to me. One minor nit: > > 609?? // to-space, and memory pointer is to-space as well. Nothing is able to store > 610?? // to-space ptr into memory anymore. > > Should be: Nothing is able to store from-space ptr into memory anymore. > > Also: > > 626?? // and promote the result. Note that we handle the flag from any the CASes > 627?? // either from fast-path or retries. > > 'from any *of* the CASes' Right. Updated in-place. -Aleksey From rkennke at redhat.com Tue Apr 23 10:52:07 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 23 Apr 2019 12:52:07 +0200 Subject: RFR (S) 8222766: Shenandoah: streamline post-LRB CAS barrier In-Reply-To: References: Message-ID: >> Wait a second. We had this problem before: there *can* be from-space stores. Object-arraycopy can >> store from-space refs. It would only be temporary, because post-arraycopy would fix it, but I >> suspect that it can mess up the CAS. Right? > >> I do have a patch that turns the arraycopy pre/copy/post sequence into a single arraycopy loop, that >> does indeed only ever store to-space refs. Maybe worth to finish it? > > Yes. Maybe a simpler version that does the array fixups in-place before copying it. I tried that. I don't think it is simpler. And I also don't see what it might gain. > Please link that > RFE as the blocker for this one? Done: https://bugs.openjdk.java.net/browse/JDK-8222859 >> Also, this is not really related to LRB. It would work just the same pre-LRB. > > It kinda does. Before LRB we could store the to-space ptr on normal path: for example, storing the > reference that slipped through store-val barriers due to the concurrent race with evacuation > updaters. Right. This also implies that it's not enough to do RB-like-resolve in the arraycopy loop in JDK-8222859. > This new code relies on assumption that nothing ever stores to-space ptrs anywhere, as LRB > makes sure nothing is able to get the from-space ptr. Yes. I will brush my fix for JDK-8222859. Roman From shade at redhat.com Tue Apr 23 21:48:35 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 23 Apr 2019 23:48:35 +0200 Subject: RFR (S) 8222838: Shenandoah: SEGV on accessing cset bitmap for NULL ptr Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8222838 Webrev: http://cr.openjdk.java.net/~shade/8222838/webrev.01/ See the bug for the example failure that this fix resolves. Code comments should tell about the implementation details for the fix. Testing: Linux {x86_64, aarch64} hotspot_gc_shenandoah {+Coops, -Coops}, Windows x86_64 ad-hoc tests, eyeballing NMT summary -- Thanks, -Aleksey From rkennke at redhat.com Wed Apr 24 08:31:06 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 24 Apr 2019 10:31:06 +0200 Subject: RFR (S) 8222838: Shenandoah: SEGV on accessing cset bitmap for NULL ptr In-Reply-To: References: Message-ID: Looks good. Thanks! Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8222838 > > Webrev: > http://cr.openjdk.java.net/~shade/8222838/webrev.01/ > > See the bug for the example failure that this fix resolves. Code comments should tell about the > implementation details for the fix. > > Testing: Linux {x86_64, aarch64} hotspot_gc_shenandoah {+Coops, -Coops}, Windows x86_64 ad-hoc > tests, eyeballing NMT summary > From rkennke at redhat.com Wed Apr 24 09:02:57 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 24 Apr 2019 11:02:57 +0200 Subject: RFR (XS) 8222843: Print Shenandoah cset map addresses in hs_err In-Reply-To: References: Message-ID: <524481e0-9078-5bba-13cc-756ff80e7a40@redhat.com> Yes, looks good, thanks! Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8222843 > > Fix: > > diff -r 8eae2646fed8 src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Tue Apr 23 10:58:24 2019 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Tue Apr 23 11:13:05 2019 +0200 > @@ -89,4 +89,7 @@ > > private: > + jbyte* map_address() const { > + return _cset_map; > + } > jbyte* biased_map_address() const { > return _biased_cset_map; > diff -r 8eae2646fed8 src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 23 10:58:24 2019 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 23 11:13:05 2019 +0200 > @@ -538,4 +538,13 @@ > p2i(reserved_region().end())); > > + ShenandoahCollectionSet* cset = collection_set(); > + st->print_cr("Collection set:"); > + if (cset != NULL) { > + st->print_cr(" - map (vanilla): " PTR_FORMAT, p2i(cset->map_address())); > + st->print_cr(" - map (biased): " PTR_FORMAT, p2i(cset->biased_map_address())); > + } else { > + st->print_cr(" (NULL)"); > + } > + > st->cr(); > MetaspaceUtils::print_on(st); > > > Testing: eyeballing hs_errs > From shade at redhat.com Wed Apr 24 10:12:32 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Apr 2019 12:12:32 +0200 Subject: RFC: Pick up jdk-13+17 to sh/jdk Message-ID: We have not synced up sh/jdk for a while now. Let's pick up to the latest upstream tag, jdk-13+17. Merge is trivial. Changesets: http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk-13%2b17/changesets.txt Testing: hotspot_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From rkennke at redhat.com Wed Apr 24 11:02:52 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 24 Apr 2019 13:02:52 +0200 Subject: RFC: Pick up jdk-13+17 to sh/jdk In-Reply-To: References: Message-ID: <891cc557-3f60-e46f-a64f-69e10ded77e3@redhat.com> Yes, do it! Thanks, Roman > We have not synced up sh/jdk for a while now. Let's pick up to the latest upstream tag, jdk-13+17. > Merge is trivial. > > Changesets: > http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk-13%2b17/changesets.txt > > Testing: hotspot_gc_shenandoah {fastdebug, release} > From shade at redhat.com Wed Apr 24 11:12:24 2019 From: shade at redhat.com (shade at redhat.com) Date: Wed, 24 Apr 2019 11:12:24 +0000 Subject: hg: shenandoah/jdk: 80 new changesets Message-ID: <201904241112.x3OBCTpT029917@aojmv0008.oracle.com> Changeset: 17b1c2c467ad Author: vromero Date: 2019-04-10 17:15 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/17b1c2c467ad 8222035: minimal inference context optimization is forcing resolution with incomplete constraints Reviewed-by: mcimadamore, cushon ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/InferenceContext.java + test/langtools/tools/javac/T8222035/MinContextOpTest.java + test/langtools/tools/javac/T8222035/MinContextOpTest.out Changeset: 1bbce3048d20 Author: dtitov Date: 2019-04-10 21:21 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/1bbce3048d20 8222224: vmTestbase/nsk/jvmti/SingleStep/singlestep001/TestDescription.java fails Reviewed-by: sspitsyn, jcbeyler, amenkov ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SingleStep/singlestep001/singlestep001.cpp Changeset: 941db9c0b5b5 Author: coleenp Date: 2019-04-10 17:31 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/941db9c0b5b5 8222231: Clean up interfaceSupport.inline.hpp duplicated code Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/thread.inline.hpp Changeset: 30aca1e755bf Author: jwilhelm Date: 2019-04-11 01:21 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/30aca1e755bf Added tag jdk-13+16 for changeset 9d0ae9508d53 ! .hgtags Changeset: 96230a5ef2ec Author: sspitsyn Date: 2019-04-10 17:29 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/96230a5ef2ec 8222072: JVMTI GenerateEvents() sends CompiledMethodLoad events to wrong jvmtiEnv Summary: Fix GenerateEvents() to send CompiledMethodLoad events to requesting agent only Reviewed-by: jcbeyler, amenkov ! src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiExport.hpp + test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/MyPackage/GenerateEventsTest.java + test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/libGenerateEvents1.cpp + test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/libGenerateEvents2.cpp Changeset: 4eefc9f3313c Author: aoqi Date: 2019-04-10 22:41 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/4eefc9f3313c 8222300: Zero build broken after JDK-8222231 Reviewed-by: dholmes ! src/hotspot/cpu/zero/cppInterpreter_zero.cpp Changeset: 3ea8b5858874 Author: mbaesken Date: 2019-04-10 09:33 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/3ea8b5858874 8221915: cleanup ticks related coding in os_perf_aix.cpp [aix] Reviewed-by: mdoerr ! src/hotspot/os/aix/os_perf_aix.cpp Changeset: 71ef6db01d8e Author: pmuthuswamy Date: 2019-04-11 12:49 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/71ef6db01d8e 8217013: javadoc generates references to missing file overview-frame.html Reviewed-by: hannesw ! test/langtools/jdk/javadoc/doclet/testHtmlLandmarkRegions/TestHtmlLandmarkRegions.java ! test/langtools/jdk/javadoc/doclet/testIndexWithModules/TestIndexWithModules.java Changeset: d79e50159c0e Author: psadhukhan Date: 2019-04-03 14:21 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/d79e50159c0e 8221661: javax.swing.text.View.getPreferredSpan(int axis) Reviewed-by: serb ! src/java.desktop/share/classes/javax/swing/text/View.java Changeset: d95d9d034034 Author: serb Date: 2019-04-03 15:56 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/d95d9d034034 6684386: ElementIterator javadoc bug Reviewed-by: psadhukhan ! src/java.desktop/share/classes/javax/swing/text/ElementIterator.java Changeset: e64a8477cd71 Author: pbansal Date: 2019-04-04 12:14 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/e64a8477cd71 8220349: The fix done for JDK-8214253 have caused issues in JTree behaviour Reviewed-by: serb, prr ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c Changeset: 55b0469425e1 Author: serb Date: 2019-04-08 14:48 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/55b0469425e1 8221885: Add intermittent test in the JavaSound to the ProblemList Reviewed-by: prr ! test/jdk/ProblemList.txt Changeset: 7f53d59593e2 Author: aivanov Date: 2019-04-09 08:50 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/7f53d59593e2 8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use Reviewed-by: serb, prr ! test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java Changeset: 8b3b89320d03 Author: serb Date: 2019-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/8b3b89320d03 8221445: FastSysexMessage constructor crashes MIDI receiption thread Reviewed-by: prr ! src/java.desktop/share/classes/com/sun/media/sound/FastSysexMessage.java ! src/java.desktop/share/classes/com/sun/media/sound/MidiUtils.java ! src/java.desktop/share/classes/javax/sound/midi/SysexMessage.java + test/jdk/javax/sound/midi/SysexMessage/Basic.java + test/jdk/javax/sound/midi/SysexMessage/Exceptions.java Changeset: a67b9214cfab Author: psadhukhan Date: 2019-04-10 10:32 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a67b9214cfab 8222097: ProblemList tests that are failing recurringly and intermittently in PIT Reviewed-by: prr, kaddepalli ! test/jdk/ProblemList.txt Changeset: 85d7f6e725a8 Author: psadhukhan Date: 2019-04-10 10:46 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/85d7f6e725a8 Merge - test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java Changeset: 6c291f12969f Author: psadhukhan Date: 2019-04-11 14:20 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/6c291f12969f Merge Changeset: c97a91097f9f Author: stefank Date: 2019-04-10 15:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/c97a91097f9f 8221913: Add GC.selected() jtreg-ext function Reviewed-by: kbarrett, pliden ! test/lib/sun/hotspot/gc/GC.java Changeset: fbfcebad8e66 Author: stefank Date: 2019-04-10 15:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/fbfcebad8e66 8221393: ResolvedMethodTable too small for StackWalking applications Reviewed-by: coleenp, rehn ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/gc/shared/weakProcessor.cpp ! src/hotspot/share/gc/shared/weakProcessor.inline.hpp ! src/hotspot/share/gc/shared/weakProcessorPhases.cpp ! src/hotspot/share/gc/shared/weakProcessorPhases.hpp ! src/hotspot/share/gc/z/zRootsIterator.cpp ! src/hotspot/share/gc/z/zRootsIterator.hpp ! src/hotspot/share/oops/weakHandle.cpp ! src/hotspot/share/oops/weakHandle.hpp ! src/hotspot/share/prims/resolvedMethodTable.cpp ! src/hotspot/share/prims/resolvedMethodTable.hpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/serviceThread.cpp ! test/hotspot/jtreg/runtime/MemberName/MemberNameLeak.java + test/hotspot/jtreg/runtime/testlibrary/ClassWithManyMethodsClassLoader.java ! test/lib/sun/hotspot/WhiteBox.java Changeset: a84c46287f28 Author: jlahoda Date: 2019-04-11 14:49 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a84c46287f28 8215407: javac should reject class files with bad EnclosingMethod attributes Summary: Reject classfiles with broken EnclosingMethod attribute. Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/langtools/tools/javac/classreader/8215407/BrokenEnclosingClass.java + test/langtools/tools/javac/classreader/8215407/Enclosing$1.jcod + test/langtools/tools/javac/classreader/8215407/UnrelatedClass.jcod Changeset: 2fd0422ac495 Author: clanger Date: 2019-04-11 15:36 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/2fd0422ac495 8221979: Cleanups for building Windows resources Reviewed-by: erikj ! make/autoconf/flags-other.m4 ! make/launcher/Launcher-jdk.accessibility.gmk ! src/hotspot/os/windows/version.rc ! src/java.base/windows/native/common/version.rc ! src/java.desktop/windows/native/libawt/windows/awt.rc - src/jdk.accessibility/windows/native/common/AccessBridgeStatusWindow.RC + src/jdk.accessibility/windows/native/common/AccessBridgeStatusWindow.rc ! src/jdk.accessibility/windows/native/common/resource.h ! src/jdk.accessibility/windows/native/jaccessinspector/jaccessinspectorWindow.rc ! src/jdk.accessibility/windows/native/jaccesswalker/jaccesswalkerWindow.rc Changeset: b0651dcc8d98 Author: jlahoda Date: 2019-04-11 17:55 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b0651dcc8d98 8217047: Provide a way to inject missing parameter names Summary: Adding a way to provide parameter names that are missing in the classfiles. Reviewed-by: darcy, jjg ! src/jdk.compiler/share/classes/com/sun/source/util/JavacTask.java + src/jdk.compiler/share/classes/com/sun/source/util/ParameterNameProvider.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java + src/jdk.compiler/share/classes/com/sun/tools/javac/code/MissingInfoHandler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/langtools/tools/javac/api/lazy/LoadParameterNamesLazily.java Changeset: 138f47e9d8c4 Author: shade Date: 2019-04-11 19:09 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/138f47e9d8c4 8222333: fastdebug build broken after JDK-8221393 (phase_mapping[] doesn't match enum Phase in WeakProcessorPhases) Reviewed-by: zgu, shade Contributed-by: Ao Qi ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Changeset: 5b1ad4cbe59e Author: shurailine Date: 2019-04-11 03:05 -0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/5b1ad4cbe59e 8221857: Collect code coverage for a subset of code Reviewed-by: erikj ! make/Coverage.gmk ! make/RunTests.gmk ! make/autoconf/jdk-options.m4 ! make/autoconf/spec.gmk.in Changeset: c201ca660afd Author: dcubed Date: 2019-04-11 14:14 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/c201ca660afd 8222034: Thread-SMR functions should be updated to remove work around Reviewed-by: mdoerr, eosterlund ! src/hotspot/share/runtime/threadSMR.cpp Changeset: 50b34791a1d2 Author: smarks Date: 2019-04-11 12:06 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/50b34791a1d2 8217405: rmic should reject class files with preview features enabled Reviewed-by: lancea, alanb ! src/jdk.rmic/share/classes/sun/tools/java/BinaryClass.java ! src/jdk.rmic/share/classes/sun/tools/java/RuntimeConstants.java ! src/jdk.rmic/share/classes/sun/tools/javac/resources/javac.properties Changeset: a2795025f417 Author: dholmes Date: 2019-04-11 19:36 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a2795025f417 8222090: Add Hygon Dhyana processor support Reviewed-by: kvn, dholmes, coleenp, rwestberg Contributed-by: Jinke Fan ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/vm_version_ext_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp Changeset: f48312257bc6 Author: vromero Date: 2019-04-11 22:56 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f48312257bc6 8222151: refactoring: enhancements to java.lang.Class::methodToString and java.lang.Class::getTypeName Reviewed-by: darcy Contributed-by: sergei.tsypanov at yandex.ru ! src/java.base/share/classes/java/lang/Class.java Changeset: 8de62c4af8c7 Author: weijun Date: 2019-04-12 13:35 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/8de62c4af8c7 8180573: Refactor sun/security/tools shell tests to plain java tests Reviewed-by: rhalade, valeriep + test/jdk/sun/security/tools/jarsigner/AlgOptions.java - test/jdk/sun/security/tools/jarsigner/AlgOptions.sh + test/jdk/sun/security/tools/jarsigner/CertPolicy.java + test/jdk/sun/security/tools/jarsigner/CheckUsage.java + test/jdk/sun/security/tools/jarsigner/Collator.java + test/jdk/sun/security/tools/jarsigner/ConciseJarsigner.java + test/jdk/sun/security/tools/jarsigner/Crl.java + test/jdk/sun/security/tools/jarsigner/DefaultOptions.java + test/jdk/sun/security/tools/jarsigner/DiffEnd.java + test/jdk/sun/security/tools/jarsigner/EC.java + test/jdk/sun/security/tools/jarsigner/EmptyManifest.java ! test/jdk/sun/security/tools/jarsigner/EntriesOrder.java + test/jdk/sun/security/tools/jarsigner/JvIndex.java + test/jdk/sun/security/tools/jarsigner/NameClash.java + test/jdk/sun/security/tools/jarsigner/NewSize7.java + test/jdk/sun/security/tools/jarsigner/OldSig.java + test/jdk/sun/security/tools/jarsigner/OnlyManifest.java ! test/jdk/sun/security/tools/jarsigner/Options.java + test/jdk/sun/security/tools/jarsigner/PassType.java + test/jdk/sun/security/tools/jarsigner/PercentSign.java - test/jdk/sun/security/tools/jarsigner/PercentSign.sh + test/jdk/sun/security/tools/jarsigner/SameName.java + test/jdk/sun/security/tools/jarsigner/WeakSize.java - test/jdk/sun/security/tools/jarsigner/certpolicy.sh - test/jdk/sun/security/tools/jarsigner/checkusage.sh - test/jdk/sun/security/tools/jarsigner/collator.sh - test/jdk/sun/security/tools/jarsigner/concise_jarsigner.sh - test/jdk/sun/security/tools/jarsigner/crl.sh - test/jdk/sun/security/tools/jarsigner/default_options.sh - test/jdk/sun/security/tools/jarsigner/diffend.sh - test/jdk/sun/security/tools/jarsigner/ec.sh - test/jdk/sun/security/tools/jarsigner/emptymanifest.sh - test/jdk/sun/security/tools/jarsigner/jvindex.sh - test/jdk/sun/security/tools/jarsigner/nameclash.sh - test/jdk/sun/security/tools/jarsigner/newsize7.sh - test/jdk/sun/security/tools/jarsigner/oldsig.sh - test/jdk/sun/security/tools/jarsigner/onlymanifest.sh - test/jdk/sun/security/tools/jarsigner/passtype.sh - test/jdk/sun/security/tools/jarsigner/samename.sh - test/jdk/sun/security/tools/jarsigner/weaksize.sh + test/jdk/sun/security/tools/keytool/CloneKeyAskPassword.java - test/jdk/sun/security/tools/keytool/CloneKeyAskPassword.sh + test/jdk/sun/security/tools/keytool/DefaultOptions.java + test/jdk/sun/security/tools/keytool/EmptySubject.java + test/jdk/sun/security/tools/keytool/FileInHelp.java + test/jdk/sun/security/tools/keytool/ImportReadAll.java + test/jdk/sun/security/tools/keytool/KeyAlg.java + test/jdk/sun/security/tools/keytool/NewHelp.java + test/jdk/sun/security/tools/keytool/NoExtNPE.java - test/jdk/sun/security/tools/keytool/NoExtNPE.sh + test/jdk/sun/security/tools/keytool/Resource.java + test/jdk/sun/security/tools/keytool/SecretKeyKS.java - test/jdk/sun/security/tools/keytool/SecretKeyKS.sh + test/jdk/sun/security/tools/keytool/SecurityToolsTest.java + test/jdk/sun/security/tools/keytool/SelfIssued.java + test/jdk/sun/security/tools/keytool/StandardAlgName.java - test/jdk/sun/security/tools/keytool/StandardAlgName.sh ! test/jdk/sun/security/tools/keytool/StorePasswords.java - test/jdk/sun/security/tools/keytool/StorePasswordsByShell.sh + test/jdk/sun/security/tools/keytool/TryStore.java - test/jdk/sun/security/tools/keytool/default_options.sh - test/jdk/sun/security/tools/keytool/emptysubject.sh - test/jdk/sun/security/tools/keytool/file-in-help.sh ! test/jdk/sun/security/tools/keytool/i18n.html ! test/jdk/sun/security/tools/keytool/i18n.java - test/jdk/sun/security/tools/keytool/i18n.sh - test/jdk/sun/security/tools/keytool/importreadall.sh - test/jdk/sun/security/tools/keytool/keyalg.sh - test/jdk/sun/security/tools/keytool/newhelp.sh - test/jdk/sun/security/tools/keytool/resource.sh - test/jdk/sun/security/tools/keytool/selfissued.sh - test/jdk/sun/security/tools/keytool/trystore.sh ! test/lib/jdk/test/lib/SecurityTools.java Changeset: 60bc754b9744 Author: zgu Date: 2019-04-12 07:51 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/60bc754b9744 8222188: Shenandoah: Adjust Shenandoah work gang types Reviewed-by: shade, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp Changeset: 5df03f58d25b Author: coleenp Date: 2019-04-12 09:30 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/5df03f58d25b 8222297: IRT_ENTRY/IRT_LEAF etc are the same as JRT Summary: Replace IRT entry points with JRT. Reviewed-by: lfoltan, dcubed ! src/hotspot/cpu/aarch64/interpreterRT_aarch64.cpp ! src/hotspot/cpu/arm/interpreterRT_arm.cpp ! src/hotspot/cpu/ppc/interpreterRT_ppc.cpp ! src/hotspot/cpu/s390/interpreterRT_s390.cpp ! src/hotspot/cpu/sparc/interpreterRT_sparc.cpp ! src/hotspot/cpu/x86/interpreterRT_x86_32.cpp ! src/hotspot/cpu/x86/interpreterRT_x86_64.cpp ! src/hotspot/cpu/zero/cppInterpreter_zero.cpp ! src/hotspot/cpu/zero/interpreterRT_zero.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp Changeset: 33fda525ad41 Author: zgu Date: 2019-04-12 09:55 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/33fda525ad41 8222403: Shenandoah: Remove ShenandoahAlwaysTrueClosure, use AlwaysTrueClosure instead Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.cpp Changeset: 5ae4d3f46537 Author: mseledtsov Date: 2019-04-12 12:26 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/5ae4d3f46537 8222299: [TESTBUG] move hotspot container tests to hotspot/containers Summary: Moved the tests, updated relevant files Reviewed-by: dholmes, iignatyev ! doc/testing.html ! doc/testing.md ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/containers/cgroup/PlainRead.java + test/hotspot/jtreg/containers/docker/AttemptOOM.java + test/hotspot/jtreg/containers/docker/CheckContainerized.java + test/hotspot/jtreg/containers/docker/DockerBasicTest.java + test/hotspot/jtreg/containers/docker/HelloDocker.java + test/hotspot/jtreg/containers/docker/JfrReporter.java + test/hotspot/jtreg/containers/docker/PrintContainerInfo.java + test/hotspot/jtreg/containers/docker/TEST.properties + test/hotspot/jtreg/containers/docker/TestCPUAwareness.java + test/hotspot/jtreg/containers/docker/TestCPUSets.java + test/hotspot/jtreg/containers/docker/TestJFREvents.java + test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java + test/hotspot/jtreg/containers/docker/TestMisc.java - test/hotspot/jtreg/runtime/containers/cgroup/PlainRead.java - test/hotspot/jtreg/runtime/containers/docker/AttemptOOM.java - test/hotspot/jtreg/runtime/containers/docker/CheckContainerized.java - test/hotspot/jtreg/runtime/containers/docker/DockerBasicTest.java - test/hotspot/jtreg/runtime/containers/docker/HelloDocker.java - test/hotspot/jtreg/runtime/containers/docker/JfrReporter.java - test/hotspot/jtreg/runtime/containers/docker/PrintContainerInfo.java - test/hotspot/jtreg/runtime/containers/docker/TEST.properties - test/hotspot/jtreg/runtime/containers/docker/TestCPUAwareness.java - test/hotspot/jtreg/runtime/containers/docker/TestCPUSets.java - test/hotspot/jtreg/runtime/containers/docker/TestJFREvents.java - test/hotspot/jtreg/runtime/containers/docker/TestMemoryAwareness.java - test/hotspot/jtreg/runtime/containers/docker/TestMisc.java ! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java Changeset: 94148bed13c4 Author: zgu Date: 2019-04-12 16:30 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/94148bed13c4 8222419: Shenandoah: Remove unused _par_state_string in ShenandoahRootProcessor Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp Changeset: 96d290a7e94f Author: epavlova Date: 2019-04-12 14:13 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/96d290a7e94f 8208066: compiler/graalunit/JttThreadsTest.java failed with org.junit.runners.model.TestTimedOutException: test timed out after 20 seconds Reviewed-by: iignatyev ! test/hotspot/jtreg/ProblemList-graal.txt ! test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java Changeset: ac56154f0b9e Author: weijun Date: 2019-04-14 10:22 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/ac56154f0b9e 8222275: sun/security/tools/keytool/Serial64.java: assertTrue: expected true, was false Reviewed-by: xuelei ! test/jdk/sun/security/tools/keytool/Serial64.java Changeset: d2c2622995e2 Author: dholmes Date: 2019-04-14 21:40 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/d2c2622995e2 8222387: Out-of-bounds access to CPU _family_id_xxx array Reviewed-by: dholmes, kvn Contributed-by: Jinke Fan ! src/hotspot/cpu/x86/vm_version_ext_x86.cpp ! src/hotspot/cpu/x86/vm_version_ext_x86.hpp Changeset: 00c0906bf4d1 Author: mdoerr Date: 2019-04-15 10:16 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/00c0906bf4d1 8220625: tools/javac/classreader/8171132/BadConstantValue.java failed with "did not see expected error" Reviewed-by: clanger ! test/langtools/tools/javac/classreader/8171132/BadConstantValue.java Changeset: edf1b4c6b936 Author: hannesw Date: 2019-04-15 15:38 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/edf1b4c6b936 8221644: jquery directory should be renamed Reviewed-by: jjg - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/external/jquery/jquery.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_55_fbf9ee_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_65_dadada_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_75_dadada_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_75_e6e6e6_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_95_fef1ec_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_highlight-soft_75_cccccc_1x100.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_222222_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_2e83ff_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_454545_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_888888_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_cd0a0a_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-3.3.1.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-migrate-3.0.1.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.min.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.structure.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.structure.min.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip/dist/jszip.min.js + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/external/jquery/jquery.js + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/images/ui-bg_glass_55_fbf9ee_1x400.png + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/images/ui-bg_glass_65_dadada_1x400.png + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/images/ui-bg_glass_75_dadada_1x400.png + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/images/ui-bg_glass_75_e6e6e6_1x400.png + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/images/ui-bg_glass_95_fef1ec_1x400.png + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/images/ui-bg_highlight-soft_75_cccccc_1x100.png + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/images/ui-icons_222222_256x240.png + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/images/ui-icons_2e83ff_256x240.png + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/images/ui-icons_454545_256x240.png + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/images/ui-icons_888888_256x240.png + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/images/ui-icons_cd0a0a_256x240.png + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-3.3.1.js + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-migrate-3.0.1.js + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-ui.css + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-ui.js + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-ui.min.css + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-ui.min.js + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-ui.structure.css + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jquery-ui.structure.min.css + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.js + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils-ie.min.js + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.js + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip-utils/dist/jszip-utils.min.js + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.js + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/script-dir/jszip/dist/jszip.min.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! test/langtools/jdk/javadoc/doclet/testOptions/help.html ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/langtools/jdk/javadoc/tool/api/basic/APITest.java Changeset: e9c62d960d64 Author: adinn Date: 2019-04-09 16:21 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/e9c62d960d64 8221397: Support implementation-defined Map Modes Summary: Allow implementation-defined extensions to FileChannel MapMode enum Reviewed-by: alanb ! src/java.base/share/classes/java/nio/channels/FileChannel.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java Changeset: 9219624244a6 Author: shade Date: 2019-04-15 18:22 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/9219624244a6 8222410: java/nio/file/attribute/BasicFileAttributeView/UnixSocketFile hangs when "nc" does not accept "-U" Reviewed-by: alanb ! test/jdk/java/nio/file/attribute/BasicFileAttributeView/UnixSocketFile.java Changeset: 66f5241da404 Author: shade Date: 2019-04-15 18:22 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/66f5241da404 8222397: x86_32 tests with UseSHA1Intrinsics SEGV due to garbled registers Reviewed-by: kvn, dsamersoff ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp Changeset: 377dcf569920 Author: zgu Date: 2019-04-15 12:54 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/377dcf569920 8222490: Shenandoah: Remove unused _par_state_string in ShenandoahRootEvacuator Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp Changeset: fb53a1c25903 Author: zgu Date: 2019-04-15 13:07 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/fb53a1c25903 8222425: Shenandoah: Move commonly used closures to separate files Reviewed-by: shade + src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp + src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp Changeset: 9d3117203dd3 Author: mseledtsov Date: 2019-04-15 11:44 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/9d3117203dd3 8221711: [TESTBUG] create more tests for JFR in container environment Summary: Added test cases for environment and network events Reviewed-by: egahlin + test/hotspot/jtreg/containers/docker/JfrNetwork.java ! test/hotspot/jtreg/containers/docker/JfrReporter.java ! test/hotspot/jtreg/containers/docker/TestJFREvents.java + test/hotspot/jtreg/containers/docker/TestJFRNetworkEvents.java ! test/jtreg-ext/requires/VMProps.java Changeset: ef331769d4ab Author: mseledtsov Date: 2019-04-15 12:35 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/ef331769d4ab 8222501: [TESTBUG] Docker support is always set to true in jtreg-ext/requires/VMProps.java Summary: Restored prior code Reviewed-by: dcubed ! test/jtreg-ext/requires/VMProps.java Changeset: bdbfa0115fc6 Author: darcy Date: 2019-04-15 15:44 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/bdbfa0115fc6 8222378: Provide mechanism to query preview feature status for annotation processors Reviewed-by: jjg ! src/java.compiler/share/classes/javax/annotation/processing/ProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/langtools/tools/javac/processing/environment/TestPreviewEnabled.java Changeset: 4de70bc80f24 Author: darcy Date: 2019-04-15 16:05 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/4de70bc80f24 8222430: Add tests for ElementKind predicates Reviewed-by: jjg + test/langtools/tools/javac/processing/model/element/TestElementKindPredicates.java Changeset: 9ff8d175035d Author: qpzhang Date: 2019-04-09 18:46 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/9ff8d175035d 8163363: AArch64: Stack size in tools/launcher/Settings.java needs to be adjusted Summary: Specify a proper min stack size input to -Xss for aarch64 Reviewed-by: aph ! test/jdk/tools/launcher/Settings.java Changeset: 0a4214c90a55 Author: rrich Date: 2019-04-16 08:51 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/0a4214c90a55 8222271: [s390] optimize register usage in C2 instruction forms for clearing arrays Reviewed-by: mdoerr, lucy ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.hpp ! src/hotspot/cpu/s390/s390.ad Changeset: 4fc566b7a9c0 Author: qpzhang Date: 2019-04-16 11:00 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/4fc566b7a9c0 8222334: java -Xss0 triggers StackOverflowError Summary: Launcher to use the stack size decided by hotpot or system if -Xss is 0 Reviewed-by: dholmes, alanb ! src/java.base/share/native/libjli/java.c ! test/hotspot/jtreg/runtime/Thread/TooSmallStackSize.java ! test/jdk/tools/launcher/TooSmallStackSize.java Changeset: 97a4b8f46a49 Author: pmuthuswamy Date: 2019-04-16 17:56 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/97a4b8f46a49 8222395: Refactor the abstract classes of package and module index writer Reviewed-by: hannesw - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractOverviewIndexWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractPackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties Changeset: 3362898da451 Author: coleenp Date: 2019-04-16 10:01 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/3362898da451 8220743: [TESTBUG] Review Runtime tests recently migrated from JDK subdirs Summary: removed tests that will not find bugs in current code base. Reviewed-by: lfoltan, hseigel - test/hotspot/jtreg/runtime/ErrorHandling/ExplicitArithmeticCheck.java - test/hotspot/jtreg/runtime/Thread/MonitorCacheMaybeExpand_DeadLock.java - test/hotspot/jtreg/runtime/interpreter/WideStrictInline.java Changeset: 460996cd27f9 Author: clanger Date: 2019-04-16 17:15 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/460996cd27f9 8222522: Add configure options for Mac Bundle creation Reviewed-by: erikj ! make/autoconf/jdk-version.m4 Changeset: 53aecb049e0a Author: hannesw Date: 2019-04-16 18:22 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/53aecb049e0a 8222528: Fix javadoc headers in Nashorn sources Reviewed-by: sundar ! src/jdk.dynalink/share/classes/jdk/dynalink/NamespaceOperation.java ! src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/linker/NameCodec.java ! src/jdk.scripting.nashorn/share/classes/module-info.java Changeset: b057e09eef80 Author: manc Date: 2019-04-15 18:37 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b057e09eef80 8222510: Small cleanup for JDK launcher's make file Reviewed-by: clanger, erikj ! make/launcher/Launcher-java.base.gmk ! make/launcher/LauncherCommon.gmk Changeset: 02ef86858896 Author: joehw Date: 2019-04-16 21:29 +0000 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/02ef86858896 8222415: Xerces 2.12.0: Parsing Configuration Reviewed-by: lancea ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! test/jaxp/javax/xml/jaxp/unittest/parsers/BaseParsingTest.java Changeset: 5fa7fbddfe9d Author: redestad Date: 2019-04-17 00:06 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/5fa7fbddfe9d 8222484: Specialize generation of simple String concatenation expressions Reviewed-by: jrose, jlaskey ! make/jdk/src/classes/build/tools/classlist/HelloClasslist.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/StringConcatHelper.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! test/micro/org/openjdk/bench/java/lang/StringConcat.java Changeset: 6f8a7671afef Author: xuelei Date: 2019-04-16 16:59 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/6f8a7671afef 8216326: SSLSocket stream close() does not close the associated socket Reviewed-by: jnimeh ! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java + test/jdk/javax/net/ssl/SSLSocket/InputStreamClosure.java + test/jdk/javax/net/ssl/SSLSocket/OutputStreamClosure.java Changeset: c09bdb9043f1 Author: ccheung Date: 2018-12-12 11:57 -0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/c09bdb9043f1 8214809: CDS storage improvements Reviewed-by: acorn, iklam, ahgross, rhalade ! src/hotspot/share/classfile/classFileParser.cpp ! test/hotspot/jtreg/runtime/appcds/OldClassTest.java Changeset: 62771002a1cb Author: henryjen Date: 2019-01-22 14:14 -0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/62771002a1cb Merge ! src/hotspot/share/classfile/classFileParser.cpp - src/hotspot/share/gc/g1/evacuationInfo.hpp - src/hotspot/share/runtime/arguments_ext.hpp - src/hotspot/share/services/diagnosticCommand_ext.hpp - src/java.desktop/share/classes/sun/awt/Graphics2Delegate.java - src/java.desktop/share/classes/sun/awt/TracedEventQueue.java - src/java.desktop/share/classes/sun/awt/image/BadDepthException.java - src/utils/LogCompilation/src/test/resources/hotspot_pid23756.log - src/utils/LogCompilation/src/test/resources/hotspot_pid25109.log - src/utils/LogCompilation/src/test/resources/no_tiered_short.log - src/utils/LogCompilation/src/test/resources/tiered_short.log - test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorEventsForTwoThreadsTest.java - test/jdk/java/lang/String/AlignIndent.java - test/jdk/java/net/MulticastSocket/PromiscuousIPv6.java - test/jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java - test/jdk/javax/net/ssl/compatibility/Parameter.java - test/jdk/sun/security/util/Resources/NewNamesFormat.java - test/jdk/sun/security/util/Resources/NewResourcesNames.java - test/langtools/jdk/javadoc/doclet/lib/JavadocTester.java - test/langtools/jdk/javadoc/doclet/testHtmlLandmarkRegions/TestHtmlLankmarkRegions.java - test/langtools/tools/javac/RawStringLiteralLang.java - test/langtools/tools/javac/RawStringLiteralLangAPI.java - test/langtools/tools/javac/diags/examples/RawStringLiteral.java Changeset: c171aa9e5d3e Author: henryjen Date: 2019-03-26 10:55 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/c171aa9e5d3e Merge - make/devkit/createMacosxDevkit6.sh - make/devkit/createMacosxDevkit9.sh - make/devkit/createWindowsDevkit2013.sh - make/devkit/createWindowsDevkit2015.sh - make/gensrc/GensrcCLDR.gmk - src/hotspot/os_cpu/linux_aarch64/linux_aarch64.ad - src/hotspot/os_cpu/linux_sparc/linux_sparc.ad - src/hotspot/os_cpu/linux_x86/gc/z/zLargePages_linux_x86.cpp - src/hotspot/os_cpu/linux_x86/gc/z/zNUMA_linux_x86.cpp - src/hotspot/os_cpu/linux_x86/gc/z/zVirtualMemory_linux_x86.cpp ! src/hotspot/share/classfile/classFileParser.cpp - src/hotspot/share/classfile/dictionary.inline.hpp - src/hotspot/share/code/relocInfo_ext.cpp - src/hotspot/share/code/relocInfo_ext.hpp - src/hotspot/share/gc/g1/collectionSetChooser.cpp - src/hotspot/share/gc/g1/collectionSetChooser.hpp - src/hotspot/share/gc/g1/dirtyCardQueue.cpp - src/hotspot/share/gc/g1/dirtyCardQueue.hpp - src/hotspot/share/gc/z/zAddressRangeMap.hpp - src/hotspot/share/gc/z/zAddressRangeMap.inline.hpp - src/hotspot/share/gc/z/zForwardingTableEntry.hpp - src/hotspot/share/gc/z/zPageTableEntry.hpp - src/hotspot/share/gc/z/zStatTLAB.cpp - src/hotspot/share/gc/z/zStatTLAB.hpp - src/hotspot/share/oops/array.inline.hpp - src/hotspot/share/prims/evmCompat.cpp - src/hotspot/share/utilities/intHisto.cpp - src/hotspot/share/utilities/intHisto.hpp - src/java.base/share/classes/com/sun/net/ssl/HostnameVerifier.java - src/java.base/share/classes/com/sun/net/ssl/HttpsURLConnection.java - src/java.base/share/classes/com/sun/net/ssl/KeyManager.java - src/java.base/share/classes/com/sun/net/ssl/KeyManagerFactory.java - src/java.base/share/classes/com/sun/net/ssl/KeyManagerFactorySpi.java - src/java.base/share/classes/com/sun/net/ssl/SSLContext.java - src/java.base/share/classes/com/sun/net/ssl/SSLContextSpi.java - src/java.base/share/classes/com/sun/net/ssl/SSLPermission.java - src/java.base/share/classes/com/sun/net/ssl/SSLSecurity.java - src/java.base/share/classes/com/sun/net/ssl/TrustManager.java - src/java.base/share/classes/com/sun/net/ssl/TrustManagerFactory.java - src/java.base/share/classes/com/sun/net/ssl/TrustManagerFactorySpi.java - src/java.base/share/classes/com/sun/net/ssl/X509KeyManager.java - src/java.base/share/classes/com/sun/net/ssl/X509TrustManager.java - src/java.base/share/classes/com/sun/net/ssl/internal/ssl/Provider.java - src/java.base/share/classes/com/sun/net/ssl/internal/ssl/X509ExtendedTrustManager.java - src/java.base/share/classes/com/sun/net/ssl/internal/www/protocol/https/DelegateHttpsURLConnection.java - src/java.base/share/classes/com/sun/net/ssl/internal/www/protocol/https/Handler.java - src/java.base/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java - src/java.base/share/classes/com/sun/net/ssl/package-info.java - src/java.base/unix/native/libnio/ch/ServerSocketChannelImpl.c - src/java.base/unix/native/libnio/ch/SocketChannelImpl.c ! src/java.base/unix/native/libnio/ch/SocketDispatcher.c - src/java.base/unix/native/libnio/ch/UnixAsynchronousServerSocketChannelImpl.c - src/java.base/windows/native/libnio/ch/ServerSocketChannelImpl.c - src/java.base/windows/native/libnio/ch/SocketChannelImpl.c - src/java.desktop/share/classes/sun/awt/AWTSecurityManager.java - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-atomic-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-blob-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-buffer-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-face-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-font-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-map-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-mutex-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-object-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-open-file-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-open-type-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-layout-common-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-layout-gsubgpos-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-layout-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-map-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-indic-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-khmer-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-myanmar-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-tibetan.cc - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-use-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-normalize-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-tag.h - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-set-digest-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-set-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-shape-plan-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-shaper-impl-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-shaper-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-subset-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-unicode-private.hh - src/java.desktop/share/native/libfontmanager/harfbuzz/hb-utf-private.hh - src/java.desktop/windows/native/libawt/windows/awt_Robot.h - src/java.smartcardio/unix/native/libj2pcsc/MUSCLE/COPYING - src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/BaseStructure.java - src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Marshaller.java - src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XmlWriter.java - src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XmlWriterToTree.java - src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/output_html.properties - src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/output_text.properties - src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/output_unknown.properties - src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/output_xml.properties - src/java.xml/share/classes/com/sun/org/apache/xpath/internal/SourceTreeManager.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZAddressRangeMapForPageTable.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.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotMaths.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/ArrayRangeWriteBarrier.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/G1ArrayRangePostWriteBarrier.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/G1ArrayRangePreWriteBarrier.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/G1PostWriteBarrier.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/G1PreWriteBarrier.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/G1ReferentFieldReadBarrier.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/ObjectWriteBarrier.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/SerialArrayRangeWriteBarrier.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/nodes/SerialWriteBarrier.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/IntegerExactOpSpeculation.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/ConvertDeoptimizeToGuardPhase.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.amd64/src/org/graalvm/compiler/replacements/amd64/AMD64MathSubstitutions.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/arithmetic/IntegerMulHighNode.java - src/jdk.javadoc/share/classes/com/sun/javadoc/AnnotatedType.java - src/jdk.javadoc/share/classes/com/sun/javadoc/AnnotationDesc.java - src/jdk.javadoc/share/classes/com/sun/javadoc/AnnotationTypeDoc.java - src/jdk.javadoc/share/classes/com/sun/javadoc/AnnotationTypeElementDoc.java - src/jdk.javadoc/share/classes/com/sun/javadoc/AnnotationValue.java - src/jdk.javadoc/share/classes/com/sun/javadoc/ClassDoc.java - src/jdk.javadoc/share/classes/com/sun/javadoc/ConstructorDoc.java - src/jdk.javadoc/share/classes/com/sun/javadoc/Doc.java - src/jdk.javadoc/share/classes/com/sun/javadoc/DocErrorReporter.java - src/jdk.javadoc/share/classes/com/sun/javadoc/Doclet.java - src/jdk.javadoc/share/classes/com/sun/javadoc/ExecutableMemberDoc.java - src/jdk.javadoc/share/classes/com/sun/javadoc/FieldDoc.java - src/jdk.javadoc/share/classes/com/sun/javadoc/LanguageVersion.java - src/jdk.javadoc/share/classes/com/sun/javadoc/MemberDoc.java - src/jdk.javadoc/share/classes/com/sun/javadoc/MethodDoc.java - src/jdk.javadoc/share/classes/com/sun/javadoc/PackageDoc.java - src/jdk.javadoc/share/classes/com/sun/javadoc/ParamTag.java - src/jdk.javadoc/share/classes/com/sun/javadoc/Parameter.java - src/jdk.javadoc/share/classes/com/sun/javadoc/ParameterizedType.java - src/jdk.javadoc/share/classes/com/sun/javadoc/ProgramElementDoc.java - src/jdk.javadoc/share/classes/com/sun/javadoc/RootDoc.java - src/jdk.javadoc/share/classes/com/sun/javadoc/SeeTag.java - src/jdk.javadoc/share/classes/com/sun/javadoc/SerialFieldTag.java - src/jdk.javadoc/share/classes/com/sun/javadoc/SourcePosition.java - src/jdk.javadoc/share/classes/com/sun/javadoc/Tag.java - src/jdk.javadoc/share/classes/com/sun/javadoc/ThrowsTag.java - src/jdk.javadoc/share/classes/com/sun/javadoc/Type.java - src/jdk.javadoc/share/classes/com/sun/javadoc/TypeVariable.java - src/jdk.javadoc/share/classes/com/sun/javadoc/WildcardType.java - src/jdk.javadoc/share/classes/com/sun/javadoc/package-info.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/standard/Standard.java - src/jdk.javadoc/share/classes/com/sun/tools/doclets/standard/package-info.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/Main.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AbstractTypeImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotatedTypeImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotationDescImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotationTypeDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotationTypeElementDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/AnnotationValueImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ClassDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/Comment.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ConstructorDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocEnv.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocLocale.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/DocletInvoker.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ExecutableMemberDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/FieldDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavaScriptScanner.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavadocClassFinder.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavadocEnter.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavadocMemberEnter.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavadocTodo.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/JavadocTool.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/MemberDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/Messager.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/MethodDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ModifierFilter.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/PackageDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ParamTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ParameterImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ParameterizedTypeImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/PrimitiveType.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ProgramElementDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/RootDocImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/SeeTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/SerialFieldTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/SerializedForm.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/SourcePositionImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/Start.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/TagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ThrowsTagImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/ToolOption.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/TypeMaker.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/TypeVariableImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/main/WildcardTypeImpl.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/package-info.java - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc.properties - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties - src/jdk.javadoc/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlConstants.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlVersion.java - src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripDebugPlugin.java - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/bcp47/timezone.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/dtd/ldml.dtd - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/dtd/ldmlBCP47.dtd - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/dtd/ldmlSupplemental.dtd - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/af.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/af_NA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/af_ZA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/agq.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/agq_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ak.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ak_GH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/am.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/am_ET.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_001.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_AE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_BH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_DJ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_DZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_EG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_EH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_ER.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_IL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_IQ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_JO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_KM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_KW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_LB.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_LY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_MA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_MR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_OM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_PS.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_QA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_SA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_SD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_SO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_SS.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_SY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_TD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_TN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ar_YE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/as.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/as_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/asa.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/asa_TZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ast.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ast_ES.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/az.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/az_Cyrl.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/az_Cyrl_AZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/az_Latn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/az_Latn_AZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bas.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bas_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/be.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/be_BY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bem.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bem_ZM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bez.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bez_TZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bg.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bg_BG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bm.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bm_ML.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bn_BD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bn_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bo_CN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bo_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/br.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/br_FR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/brx.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/brx_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bs.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bs_Cyrl.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bs_Cyrl_BA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bs_Latn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/bs_Latn_BA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ca.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ca_AD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ca_ES.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ca_ES_VALENCIA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ca_FR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ca_IT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ccp.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ccp_BD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ccp_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ce.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ce_RU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/cgg.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/cgg_UG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/chr.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/chr_US.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ckb.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ckb_IQ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ckb_IR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/cs.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/cs_CZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/cu.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/cu_RU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/cy.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/cy_GB.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/da.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/da_DK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/da_GL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/dav.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/dav_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/de.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/de_AT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/de_BE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/de_CH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/de_DE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/de_IT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/de_LI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/de_LU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/dje.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/dje_NE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/dsb.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/dsb_DE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/dua.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/dua_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/dyo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/dyo_SN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/dz.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/dz_BT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ebu.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ebu_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ee.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ee_GH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ee_TG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/el.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/el_CY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/el_GR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_001.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_150.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_AG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_AI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_AS.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_AT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_AU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_BB.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_BE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_BI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_BM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_BS.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_BW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_BZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_CA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_CC.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_CH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_CK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_CX.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_CY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_DE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_DG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_DK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_DM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_ER.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_FI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_FJ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_FK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_FM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_GB.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_GD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_GG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_GH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_GI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_GM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_GU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_GY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_HK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_IE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_IL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_IM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_IO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_JE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_JM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_KI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_KN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_KY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_LC.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_LR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_LS.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_MG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_MH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_MO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_MP.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_MS.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_MT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_MU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_MW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_MY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_NA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_NF.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_NG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_NL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_NR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_NU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_NZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_PG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_PH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_PK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_PN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_PR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_PW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_RW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_SB.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_SC.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_SD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_SE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_SG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_SH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_SI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_SL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_SS.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_SX.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_SZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_TC.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_TK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_TO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_TT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_TV.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_TZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_UG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_UM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_US.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_US_POSIX.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_VC.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_VG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_VI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_VU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_WS.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_ZA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_ZM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/en_ZW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/eo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/eo_001.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_419.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_AR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_BO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_BR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_BZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_CL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_CO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_CR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_CU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_DO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_EA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_EC.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_ES.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_GQ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_GT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_HN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_IC.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_MX.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_NI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_PA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_PE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_PH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_PR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_PY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_SV.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_US.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_UY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/es_VE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/et.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/et_EE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/eu.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/eu_ES.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ewo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ewo_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fa.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fa_AF.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fa_IR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ff.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ff_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ff_GN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ff_MR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ff_SN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fi.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fi_FI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fil.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fil_PH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fo_DK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fo_FO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_BE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_BF.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_BI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_BJ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_BL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_CA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_CD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_CF.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_CG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_CH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_CI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_DJ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_DZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_FR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_GA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_GF.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_GN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_GP.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_GQ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_HT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_KM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_LU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_MA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_MC.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_MF.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_MG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_ML.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_MQ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_MR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_MU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_NC.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_NE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_PF.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_PM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_RE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_RW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_SC.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_SN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_SY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_TD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_TG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_TN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_VU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_WF.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fr_YT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fur.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fur_IT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fy.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/fy_NL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ga.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ga_IE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/gd.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/gd_GB.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/gl.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/gl_ES.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/gsw.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/gsw_CH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/gsw_FR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/gsw_LI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/gu.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/gu_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/guz.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/guz_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/gv.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/gv_IM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ha.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ha_GH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ha_NE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ha_NG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/haw.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/haw_US.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/he.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/he_IL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/hi.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/hi_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/hr.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/hr_BA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/hr_HR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/hsb.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/hsb_DE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/hu.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/hu_HU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/hy.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/hy_AM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/id.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/id_ID.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ig.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ig_NG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ii.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ii_CN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/is.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/is_IS.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/it.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/it_CH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/it_IT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/it_SM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/it_VA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ja.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ja_JP.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/jgo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/jgo_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/jmc.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/jmc_TZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ka.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ka_GE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kab.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kab_DZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kam.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kam_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kde.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kde_TZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kea.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kea_CV.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/khq.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/khq_ML.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ki.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ki_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kk.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kk_KZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kkj.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kkj_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kl.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kl_GL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kln.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kln_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/km.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/km_KH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kn_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ko.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ko_KP.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ko_KR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kok.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kok_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ks.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ks_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ksb.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ksb_TZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ksf.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ksf_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ksh.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ksh_DE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kw.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/kw_GB.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ky.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ky_KG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lag.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lag_TZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lb.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lb_LU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lg.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lg_UG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lkt.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lkt_US.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ln.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ln_AO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ln_CD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ln_CF.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ln_CG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lo_LA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lrc.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lrc_IQ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lrc_IR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lt.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lt_LT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lu.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lu_CD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/luo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/luo_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/luy.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/luy_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lv.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/lv_LV.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mas.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mas_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mas_TZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mer.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mer_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mfe.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mfe_MU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mg.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mg_MG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mgh.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mgh_MZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mgo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mgo_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mk.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mk_MK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ml.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ml_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mn_MN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mr.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mr_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ms.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ms_BN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ms_MY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ms_SG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mt.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mt_MT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mua.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mua_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/my.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/my_MM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mzn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/mzn_IR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/naq.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/naq_NA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nb.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nb_NO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nb_SJ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nd.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nd_ZW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nds.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nds_DE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nds_NL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ne.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ne_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ne_NP.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nl.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nl_AW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nl_BE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nl_BQ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nl_CW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nl_NL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nl_SR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nl_SX.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nmg.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nmg_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nn_NO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nnh.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nnh_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nus.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nus_SS.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nyn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/nyn_UG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/om.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/om_ET.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/om_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/or.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/or_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/os.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/os_GE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/os_RU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pa.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pa_Arab.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pa_Arab_PK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pa_Guru.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pa_Guru_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pl.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pl_PL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/prg.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/prg_001.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ps.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ps_AF.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pt.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pt_AO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pt_BR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pt_CH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pt_CV.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pt_GQ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pt_GW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pt_LU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pt_MO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pt_MZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pt_PT.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pt_ST.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/pt_TL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/qu.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/qu_BO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/qu_EC.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/qu_PE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/rm.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/rm_CH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/rn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/rn_BI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ro.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ro_MD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ro_RO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/rof.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/rof_TZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/root.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ru.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ru_BY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ru_KG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ru_KZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ru_MD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ru_RU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ru_UA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/rw.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/rw_RW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/rwk.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/rwk_TZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sah.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sah_RU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/saq.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/saq_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sbp.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sbp_TZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sd.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sd_PK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/se.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/se_FI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/se_NO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/se_SE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/seh.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/seh_MZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ses.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ses_ML.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sg.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sg_CF.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/shi.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/shi_Latn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/shi_Latn_MA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/shi_Tfng.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/shi_Tfng_MA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/si.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/si_LK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sk.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sk_SK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sl.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sl_SI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/smn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/smn_FI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sn_ZW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/so.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/so_DJ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/so_ET.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/so_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/so_SO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sq.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sq_AL.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sq_MK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sq_XK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sr.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sr_Cyrl.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sr_Cyrl_BA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sr_Cyrl_ME.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sr_Cyrl_RS.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sr_Cyrl_XK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sr_Latn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sr_Latn_BA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sr_Latn_ME.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sr_Latn_RS.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sr_Latn_XK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sv.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sv_AX.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sv_FI.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sv_SE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sw.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sw_CD.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sw_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sw_TZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/sw_UG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ta.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ta_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ta_LK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ta_MY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ta_SG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/te.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/te_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/teo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/teo_KE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/teo_UG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/tg.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/tg_TJ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/th.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/th_TH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ti.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ti_ER.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ti_ET.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/tk.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/tk_TM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/to.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/to_TO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/tr.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/tr_CY.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/tr_TR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/tt.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/tt_RU.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/twq.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/twq_NE.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/tzm.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/tzm_MA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ug.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ug_CN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/uk.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/uk_UA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ur.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ur_IN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/ur_PK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/uz.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/uz_Arab.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/uz_Arab_AF.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/uz_Cyrl.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/uz_Cyrl_UZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/uz_Latn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/uz_Latn_UZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/vai.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/vai_Latn.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/vai_Latn_LR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/vai_Vaii.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/vai_Vaii_LR.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/vi.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/vi_VN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/vo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/vo_001.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/vun.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/vun_TZ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/wae.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/wae_CH.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/wo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/wo_SN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/xog.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/xog_UG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/yav.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/yav_CM.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/yi.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/yi_001.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/yo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/yo_BJ.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/yo_NG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/yue.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/yue_HK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/yue_Hans.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/yue_Hans_CN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/yue_Hant.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/yue_Hant_HK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zgh.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zgh_MA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zh.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zh_Hans.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zh_Hans_CN.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zh_Hans_HK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zh_Hans_MO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zh_Hans_SG.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zh_Hant.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zh_Hant_HK.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zh_Hant_MO.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zh_Hant_TW.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zu.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/main/zu_ZA.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/attributeValueValidity.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/characters.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/coverageLevels.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/dayPeriods.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/genderList.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/languageInfo.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/likelySubtags.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/metaZones.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/numberingSystems.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/ordinals.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/pluralRanges.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/plurals.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/rgScope.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/subdivisions.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/supplementalData.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/supplementalMetadata.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/telephoneCodeData.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/common/supplemental/windowsZones.xml - src/jdk.localedata/share/classes/sun/util/cldr/resources/unicode-license.txt - src/jdk.sctp/unix/native/libsctp/SctpServerChannelImpl.c - test/Makefile - test/TestCommon.gmk - test/hotspot/gtest/gc/z/test_zForwardingTable.cpp - test/hotspot/gtest/memory/test_virtualSpaceNode.cpp - test/hotspot/jtreg/Makefile - test/hotspot/jtreg/gc/g1/TestStringTableStats.java - test/hotspot/jtreg/runtime/RedefineObject/Agent.java - test/hotspot/jtreg/runtime/RedefineObject/TestRedefineObject.java - test/hotspot/jtreg/runtime/RedefineObject/WalkThroughInvoke.java - test/hotspot/jtreg/runtime/RedefineTests/ModifyAnonymous.java - test/hotspot/jtreg/runtime/RedefineTests/RedefineAddLambdaExpression.java - test/hotspot/jtreg/runtime/RedefineTests/RedefineAnnotations.java - test/hotspot/jtreg/runtime/RedefineTests/RedefineDoubleDelete.java - test/hotspot/jtreg/runtime/RedefineTests/RedefineFinalizer.java - test/hotspot/jtreg/runtime/RedefineTests/RedefineInterfaceCall.java - test/hotspot/jtreg/runtime/RedefineTests/RedefineInterfaceMethods.java - test/hotspot/jtreg/runtime/RedefineTests/RedefineLeak.java - test/hotspot/jtreg/runtime/RedefineTests/RedefinePreviousVersions.java - test/hotspot/jtreg/runtime/RedefineTests/RedefineRunningMethods.java - test/hotspot/jtreg/runtime/RedefineTests/RedefineRunningMethodsWithBacktrace.java - test/hotspot/jtreg/runtime/RedefineTests/RedefineRunningMethodsWithResolutionErrors.java - test/hotspot/jtreg/runtime/RedefineTests/RedefineSubtractLambdaExpression.java - test/hotspot/jtreg/runtime/RedefineTests/libRedefineDoubleDelete.c - test/hotspot/jtreg/serviceability/dcmd/framework/TEST.properties - test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/libHeapMonitorTest.c - test/hotspot/jtreg/serviceability/jvmti/RetransformClassesZeroLength.java - test/hotspot/jtreg/serviceability/jvmti/TestLambdaFormRetransformation.java - test/hotspot/jtreg/serviceability/jvmti/TestRedefineWithUnresolvedClass.java - test/hotspot/jtreg/serviceability/jvmti/UnresolvedClassAgent.java - test/hotspot/jtreg/serviceability/jvmti/UnresolvedClassAgent.mf - test/jaxp/Makefile - test/jdk/Makefile - test/jdk/com/sun/net/ssl/SSLSecurity/ComKeyManagerFactoryImpl.java - test/jdk/com/sun/net/ssl/SSLSecurity/ComSSLContextImpl.java - test/jdk/com/sun/net/ssl/SSLSecurity/ComTrustManagerFactoryImpl.java - test/jdk/com/sun/net/ssl/SSLSecurity/JavaxKeyManagerFactoryImpl.java - test/jdk/com/sun/net/ssl/SSLSecurity/JavaxSSLContextImpl.java - test/jdk/com/sun/net/ssl/SSLSecurity/JavaxTrustManagerFactoryImpl.java - test/jdk/com/sun/net/ssl/SSLSecurity/ProviderTest.java - test/jdk/com/sun/net/ssl/SSLSecurity/TruncateArray.java - test/jdk/java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html - test/jdk/java/awt/Choice/PopupPosTest/PopupPosTest.html - test/jdk/java/awt/Clipboard/HTMLTransferTest/HTMLTransferTest.html - test/jdk/java/awt/Component/F10TopToplevel/F10TopToplevel.html - test/jdk/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html - test/jdk/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.html - test/jdk/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.html - test/jdk/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.html - test/jdk/java/awt/Focus/ChildWindowFocusTest/ChildWindowFocusTest.html - test/jdk/java/awt/Focus/DeiconifiedFrameLoosesFocus/DeiconifiedFrameLoosesFocus.html - test/jdk/java/awt/Focus/FocusSubRequestTest/FocusSubRequestTest.html - test/jdk/java/awt/Focus/ModalBlockedStealsFocusTest/ModalBlockedStealsFocusTest.html - test/jdk/java/awt/Focus/ModalDialogInitialFocusTest/ModalDialogInitialFocusTest.html - test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.html - test/jdk/java/awt/Focus/NonFocusableBlockedOwnerTest/NonFocusableBlockedOwnerTest.html - test/jdk/java/awt/Focus/ToFrontFocusTest/ToFrontFocus.html - test/jdk/java/awt/Focus/WindowInitialFocusTest/WindowInitialFocusTest.html - test/jdk/java/awt/Focus/WindowUpdateFocusabilityTest/WindowUpdateFocusabilityTest.html - test/jdk/java/awt/FontClass/CreateFont/bigfont.html - test/jdk/java/awt/Frame/DisposeStressTest/DisposeStressTest.html - test/jdk/java/awt/Frame/NonEDT_GUI_DeadlockTest/NonEDT_GUI_Deadlock.html - test/jdk/java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest.html - test/jdk/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeForModalDialogTest/ConsumeForModalDialogTest.html - test/jdk/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest.html - test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.html - test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.html - test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html - test/jdk/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.html - test/jdk/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.html - test/jdk/java/awt/List/KeyEventsTest/KeyEventsTest.html - test/jdk/java/awt/Mouse/ExtraMouseClick/ExtraMouseClick.html - test/jdk/java/awt/Mouse/TitleBarDoubleClick/TitleBarDoubleClick.html - test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.html - test/jdk/java/awt/Window/HandleWindowDestroyTest/HandleWindowDestroyTest.html - test/jdk/java/awt/datatransfer/DragUnicodeBetweenJVMTest/DragUnicodeBetweenJVMTest.html - test/jdk/java/awt/datatransfer/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.html - test/jdk/java/awt/dnd/DragInterceptorAppletTest/DragInterceptorAppletTest.html - test/jdk/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.html - test/jdk/java/awt/dnd/ImageDecoratedDnDInOut/ImageDecoratedDnDInOut.html - test/jdk/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.html - test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.html - test/jdk/java/awt/dnd/NoFormatsCrashTest/NoFormatsCrashTest.html - test/jdk/java/awt/dnd/URIListBetweenJVMsTest/URIListBetweenJVMsTest.html - test/jdk/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.html - test/jdk/java/awt/event/ComponentEvent/MovedResizedTardyEventTest/MovedResizedTardyEventTest.html - test/jdk/java/awt/event/KeyEvent/KeyTyped/CtrlASCII.html - test/jdk/java/awt/event/MouseEvent/FrameMouseEventAbsoluteCoordsTest/FrameMouseEventAbsoluteCoordsTest.html - test/jdk/java/awt/event/MouseEvent/MenuDragMouseEventAbsoluteCoordsTest/MenuDragMouseEventAbsoluteCoordsTest.html - test/jdk/java/awt/event/MouseEvent/MouseClickTest/MouseClickTest.html - test/jdk/java/awt/event/MouseEvent/MouseWheelEventAbsoluteCoordsTest/MouseWheelEventAbsoluteCoordsTest.html - test/jdk/java/awt/event/MouseEvent/RobotLWTest/RobotLWTest.html - test/jdk/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.html - test/jdk/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.html - test/jdk/javax/imageio/AppletResourceTest.html - test/jdk/javax/net/ssl/FixingJavadocs/ComURLNulls.java - test/jdk/javax/net/ssl/SSLSession/CheckMyTrustedKeystore.java - test/jdk/javax/swing/JFrame/4962534/bug4962534.html - test/jdk/javax/swing/JPopupMenu/4634626/bug4634626.html - test/jdk/javax/swing/MultiUIDefaults/4300666/bug4300666.html - test/jdk/javax/swing/text/StyledEditorKit/4506788/bug4506788.html - test/jdk/sanity/client/TEST.ROOT.template - test/jdk/sun/java2d/cmm/ColorConvertOp/ConstructorsNullTest/ConstructorsNullTest.html - test/jdk/sun/net/www/protocol/https/NewImpl/ComHTTPSConnection.java - test/jdk/sun/net/www/protocol/https/NewImpl/ComHostnameVerifier.java - test/jdk/sun/security/krb5/auto/rcache_usemd5.sh - test/jdk/sun/security/krb5/tools/ktarg.sh - test/jdk/sun/security/krb5/tools/ktcheck.sh - test/jdk/sun/security/krb5/tools/ktmissing.sh - test/jdk/sun/security/krb5/tools/ktzero.sh - test/jdk/sun/security/pkcs11/fips/CipherTest.java - test/jdk/sun/security/pkcs11/fips/ClientJSSEServerJSSE.java - test/jdk/sun/security/pkcs11/fips/ImportKeyStore.java - test/jdk/sun/security/pkcs11/fips/JSSEClient.java - test/jdk/sun/security/pkcs11/fips/JSSEServer.java - test/jdk/sun/security/pkcs11/fips/TestTLS12.java - test/jdk/sun/security/pkcs11/fips/TrustManagerTest.java - test/jdk/sun/security/pkcs11/fips/TrustManagerTest.policy - test/jdk/sun/security/pkcs11/fips/cert8.db - test/jdk/sun/security/pkcs11/fips/certs/anchor.cer - test/jdk/sun/security/pkcs11/fips/certs/ca.cer - test/jdk/sun/security/pkcs11/fips/certs/server.cer - test/jdk/sun/security/pkcs11/fips/fips.cfg - test/jdk/sun/security/pkcs11/fips/key3.db - test/jdk/sun/security/pkcs11/fips/keystore - test/jdk/sun/security/pkcs11/fips/secmod.db - test/jdk/sun/security/pkcs11/fips/truststore - test/jdk/sun/security/ssl/X509TrustManagerImpl/ClientServer.java - test/jdk/tools/jlink/plugins/StripDebugPluginTest.java - test/jdk/vm/JniInvocationTest.java - test/jdk/vm/exeJniInvocationTest.c - test/jdk/vm/gc/ArraySize.java - test/jdk/vm/gc/InfiniteList.java - test/jdk/vm/jit/BadLogicCode.java - test/jdk/vm/jit/ExceptionInInit.java - test/jdk/vm/jit/JITClassInit.java - test/jdk/vm/runtime/ExplicitArithmeticCheck.java - test/jdk/vm/runtime/MonitorCacheMaybeExpand_DeadLock.java - test/jdk/vm/runtime/ReflectStackOverflow.java - test/jdk/vm/runtime/ShiftTest.java - test/jdk/vm/runtime/WideStrictInline.java - test/jdk/vm/verifier/TestStaticIF.java - test/jdk/vm/verifier/VerifyProtectedConstructor.java - test/jdk/vm/verifier/VerifyStackForExceptionHandlers.java - test/jdk/vm/verifier/defaultMethods/DefaultMethodRegressionTests.java - test/jdk/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java - test/langtools/Makefile - test/langtools/jdk/javadoc/doclet/testHtmlWarning/TestHtmlWarning.java - test/langtools/jdk/javadoc/tool/api/basic/GetTask_DocletClassTest.java - test/langtools/jdk/javadoc/tool/doclint/ImplicitHeadersTest.java - test/langtools/tools/javac/doclint/ImplicitHeadersTest.java - test/langtools/tools/javadoc/6176978/T6176978.java - test/langtools/tools/javadoc/6176978/X.java - test/langtools/tools/javadoc/6227454/Test.java - test/langtools/tools/javadoc/6942366/T6942366.java - test/langtools/tools/javadoc/6942366/Test.java - test/langtools/tools/javadoc/6942366/p/Base.java - test/langtools/tools/javadoc/6958836/Test.java - test/langtools/tools/javadoc/6964914/Error.java - test/langtools/tools/javadoc/6964914/JavacWarning.java - test/langtools/tools/javadoc/6964914/JavadocWarning.java - test/langtools/tools/javadoc/6964914/Test.java - test/langtools/tools/javadoc/6964914/TestStdDoclet.java - test/langtools/tools/javadoc/6964914/TestUserDoclet.java - test/langtools/tools/javadoc/8025693/Test.java - test/langtools/tools/javadoc/8147801/T8147801.java - test/langtools/tools/javadoc/8147801/jarsrc/lib/Lib1.java - test/langtools/tools/javadoc/8147801/jarsrc/lib/Lib2.java - test/langtools/tools/javadoc/8147801/p/Test.java - test/langtools/tools/javadoc/AddOpensTest.java - test/langtools/tools/javadoc/BadOptionsTest.java - test/langtools/tools/javadoc/BooleanConst.java - test/langtools/tools/javadoc/BreakIteratorWarning.java - test/langtools/tools/javadoc/CheckResourceKeys.java - test/langtools/tools/javadoc/CompletionError.java - test/langtools/tools/javadoc/EncodingTest.java - test/langtools/tools/javadoc/FlagsTooEarly.java - test/langtools/tools/javadoc/InlineTagsWithBraces.java - test/langtools/tools/javadoc/LangVers.java - test/langtools/tools/javadoc/MaxWarns.java - test/langtools/tools/javadoc/MethodLinks.java - test/langtools/tools/javadoc/NoStar.java - test/langtools/tools/javadoc/ReleaseOption.java - test/langtools/tools/javadoc/ReleaseOptionSource.java - test/langtools/tools/javadoc/T4994049/FileWithTabs.java - test/langtools/tools/javadoc/T4994049/T4994049.java - test/langtools/tools/javadoc/T6968833.java - test/langtools/tools/javadoc/XWerror.java - test/langtools/tools/javadoc/annotations/annotateMethodsFields/Main.java - test/langtools/tools/javadoc/annotations/annotateMethodsFields/expected.out - test/langtools/tools/javadoc/annotations/annotateMethodsFields/pkg1/A.java - test/langtools/tools/javadoc/annotations/annotateMethodsFields/pkg1/B.java - test/langtools/tools/javadoc/annotations/annotateMethodsFields/pkg1/E.java - test/langtools/tools/javadoc/annotations/annotatePackage/Main.java - test/langtools/tools/javadoc/annotations/annotatePackage/expected.out - test/langtools/tools/javadoc/annotations/annotatePackage/pkg1/A.java - test/langtools/tools/javadoc/annotations/annotatePackage/pkg1/package-info.java - test/langtools/tools/javadoc/annotations/annotatePackage/pkg1/package.html - test/langtools/tools/javadoc/annotations/annotatePackage/pkg2/B.java - test/langtools/tools/javadoc/annotations/annotatePackage/pkg2/package.html - test/langtools/tools/javadoc/annotations/annotateParams/Main.java - test/langtools/tools/javadoc/annotations/annotateParams/expected.out - test/langtools/tools/javadoc/annotations/annotateParams/pkg1/A.java - test/langtools/tools/javadoc/annotations/annotateParams/pkg1/C.java - test/langtools/tools/javadoc/annotations/badVals/Main.java - test/langtools/tools/javadoc/annotations/badVals/pkg1/A.java - test/langtools/tools/javadoc/annotations/defaults/Main.java - test/langtools/tools/javadoc/annotations/defaults/expected.out - test/langtools/tools/javadoc/annotations/defaults/pkg1/A.java - test/langtools/tools/javadoc/annotations/defaults/pkg1/B.java - test/langtools/tools/javadoc/annotations/elementTypes/Main.java - test/langtools/tools/javadoc/annotations/elementTypes/expected.out - test/langtools/tools/javadoc/annotations/elementTypes/pkg1/A.java - test/langtools/tools/javadoc/annotations/elementTypes/pkg1/B.java - test/langtools/tools/javadoc/annotations/missing/Main.java - test/langtools/tools/javadoc/annotations/missing/somepackage/MissingAnnotationClass.java - test/langtools/tools/javadoc/annotations/shortcuts/Main.java - test/langtools/tools/javadoc/annotations/shortcuts/expected.out - test/langtools/tools/javadoc/annotations/shortcuts/pkg1/A.java - test/langtools/tools/javadoc/annotations/shortcuts/pkg1/Array.java - test/langtools/tools/javadoc/annotations/shortcuts/pkg1/Marker.java - test/langtools/tools/javadoc/annotations/shortcuts/pkg1/Value.java - test/langtools/tools/javadoc/api/basic/APITest.java - test/langtools/tools/javadoc/api/basic/DocletPathTest.java - test/langtools/tools/javadoc/api/basic/DocumentationToolLocationTest.java - test/langtools/tools/javadoc/api/basic/GetSourceVersionsTest.java - test/langtools/tools/javadoc/api/basic/GetTask_DiagListenerTest.java - test/langtools/tools/javadoc/api/basic/GetTask_DocletClassTest.java - test/langtools/tools/javadoc/api/basic/GetTask_FileManagerTest.java - test/langtools/tools/javadoc/api/basic/GetTask_FileObjectsTest.java - test/langtools/tools/javadoc/api/basic/GetTask_OptionsTest.java - test/langtools/tools/javadoc/api/basic/GetTask_WriterTest.java - test/langtools/tools/javadoc/api/basic/Task_reuseTest.java - test/langtools/tools/javadoc/api/basic/pkg/C.java - test/langtools/tools/javadoc/api/basic/taglets/UnderlineTaglet.java - test/langtools/tools/javadoc/completionFailure/CompletionFailure.java - test/langtools/tools/javadoc/completionFailure/pkg/A.java - test/langtools/tools/javadoc/completionFailure/pkg/B.java - test/langtools/tools/javadoc/dupOk/DupOk.java - test/langtools/tools/javadoc/dupOk/sp1/p/A.java - test/langtools/tools/javadoc/dupOk/sp2/p/A.java - test/langtools/tools/javadoc/dupOk/sp2/p/B.java - test/langtools/tools/javadoc/enum/docComments/Main.java - test/langtools/tools/javadoc/enum/docComments/pkg1/Operation.java - test/langtools/tools/javadoc/enum/enumType/Main.java - test/langtools/tools/javadoc/enum/enumType/expected.out - test/langtools/tools/javadoc/enum/enumType/pkg1/QuotablePerson.java - test/langtools/tools/javadoc/generics/genericClass/Main.java - test/langtools/tools/javadoc/generics/genericClass/expected.out - test/langtools/tools/javadoc/generics/genericClass/pkg1/A.java - test/langtools/tools/javadoc/generics/genericInnerAndOuter/Main.java - test/langtools/tools/javadoc/generics/genericInnerAndOuter/expected.out - test/langtools/tools/javadoc/generics/genericInnerAndOuter/pkg1/O.java - test/langtools/tools/javadoc/generics/genericInnerAndOuter/pkg1/X.java - test/langtools/tools/javadoc/generics/genericInterface/Main.java - test/langtools/tools/javadoc/generics/genericInterface/expected.out - test/langtools/tools/javadoc/generics/genericInterface/pkg1/A.java - test/langtools/tools/javadoc/generics/genericMethod/Main.java - test/langtools/tools/javadoc/generics/genericMethod/expected.out - test/langtools/tools/javadoc/generics/genericMethod/pkg1/A.java - test/langtools/tools/javadoc/generics/genericSuper/Main.java - test/langtools/tools/javadoc/generics/genericSuper/expected.out - test/langtools/tools/javadoc/generics/genericSuper/pkg1/A.java - test/langtools/tools/javadoc/generics/supertypes/Main.java - test/langtools/tools/javadoc/generics/supertypes/expected.out - test/langtools/tools/javadoc/generics/supertypes/pkg1/A.java - test/langtools/tools/javadoc/generics/supertypes/pkg1/B.java - test/langtools/tools/javadoc/generics/throwsGeneric/Main.java - test/langtools/tools/javadoc/generics/throwsGeneric/expected.out - test/langtools/tools/javadoc/generics/throwsGeneric/pkg1/A.java - test/langtools/tools/javadoc/generics/tparamCycle/Main.java - test/langtools/tools/javadoc/generics/tparamCycle/pkg1/LikeEnum.java - test/langtools/tools/javadoc/generics/tparamTagOnMethod/Main.java - test/langtools/tools/javadoc/generics/tparamTagOnMethod/expected.out - test/langtools/tools/javadoc/generics/tparamTagOnMethod/pkg1/A.java - test/langtools/tools/javadoc/generics/tparamTagOnType/Main.java - test/langtools/tools/javadoc/generics/tparamTagOnType/expected.out - test/langtools/tools/javadoc/generics/tparamTagOnType/pkg1/A.java - test/langtools/tools/javadoc/generics/wildcards/Main.java - test/langtools/tools/javadoc/generics/wildcards/expected.out - test/langtools/tools/javadoc/generics/wildcards/pkg1/A.java - test/langtools/tools/javadoc/imports/I.java - test/langtools/tools/javadoc/imports/MissingImport.java - test/langtools/tools/javadoc/lib/OldToolTester.java - test/langtools/tools/javadoc/lib/ToyDoclet.java - test/langtools/tools/javadoc/nestedClass/NestedClass.java - test/langtools/tools/javadoc/nestedClass/NestedClassB.java - test/langtools/tools/javadoc/nonConstExprs/Test.java - test/langtools/tools/javadoc/outputRedirect/Test.java - test/langtools/tools/javadoc/outputRedirect/p/OutputRedirect.java - test/langtools/tools/javadoc/parser/7091528/T7091528.java - test/langtools/tools/javadoc/parser/7091528/p/C1.java - test/langtools/tools/javadoc/parser/7091528/p/C3.java - test/langtools/tools/javadoc/parser/7091528/p/q/C2.java - test/langtools/tools/javadoc/sourceOnly/Test.java - test/langtools/tools/javadoc/sourceOnly/p/NonSource.jasm - test/langtools/tools/javadoc/sourceOnly/p/SourceOnly.java - test/langtools/tools/javadoc/sourceOption/SourceOption.java - test/langtools/tools/javadoc/sourceOption/p/LambdaConstructTest.java - test/langtools/tools/javadoc/subpackageIgnore/SubpackageIgnore.java - test/langtools/tools/javadoc/subpackageIgnore/pkg1/not-subpkg/SomeJavaFile.java - test/langtools/tools/javadoc/varArgs/Main.java - test/langtools/tools/javadoc/varArgs/expected.out - test/langtools/tools/javadoc/varArgs/pkg1/A.java - test/nashorn/Makefile Changeset: 132973ef7a31 Author: bpb Date: 2019-01-22 09:45 -0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/132973ef7a31 8211936: Better String parsing Reviewed-by: bpb, darcy Contributed-by: Brian Burkhalter , Joe Darcy , Paul Hohensee ! src/java.base/share/classes/java/math/BigDecimal.java + test/jdk/java/math/BigDecimal/IntValueExactTests.java + test/jdk/java/math/BigDecimal/IntegralValueTests.java ! test/jdk/java/math/BigDecimal/LongValueExactTests.java Changeset: 30503c380394 Author: rriggs Date: 2019-02-06 11:39 -0500 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/30503c380394 8218453: More dynamic RMI interactions Reviewed-by: ahgross, skoivu, smarks ! src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl_Skel.java ! src/java.rmi/share/classes/sun/rmi/server/UnicastServerRef.java + test/jdk/java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java Changeset: 4ff026ff9c98 Author: henryjen Date: 2019-04-15 18:24 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/4ff026ff9c98 Merge ! src/hotspot/share/classfile/classFileParser.cpp Changeset: 15f2aae40bc8 Author: henryjen Date: 2019-04-16 20:47 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/15f2aae40bc8 Merge - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractPackageIndexWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/external/jquery/jquery.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_55_fbf9ee_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_65_dadada_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_75_dadada_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_75_e6e6e6_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_95_fef1ec_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_highlight-soft_75_cccccc_1x100.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_222222_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_2e83ff_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_454545_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_888888_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_cd0a0a_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-3.3.1.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-migrate-3.0.1.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.min.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.structure.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.structure.min.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip/dist/jszip.min.js - test/hotspot/jtreg/runtime/ErrorHandling/ExplicitArithmeticCheck.java - test/hotspot/jtreg/runtime/Thread/MonitorCacheMaybeExpand_DeadLock.java - test/hotspot/jtreg/runtime/interpreter/WideStrictInline.java Changeset: 86533c4a2f68 Author: thartmann Date: 2019-04-17 08:12 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/86533c4a2f68 8222417: compiler/loopopts/TestOverunrolling.java times out Summary: Problem list the test with Graal because it uses -Xcomp in combination with -XX:-TieredCompilation. Reviewed-by: kvn, iignatyev ! test/hotspot/jtreg/ProblemList-graal.txt Changeset: 8b2f797e3edb Author: thartmann Date: 2019-04-17 08:15 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/8b2f797e3edb 8222418: compiler/arguments/TestScavengeRootsInCode.java times out Summary: Problem list the test with Graal because it uses -Xcomp in combination with -XX:-TieredCompilation. Reviewed-by: kvn, iignatyev ! test/hotspot/jtreg/ProblemList-graal.txt Changeset: 6c4d8b7128d5 Author: pmuthuswamy Date: 2019-04-17 12:43 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/6c4d8b7128d5 8220382: Cleanup doclet instantiation Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java Changeset: 1af5c0e68381 Author: rehn Date: 2019-04-17 09:25 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/1af5c0e68381 8218147: make_walkable asserts on multiple calls Reviewed-by: dholmes, dcubed ! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: ba8ab3f67aec Author: rehn Date: 2019-04-17 09:29 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/ba8ab3f67aec 8222327: java_lang_Thread _thread_status_offset, remove pre 1.5 code paths Reviewed-by: dholmes, redestad ! src/hotspot/share/classfile/javaClasses.cpp Changeset: b36e68b34be3 Author: neliasso Date: 2019-04-17 09:54 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b36e68b34be3 8218468: Load barrier slow path node should be MachTypeNode Reviewed-by: shade, pliden, kvn ! src/hotspot/share/adlc/formssel.cpp Changeset: 3b2101f56cdd Author: clanger Date: 2019-04-17 10:31 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/3b2101f56cdd 8222627: Remove sneaky token 'Name' in jdk-version.m4 Reviewed-by: simonis ! make/autoconf/jdk-version.m4 Changeset: 4224f26b2e7f Author: rschmelter Date: 2019-04-15 06:41 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/4224f26b2e7f 8222491: jcmd can fail converting UTF8 output to strings Reviewed-by: jcbeyler, clanger, dholmes ! src/jdk.jcmd/share/classes/sun/tools/jcmd/JCmd.java Changeset: 224515275cf9 Author: eosterlund Date: 2019-04-17 12:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/224515275cf9 8219718: ZGC: Make nmethod entry barriers and nmethod::is_unloading use ZNMethodDataOops Reviewed-by: pliden, stefank ! src/hotspot/share/gc/z/zBarrierSetNMethod.cpp ! src/hotspot/share/gc/z/zUnload.cpp Changeset: b2ed96c35687 Author: mcimadamore Date: 2019-04-17 15:37 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b2ed96c35687 8222289: Overhaul logic for reading/writing constant pool entries Summary: Rewrite of Pool,ClassReader,ClassWriter to use shared pool helper components Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Code.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Items.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ModuleNameReader.java - src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java + src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolConstant.java + src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolReader.java + src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolWriter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/ByteBuffer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/AnnotatedExtendsTest.java ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/BridgeShouldHaveNoInteriorAnnotationsTest.java ! test/langtools/tools/javac/annotations/typeAnnotations/classfile/NestedLambdasCastedTest.java ! test/langtools/tools/javac/diags/examples.not-yet.txt ! test/langtools/tools/javac/lambda/TestBootstrapMethodsCount.java ! test/langtools/tools/javac/lambda/TestInvokeDynamic.java ! test/langtools/tools/javac/modules/T8159439/NPEForModuleInfoWithNonZeroSuperClassTest.out ! test/langtools/tools/javac/nestmates/CheckNestmateAttrs.java ! test/langtools/tools/javap/AnnoTest.java ! test/langtools/tools/javap/typeAnnotations/AnnotationDefaultNewlineTest.java ! test/langtools/tools/javap/typeAnnotations/InvisibleParameterAnnotationsTest.java Changeset: 7689e1cc56fe Author: bpb Date: 2019-04-17 08:12 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/7689e1cc56fe 8220477: Channels.newWriter() does not close if underlying channel throws an IOException Reviewed-by: alanb ! src/java.base/share/classes/sun/nio/cs/StreamDecoder.java ! src/java.base/share/classes/sun/nio/cs/StreamEncoder.java ! test/jdk/java/nio/channels/Channels/Basic.java Changeset: 93b702d2a0cb Author: erikj Date: 2019-04-17 13:18 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/93b702d2a0cb 8222444: Add a suggestion for non-US locale in the test doc Reviewed-by: erikj Contributed-by: jingtian at loongson.cn ! doc/testing.html ! doc/testing.md Changeset: 5de35f58f70c Author: jwilhelm Date: 2019-04-18 02:45 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/5de35f58f70c Added tag jdk-13+17 for changeset 93b702d2a0cb ! .hgtags Changeset: 2bf8c47fc95f Author: shade Date: 2019-04-24 10:36 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/2bf8c47fc95f Merge ! .hgtags ! src/hotspot/cpu/s390/macroAssembler_s390.hpp ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp - src/jdk.accessibility/windows/native/common/AccessBridgeStatusWindow.RC - src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractPackageIndexWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/external/jquery/jquery.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_55_fbf9ee_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_65_dadada_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_75_dadada_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_75_e6e6e6_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_95_fef1ec_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_highlight-soft_75_cccccc_1x100.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_222222_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_2e83ff_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_454545_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_888888_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_cd0a0a_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-3.3.1.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-migrate-3.0.1.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.min.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.structure.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.structure.min.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip/dist/jszip.min.js ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/runtime/ErrorHandling/ExplicitArithmeticCheck.java ! test/hotspot/jtreg/runtime/MemberName/MemberNameLeak.java - test/hotspot/jtreg/runtime/Thread/MonitorCacheMaybeExpand_DeadLock.java - test/hotspot/jtreg/runtime/containers/cgroup/PlainRead.java - test/hotspot/jtreg/runtime/containers/docker/AttemptOOM.java - test/hotspot/jtreg/runtime/containers/docker/CheckContainerized.java - test/hotspot/jtreg/runtime/containers/docker/DockerBasicTest.java - test/hotspot/jtreg/runtime/containers/docker/HelloDocker.java - test/hotspot/jtreg/runtime/containers/docker/JfrReporter.java - test/hotspot/jtreg/runtime/containers/docker/PrintContainerInfo.java - test/hotspot/jtreg/runtime/containers/docker/TEST.properties - test/hotspot/jtreg/runtime/containers/docker/TestCPUAwareness.java - test/hotspot/jtreg/runtime/containers/docker/TestCPUSets.java - test/hotspot/jtreg/runtime/containers/docker/TestJFREvents.java - test/hotspot/jtreg/runtime/containers/docker/TestMemoryAwareness.java - test/hotspot/jtreg/runtime/containers/docker/TestMisc.java - test/hotspot/jtreg/runtime/interpreter/WideStrictInline.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SingleStep/singlestep001/singlestep001.cpp - test/jdk/sun/security/tools/jarsigner/AlgOptions.sh - test/jdk/sun/security/tools/jarsigner/PercentSign.sh - test/jdk/sun/security/tools/jarsigner/certpolicy.sh - test/jdk/sun/security/tools/jarsigner/checkusage.sh - test/jdk/sun/security/tools/jarsigner/collator.sh - test/jdk/sun/security/tools/jarsigner/concise_jarsigner.sh - test/jdk/sun/security/tools/jarsigner/crl.sh - test/jdk/sun/security/tools/jarsigner/default_options.sh - test/jdk/sun/security/tools/jarsigner/diffend.sh - test/jdk/sun/security/tools/jarsigner/ec.sh - test/jdk/sun/security/tools/jarsigner/emptymanifest.sh - test/jdk/sun/security/tools/jarsigner/jvindex.sh - test/jdk/sun/security/tools/jarsigner/nameclash.sh - test/jdk/sun/security/tools/jarsigner/newsize7.sh - test/jdk/sun/security/tools/jarsigner/oldsig.sh - test/jdk/sun/security/tools/jarsigner/onlymanifest.sh - test/jdk/sun/security/tools/jarsigner/passtype.sh - test/jdk/sun/security/tools/jarsigner/samename.sh - test/jdk/sun/security/tools/jarsigner/weaksize.sh - test/jdk/sun/security/tools/keytool/CloneKeyAskPassword.sh - test/jdk/sun/security/tools/keytool/NoExtNPE.sh - test/jdk/sun/security/tools/keytool/SecretKeyKS.sh - test/jdk/sun/security/tools/keytool/StandardAlgName.sh - test/jdk/sun/security/tools/keytool/StorePasswordsByShell.sh - test/jdk/sun/security/tools/keytool/default_options.sh - test/jdk/sun/security/tools/keytool/emptysubject.sh - test/jdk/sun/security/tools/keytool/file-in-help.sh - test/jdk/sun/security/tools/keytool/i18n.sh - test/jdk/sun/security/tools/keytool/importreadall.sh - test/jdk/sun/security/tools/keytool/keyalg.sh - test/jdk/sun/security/tools/keytool/newhelp.sh - test/jdk/sun/security/tools/keytool/resource.sh - test/jdk/sun/security/tools/keytool/selfissued.sh - test/jdk/sun/security/tools/keytool/trystore.sh ! test/lib/sun/hotspot/gc/GC.java From shade at redhat.com Wed Apr 24 13:19:03 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Apr 2019 15:19:03 +0200 Subject: RFR [11u]: Bulk backports to sh/jdk11 Message-ID: Let's pick up a few easy backports to sh/jdk11: [backport] 8222125: Shenandoah: Crash when running with ShenandoahParallelSafepointThreads=1 [backport] 8222130: Shenandoah should verify roots after pre-evacuation [backport] 8222185: Shenandoah should report "committed" as capacity [backport] 8222186: Shenandoah should not uncommit below minimum heap size [backport] 8221735: Shenandoah fails ctw/modules/jdk_management_agent.java with Traversal [backport] 8215356: Disable x86_32 Shenandoah build to avoid hotspot/tier1 failures Webrev: http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20190424/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Wed Apr 24 13:49:16 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 24 Apr 2019 15:49:16 +0200 Subject: RFR [11u]: Bulk backports to sh/jdk11 In-Reply-To: References: Message-ID: <2b1d59ad-e240-33e0-ea93-56c4698e49ba@redhat.com> Yeah looks good! Thanks! Roman > Let's pick up a few easy backports to sh/jdk11: > [backport] 8222125: Shenandoah: Crash when running with ShenandoahParallelSafepointThreads=1 > [backport] 8222130: Shenandoah should verify roots after pre-evacuation > [backport] 8222185: Shenandoah should report "committed" as capacity > [backport] 8222186: Shenandoah should not uncommit below minimum heap size > [backport] 8221735: Shenandoah fails ctw/modules/jdk_management_agent.java with Traversal > [backport] 8215356: Disable x86_32 Shenandoah build to avoid hotspot/tier1 failures > > Webrev: > http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20190424/webrev.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Wed Apr 24 13:51:18 2019 From: shade at redhat.com (shade at redhat.com) Date: Wed, 24 Apr 2019 13:51:18 +0000 Subject: hg: shenandoah/jdk11: 6 new changesets Message-ID: <201904241351.x3ODpJpT005230@aojmv0008.oracle.com> Changeset: 2891913d3094 Author: rkennke Date: 2019-04-08 18:42 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/2891913d3094 [backport] 8222125: Shenandoah: Crash when running with ShenandoahParallelSafepointThreads=1 Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp + test/hotspot/jtreg/gc/shenandoah/options/TestSafepointWorkers.java Changeset: bed2feae2ec0 Author: shade Date: 2019-04-08 19:43 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/bed2feae2ec0 [backport] 8222130: Shenandoah should verify roots after pre-evacuation Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.hpp Changeset: 50a1bc50bfd6 Author: shade Date: 2019-04-09 21:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/50a1bc50bfd6 [backport] 8222185: Shenandoah should report "committed" as capacity Reviewed-by: zgu, rkennke ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMonitoringSupport.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp Changeset: e266d7fef085 Author: shade Date: 2019-04-09 21:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/e266d7fef085 [backport] 8222186: Shenandoah should not uncommit below minimum heap size Reviewed-by: zgu, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestMemoryMXBeans.java Changeset: 4c5c27f5d18c Author: shade Date: 2019-04-01 13:33 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/4c5c27f5d18c [backport] 8221735: Shenandoah fails ctw/modules/jdk_management_agent.java with Traversal Reviewed-by: rkennke, roland ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Changeset: bdcf0ddb1452 Author: shade Date: 2018-12-13 16:45 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/bdcf0ddb1452 [backport] 8215356: Disable x86_32 Shenandoah build to avoid hotspot/tier1 failures Reviewed-by: rkennke From shade at redhat.com Fri Apr 26 10:54:34 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 26 Apr 2019 12:54:34 +0200 Subject: RFR [11u]: Bulk backports to sh/jdk11 Message-ID: <5f78fcee-7bd0-944d-8589-a8dfbaa084a0@redhat.com> Pick up another batch of simple sh/jdk11 backports: [backport] 8220664: Simplify ShenandoahUpdateHeapRefsClosure [backport] 8222403: Shenandoah: Remove ShenandoahAlwaysTrueClosure, use AlwaysTrueClosure instead [backport] 8222425: Shenandoah: Move commonly used closures to separate files [backport] 8222843: Print Shenandoah cset map addresses in hs_err [backport] 8222838: Shenandoah: SEGV on accessing cset bitmap for NULL ptr Webrev: http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20190426/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From shade at redhat.com Fri Apr 26 11:54:11 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 26 Apr 2019 13:54:11 +0200 Subject: RFC: Pick up jdk-13+18 to sh/jdk Message-ID: <9e23008b-bc6c-8aff-d604-f34a4326b6c8@redhat.com> We have not synced up sh/jdk for a while now. Let's pick up to the latest upstream tag, jdk-13+18. Merge is trivial. This should fix jcstress tests in sh/jdk (missing cases in get_barrier_strength). Changesets: http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk-13%2b18/changesets.txt Testing: hotspot_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From rkennke at redhat.com Fri Apr 26 12:03:24 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 26 Apr 2019 14:03:24 +0200 Subject: RFR [11u]: Bulk backports to sh/jdk11 In-Reply-To: <5f78fcee-7bd0-944d-8589-a8dfbaa084a0@redhat.com> References: <5f78fcee-7bd0-944d-8589-a8dfbaa084a0@redhat.com> Message-ID: <84e56f46-94d8-b6d3-0515-0677923c8599@redhat.com> Looks good to me. Thanks! Roman > Pick up another batch of simple sh/jdk11 backports: > [backport] 8220664: Simplify ShenandoahUpdateHeapRefsClosure > [backport] 8222403: Shenandoah: Remove ShenandoahAlwaysTrueClosure, use AlwaysTrueClosure instead > [backport] 8222425: Shenandoah: Move commonly used closures to separate files > [backport] 8222843: Print Shenandoah cset map addresses in hs_err > [backport] 8222838: Shenandoah: SEGV on accessing cset bitmap for NULL ptr > > Webrev: > http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20190426/webrev.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From rkennke at redhat.com Fri Apr 26 12:03:45 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 26 Apr 2019 14:03:45 +0200 Subject: RFC: Pick up jdk-13+18 to sh/jdk In-Reply-To: <9e23008b-bc6c-8aff-d604-f34a4326b6c8@redhat.com> References: <9e23008b-bc6c-8aff-d604-f34a4326b6c8@redhat.com> Message-ID: <6baca739-8694-cc94-5f65-9ebe2cd2ed97@redhat.com> Ok let's do it.! Roman > We have not synced up sh/jdk for a while now. Let's pick up to the latest upstream tag, jdk-13+18. > Merge is trivial. This should fix jcstress tests in sh/jdk (missing cases in get_barrier_strength). > > Changesets: > http://cr.openjdk.java.net/~shade/shenandoah/merges/jdk-13%2b18/changesets.txt > > Testing: hotspot_gc_shenandoah {fastdebug, release} > From shade at redhat.com Fri Apr 26 12:07:21 2019 From: shade at redhat.com (shade at redhat.com) Date: Fri, 26 Apr 2019 12:07:21 +0000 Subject: hg: shenandoah/jdk: 41 new changesets Message-ID: <201904261207.x3QC7OqQ024052@aojmv0008.oracle.com> Changeset: 75a42622414e Author: mbaesken Date: 2019-04-12 09:13 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/75a42622414e 8222280: Provide virtualization related info in the hs_error file on AIX Reviewed-by: clanger, mdoerr ! make/autoconf/libraries.m4 ! src/hotspot/cpu/ppc/vm_version_ppc.cpp ! src/hotspot/os/aix/os_aix.cpp Changeset: b73893f7fee3 Author: coleenp Date: 2019-04-18 07:02 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b73893f7fee3 8222379: JFR TestClassLoadEvent.java failed due to EXCEPTION_ACCESS_VIOLATION Summary: Give fatal error if CDS loses archive mapping. Reviewed-by: iklam, ccheung, jiangli ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/utilities/macros.hpp Changeset: 7b74bbe5085b Author: stefank Date: 2019-04-17 07:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/7b74bbe5085b 8222558: Rework ResolvedMethodTable verification Reviewed-by: coleenp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/memory/universe.hpp ! src/hotspot/share/prims/resolvedMethodTable.cpp ! src/hotspot/share/prims/resolvedMethodTable.hpp ! test/hotspot/jtreg/runtime/MemberName/MemberNameLeak.java Changeset: 84054d68bf85 Author: stefank Date: 2019-04-18 09:27 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/84054d68bf85 8222713: Add OutputAnalyzer(Path) constructor Reviewed-by: dholmes, coleenp ! test/lib/jdk/test/lib/process/OutputAnalyzer.java Changeset: aa626cbadf1b Author: stefank Date: 2019-04-17 07:41 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/aa626cbadf1b 8222550: runtime/MemberName/MemberNameLeak.java times out Reviewed-by: coleenp, dholmes ! test/hotspot/jtreg/runtime/MemberName/MemberNameLeak.java Changeset: 1c242c2d037f Author: sgehwolf Date: 2019-03-12 10:43 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/1c242c2d037f 8217338: [Containers] Improve systemd slice memory limit support Summary: Use hierachical memory limit in addition to memory_limits_in_bytes Reviewed-by: bobv, dholmes ! src/hotspot/os/linux/osContainer_linux.cpp ! src/hotspot/os/linux/osContainer_linux.hpp ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java Changeset: 895a6a380484 Author: mbalao Date: 2019-04-15 15:52 -0300 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/895a6a380484 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider Summary: Do not close the session holding the Wrapper Key while in use. Delete the Wrapper Key when no longer needed. Reviewed-by: valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java ! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_keymgmt.c Changeset: 270557b396eb Author: dfuchs Date: 2019-04-18 17:56 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/270557b396eb 8222527: HttpClient doesn't send HOST header when tunelling HTTP/1.1 through http proxy Summary: HttpClient no longer filters out system host header when sending tunelling CONNECT request to proxy Reviewed-by: michaelm ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! test/jdk/java/net/httpclient/DigestEchoServer.java ! test/jdk/java/net/httpclient/HttpsTunnelTest.java ! test/jdk/java/net/httpclient/ProxyAuthDisabledSchemesSSL.java Changeset: 79e95d8dd85d Author: naoto Date: 2019-04-18 17:36 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/79e95d8dd85d 8222668: Add @since tag to JapaneseEra.REIWA Reviewed-by: chegar, lancea ! src/java.base/share/classes/java/time/chrono/JapaneseEra.java Changeset: 5c456dd47ff1 Author: erikj Date: 2019-04-19 06:29 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/5c456dd47ff1 8222735: Update doc/building.md with current Oracle build platforms and compilers Reviewed-by: tbell ! doc/building.html ! doc/building.md Changeset: 783ddd361177 Author: qpzhang Date: 2019-04-19 14:42 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/783ddd361177 8222753: AAarch64: Add CPU implementer code for Ampere Summary: Add CPU implementer code 0xC0 for Ampere Reviewed-by: aph, drwhite, fyang ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp Changeset: 9fe44a3335b2 Author: epavlova Date: 2019-04-19 11:18 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/9fe44a3335b2 8222747: [Graal] mx_subprocess files miss testing VM flags Reviewed-by: kvn ! test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java Changeset: 2de1c3fa3e7d Author: mbalao Date: 2019-04-19 10:59 -0300 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/2de1c3fa3e7d 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed Reviewed-by: xuelei ! src/java.base/share/classes/com/sun/crypto/provider/RSACipher.java ! test/jdk/ProblemList.txt ! test/jdk/sun/security/pkcs11/tls/tls12/TestTLS12.java Changeset: 3452d108d06d Author: coleenp Date: 2019-04-19 21:49 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/3452d108d06d 8192936: RI does not follow the JVMTI RedefineClasses spec that is too strict in the definition Summary: Introduce new flag fo compatibility: -XX:AllowRedefinitionToAddOrDeleteMethods Reviewed-by: jcbeyler, sspitsyn ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAddLambdaExpression.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineDeleteJmethod.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineSubtractLambdaExpression.java + test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java ! test/jdk/com/sun/jdi/RedefineAddPrivateMethod.java ! test/jdk/com/sun/jdi/lib/jdb/Debuggee.java ! test/jdk/com/sun/jdi/lib/jdb/JdbTest.java ! test/jdk/java/lang/instrument/RedefineAddDeleteMethod/DeleteMethodHandle/MethodHandleDeletedMethod.java ! test/jdk/java/lang/instrument/RedefineMethodAddInvoke.sh ! test/jdk/java/lang/instrument/RedefineMethodDelInvoke.sh ! test/jdk/java/lang/instrument/RedefineMethodInBacktrace.sh Changeset: 0ab35668b4f4 Author: shade Date: 2019-04-22 11:16 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/0ab35668b4f4 8222786: Shenandoah get_barrier_strength should accept all shapes of (Weak)CAS reference barriers Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Changeset: b4d37cf7b90e Author: gadams Date: 2019-04-22 07:13 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b4d37cf7b90e 8222741: jdi/EventQueue/remove/remove004 fails due to VMDisconnectedException Reviewed-by: cjplummer, jcbeyler ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove004.java Changeset: f203906d0dde Author: jjiang Date: 2019-04-23 10:08 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f203906d0dde 8222391: javax/net/ssl/compatibility/Compatibility.java should be more flexible Reviewed-by: xuelei ! test/jdk/javax/net/ssl/compatibility/Client.java ! test/jdk/javax/net/ssl/compatibility/Compatibility.java ! test/jdk/javax/net/ssl/compatibility/JdkInfo.java ! test/jdk/javax/net/ssl/compatibility/Server.java ! test/jdk/javax/net/ssl/compatibility/UseCase.java ! test/jdk/javax/net/ssl/compatibility/Utils.java Changeset: 3babb3ed24c6 Author: pmuthuswamy Date: 2019-04-23 14:13 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/3babb3ed24c6 8215580: Remove support for `--no-module-directories` Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! 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/Head.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/BaseConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java ! test/langtools/jdk/javadoc/doclet/testModuleDirs/TestModuleDirs.java ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java Changeset: 98473958d49a Author: dbatrak Date: 2019-04-11 10:49 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/98473958d49a 8220231: Cache HarfBuzz face object for same font's text layout calls Reviewed-by: prr, avu, serb ! src/java.desktop/macosx/classes/sun/font/CFont.java ! src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.h ! src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.m ! src/java.desktop/share/classes/sun/font/Font2D.java ! src/java.desktop/share/classes/sun/font/FontScaler.java ! src/java.desktop/share/classes/sun/font/FreetypeFontScaler.java ! src/java.desktop/share/classes/sun/font/NullFontScaler.java ! src/java.desktop/share/classes/sun/font/SunLayoutEngine.java ! src/java.desktop/share/classes/sun/font/TrueTypeFont.java ! src/java.desktop/share/native/common/font/fontscalerdefs.h ! src/java.desktop/share/native/libfontmanager/HBShaper.c ! src/java.desktop/share/native/libfontmanager/freetypeScaler.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 + test/jdk/java/awt/font/TextLayout/FontLayoutStressTest.java Changeset: dc6c5c53669b Author: psadhukhan Date: 2019-04-16 10:09 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/dc6c5c53669b 8222332: PIT: Problemlist tests that times out consistently Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 4b4c8c11358f Author: psadhukhan Date: 2019-04-22 10:53 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/4b4c8c11358f Merge - src/jdk.accessibility/windows/native/common/AccessBridgeStatusWindow.RC - src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Pool.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractModuleIndexWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractPackageIndexWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/external/jquery/jquery.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_55_fbf9ee_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_65_dadada_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_75_dadada_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_75_e6e6e6_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_glass_95_fef1ec_1x400.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-bg_highlight-soft_75_cccccc_1x100.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_222222_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_2e83ff_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_454545_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_888888_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/images/ui-icons_cd0a0a_256x240.png - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-3.3.1.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-migrate-3.0.1.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.min.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.structure.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jquery-ui.structure.min.css - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils-ie.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils-ie.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip-utils/dist/jszip-utils.min.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip/dist/jszip.js - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/jquery/jszip/dist/jszip.min.js - test/hotspot/jtreg/runtime/ErrorHandling/ExplicitArithmeticCheck.java - test/hotspot/jtreg/runtime/Thread/MonitorCacheMaybeExpand_DeadLock.java - test/hotspot/jtreg/runtime/containers/cgroup/PlainRead.java - test/hotspot/jtreg/runtime/containers/docker/AttemptOOM.java - test/hotspot/jtreg/runtime/containers/docker/CheckContainerized.java - test/hotspot/jtreg/runtime/containers/docker/DockerBasicTest.java - test/hotspot/jtreg/runtime/containers/docker/HelloDocker.java - test/hotspot/jtreg/runtime/containers/docker/JfrReporter.java - test/hotspot/jtreg/runtime/containers/docker/PrintContainerInfo.java - test/hotspot/jtreg/runtime/containers/docker/TEST.properties - test/hotspot/jtreg/runtime/containers/docker/TestCPUAwareness.java - test/hotspot/jtreg/runtime/containers/docker/TestCPUSets.java - test/hotspot/jtreg/runtime/containers/docker/TestJFREvents.java - test/hotspot/jtreg/runtime/containers/docker/TestMemoryAwareness.java - test/hotspot/jtreg/runtime/containers/docker/TestMisc.java - test/hotspot/jtreg/runtime/interpreter/WideStrictInline.java ! test/jdk/ProblemList.txt - test/jdk/sun/security/tools/jarsigner/AlgOptions.sh - test/jdk/sun/security/tools/jarsigner/PercentSign.sh - test/jdk/sun/security/tools/jarsigner/certpolicy.sh - test/jdk/sun/security/tools/jarsigner/checkusage.sh - test/jdk/sun/security/tools/jarsigner/collator.sh - test/jdk/sun/security/tools/jarsigner/concise_jarsigner.sh - test/jdk/sun/security/tools/jarsigner/crl.sh - test/jdk/sun/security/tools/jarsigner/default_options.sh - test/jdk/sun/security/tools/jarsigner/diffend.sh - test/jdk/sun/security/tools/jarsigner/ec.sh - test/jdk/sun/security/tools/jarsigner/emptymanifest.sh - test/jdk/sun/security/tools/jarsigner/jvindex.sh - test/jdk/sun/security/tools/jarsigner/nameclash.sh - test/jdk/sun/security/tools/jarsigner/newsize7.sh - test/jdk/sun/security/tools/jarsigner/oldsig.sh - test/jdk/sun/security/tools/jarsigner/onlymanifest.sh - test/jdk/sun/security/tools/jarsigner/passtype.sh - test/jdk/sun/security/tools/jarsigner/samename.sh - test/jdk/sun/security/tools/jarsigner/weaksize.sh - test/jdk/sun/security/tools/keytool/CloneKeyAskPassword.sh - test/jdk/sun/security/tools/keytool/NoExtNPE.sh - test/jdk/sun/security/tools/keytool/SecretKeyKS.sh - test/jdk/sun/security/tools/keytool/StandardAlgName.sh - test/jdk/sun/security/tools/keytool/StorePasswordsByShell.sh - test/jdk/sun/security/tools/keytool/default_options.sh - test/jdk/sun/security/tools/keytool/emptysubject.sh - test/jdk/sun/security/tools/keytool/file-in-help.sh - test/jdk/sun/security/tools/keytool/i18n.sh - test/jdk/sun/security/tools/keytool/importreadall.sh - test/jdk/sun/security/tools/keytool/keyalg.sh - test/jdk/sun/security/tools/keytool/newhelp.sh - test/jdk/sun/security/tools/keytool/resource.sh - test/jdk/sun/security/tools/keytool/selfissued.sh - test/jdk/sun/security/tools/keytool/trystore.sh Changeset: f0cec8e8d2ab Author: psadhukhan Date: 2019-04-23 13:40 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f0cec8e8d2ab Merge Changeset: e0516ee47c36 Author: psadhukhan Date: 2019-04-23 14:20 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/e0516ee47c36 Merge Changeset: a61da18408c1 Author: lfoltan Date: 2019-04-23 07:05 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a61da18408c1 8222502: Replace 19,20 case alternatives with JVM_CONSTANT_Module/Package names Summary: Add JVM_CONSTANT_Module and JVM_CONSTANT_Package to classfile_constants.h Reviewed-by: coleenp, hseigel ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/native/include/classfile_constants.h.template ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java Changeset: 86c1da00dd6a Author: pmuthuswamy Date: 2019-04-23 18:28 +0530 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/86c1da00dd6a 8219998: Eliminate inherently singleton lists Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllPackagesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialFieldWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlSerialMethodWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.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/markup/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeFieldWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ConstructorWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/EnumConstantWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/FieldWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/MethodWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/PackageSummaryWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/PropertyWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/SerializedFormWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeFieldBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstructorBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/EnumConstantBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/FieldBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MethodBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PackageSummaryBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PropertyBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/SerializedFormBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/langtools/jdk/javadoc/doclet/testHiddenTag/TestHiddenTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlTag/TestHtmlTag.java ! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java ! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java ! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testOptions/TestOptions.java ! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestBadOverride.java ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java + test/langtools/jdk/javadoc/doclet/testSingletonLists/TestSingletonLists.java ! test/langtools/jdk/javadoc/doclet/testSummaryTag/TestSummaryTag.java ! test/langtools/jdk/javadoc/doclet/testUseOption/TestUseOption.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/A11yChecker.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/HtmlChecker.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/HtmlParser.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java Changeset: ab57d6bebed8 Author: redestad Date: 2019-04-11 14:56 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/ab57d6bebed8 8215017: Improve String::equals warmup characteristics Reviewed-by: jlaskey ! src/java.base/share/classes/java/lang/String.java + test/micro/org/openjdk/bench/java/lang/StringEquals.java Changeset: a9953a8ccd66 Author: hannesw Date: 2019-04-23 16:50 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a9953a8ccd66 8222526: Use of no longer existing jquery directory in script.js Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js Changeset: f5657f30bb01 Author: jcbeyler Date: 2019-04-23 08:11 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f5657f30bb01 8213501: Deploy ExceptionJniWrapper for a few tests Summary: Add more tests to be using the wrapper Reviewed-by: phh, amenkov, sspitsyn, dholmes, cjplummer ! make/test/JtregNativeHotspot.gmk ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002/attach002Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002/libattach002Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/libattach021Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/attach022Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/libattach022Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/libap04t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t001/bi01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t001/libbi01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/BooleanArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/ByteArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/CharArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/DoubleArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/FloatArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/IntArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/LongArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/ShortArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/StringCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNILocalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIWeakGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/jni/ExceptionCheckingJniEnv.hpp Changeset: 69cfd80f8706 Author: lfoltan Date: 2019-04-23 14:09 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/69cfd80f8706 8218994: Consolidate indy and condy JVM information within a BootstrapInfo data structure Summary: Introduce BootstrapInfo data structure and merge invocation of a bootstrap method for condy and indy into invoke_bootstrap_method. Reviewed-by: acorn, coleenp Contributed-by: john.r.rose at oracle.com, lois.foltan at oracle.com ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionary.hpp + src/hotspot/share/interpreter/bootstrapInfo.cpp + src/hotspot/share/interpreter/bootstrapInfo.hpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/constantPool.hpp Changeset: c40b2a190173 Author: jwilhelm Date: 2019-04-23 22:55 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/c40b2a190173 8221598: Update Graal Reviewed-by: kvn ! make/CompileJavaModules.gmk ! make/test/JtregGraalUnit.gmk ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.collections/src/jdk/internal/vm/compiler/collections/package-info.java + src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.libgraal/src/jdk/internal/vm/compiler/libgraal/LibGraal.java + src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.libgraal/src/jdk/internal/vm/compiler/libgraal/OptionsEncoder.java ! src/jdk.internal.vm.compiler/share/classes/jdk.internal.vm.compiler.word/src/jdk/internal/vm/compiler/word/package-info.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64BitCountAssemblerTest.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/AArch64InstructionEncodingTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64.test/src/org/graalvm/compiler/asm/aarch64/test/TestProtectedAssembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64Assembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.aarch64/src/org/graalvm/compiler/asm/aarch64/AArch64MacroAssembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.amd64/src/org/graalvm/compiler/asm/amd64/AMD64Assembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm.sparc/src/org/graalvm/compiler/asm/sparc/SPARCAssembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm/src/org/graalvm/compiler/asm/Assembler.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.asm/src/org/graalvm/compiler/asm/Label.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64.test/src/org/graalvm/compiler/core/aarch64/test/AArch64TestBitAndBranchTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64ArithmeticLIRGenerator.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.aarch64/src/org/graalvm/compiler/core/aarch64/AArch64NodeMatchRules.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/GraalOptions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/spi/ForeignCallsProvider.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.common/src/org/graalvm/compiler/core/common/util/AbstractTypeReader.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/TypeReader.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/TypeWriter.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/UnsafeArrayTypeReader.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.common/src/org/graalvm/compiler/core/common/util/UnsafeArrayTypeWriter.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/BasePhaseBinaryGraphTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/GraphResetDebugTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core.test/src/org/graalvm/compiler/core/test/TypeWriterTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.core/src/org/graalvm/compiler/core/gen/DebugInfoBuilder.java ! 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.graph/src/org/graalvm/compiler/graph/Node.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.graph/src/org/graalvm/compiler/graph/NodeList.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64.test/src/org/graalvm/compiler/hotspot/aarch64/test/AArch64UncompressPointerTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotBackendFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotMove.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64.test/src/org/graalvm/compiler/hotspot/amd64/test/StubAVXTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotBackendFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.amd64/src/org/graalvm/compiler/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotBackendFactory.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.sparc/src/org/graalvm/compiler/hotspot/sparc/SPARCHotSpotForeignCallsProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/ArrayCopyIntrinsificationTest.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/CompileTheWorld.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CompileTheWorldTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/GraalOSRTestBase.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotBase64Test.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/MemoryUsageBenchmark.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/ObjectHashCodeInliningTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/BootstrapWatchDog.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompilationTask.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/GraalHotSpotVMConfig.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/HotSpotCompiledCodeBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotForeignCallLinkage.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotForeignCallLinkageImpl.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/HotSpotReplacementsImpl.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/IsGraalPredicate.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/SymbolicSnippetEncoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/DefaultHotSpotLoweringProvider.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotClassInitializationPlugin.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotForeignCallsProviderImpl.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/phases/aot/AOTInliningPolicy.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/MonitorSnippets.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/ObjectCloneNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/stubs/SnippetStub.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.java/src/org/graalvm/compiler/java/BciBlockMapping.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/BytecodeParser.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.java/src/org/graalvm/compiler/java/FrameStateBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/jdk/System_currentTimeMillis02.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/jdk/System_nanoTime02.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/lang/Math_log10.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/lang/UnaryMath.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/SynchronizedLoopExit01.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/SynchronizedParserInlineTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64BitManipulationOp.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64ControlFlow.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.aarch64/src/org/graalvm/compiler/lir/aarch64/AArch64Move.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ControlFlow.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/alloc/lsra/LinearScanWalker.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/asm/CompilationResultBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.lir/src/org/graalvm/compiler/lir/constopt/ConstantLoadOptimization.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/src/org/graalvm/compiler/loop/LoopEx.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/CallTargetNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/DeoptimizingNode.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/IfNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/Invoke.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/InvokeNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/InvokeWithExceptionNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/StructuredGraph.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/IntegerLowerThanNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/IsNullNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/calc/PointerEqualsNode.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.nodes/src/org/graalvm/compiler/nodes/extended/ForeignCallNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/extended/GuardedUnsafeLoadNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/GeneratedInvocationPlugin.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/GraphBuilderContext.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/InlineInvokePlugin.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/IntrinsicContext.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/InvocationPlugin.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/InvocationPlugins.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/graphbuilderconf/MethodSubstitutionPlugin.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/MethodCallTargetNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/MonitorExitNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/java/TypeSwitchNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/DelegatingReplacements.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/spi/Replacements.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.nodes/src/org/graalvm/compiler/nodes/util/GraphUtil.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/ConditionalEliminationPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/DeoptimizationGroupingPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/FloatingReadPhase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/UseTrappingNullChecksPhase.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/info/elem/InlineableGraph.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.common/src/org/graalvm/compiler/phases/common/inlining/policy/GreedyInliningPolicy.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/policy/InlineEverythingPolicy.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/policy/InlineMethodSubstitutionsPolicy.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/policy/InliningPolicy.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.phases.common/src/org/graalvm/compiler/phases/common/inlining/walker/InliningData.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.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64BitCountNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64GraphBuilderPlugins.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64IntegerSubstitutions.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64LongSubstitutions.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.processor/src/org/graalvm/compiler/replacements/processor/GeneratedFoldPlugin.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/MethodSubstitutionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/ReplacementsParseTest.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/RootMethodSubstitutionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/SnippetsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StandardMethodSubstitutionsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringCompareToTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringCompressInflateTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringIndexOfCharTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringSubstitutionTestBase.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/StringSubstitutionsTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/SubstitutionNodeSourcePositionTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.test/src/org/graalvm/compiler/replacements/test/classfile/ClassfileBytecodeProviderTest.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/CachingPEGraphDecoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/GraphKit.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/IntrinsicGraphBuilder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/PEGraphDecoder.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/ReplacementsImpl.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/SnippetTemplate.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopyCallNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopySnippets.java + src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopyWithDelayedLoweringNode.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopyWithSlowPathNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/nodes/BitCountNode.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.serviceprovider/src/org/graalvm/compiler/serviceprovider/GraalServices.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.virtual/src/org/graalvm/compiler/virtual/phases/ea/VirtualizerToolImpl.java ! src/jdk.internal.vm.compiler/share/classes/org.graalvm.graphio/src/org/graalvm/graphio/GraphProtocol.java + test/hotspot/jtreg/compiler/graalunit/HotspotAarch64Test.java ! test/hotspot/jtreg/compiler/graalunit/TestPackages.txt Changeset: 848a2f381e2c Author: darcy Date: 2019-04-23 14:56 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/848a2f381e2c 8222817: Refactor printing processor to use streams Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java Changeset: cb8e16d6ff1e Author: ysuenaga Date: 2019-04-24 17:09 +0900 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/cb8e16d6ff1e 8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero Reviewed-by: egahlin, mgronlun ! src/hotspot/share/jfr/periodic/sampling/jfrCallTrace.cpp ! src/hotspot/share/jfr/recorder/service/jfrOptionSet.cpp ! src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp ! src/hotspot/share/jfr/utilities/jfrTypes.hpp Changeset: 367d9cc2b35e Author: fyang Date: 2019-04-20 15:55 +0800 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/367d9cc2b35e 8222785: aarch64: add necessary masking for immediate shift counts Reviewed-by: aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_ad.m4 Changeset: f6f95cb8643e Author: shade Date: 2019-04-24 11:39 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/f6f95cb8643e 8222843: Print Shenandoah cset map addresses in hs_err Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: 24eb7720919c Author: shade Date: 2019-04-24 11:40 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/24eb7720919c 8222838: Shenandoah: SEGV on accessing cset bitmap for NULL ptr Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: b6db97903b69 Author: hseigel Date: 2019-04-24 08:27 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/b6db97903b69 8221685: -XX:BytecodeVerificationRemote and -XX:BytecodeVerificationLocal should be diagnostic options Summary: Make the options diagnostic and add -XX:+UnlockDiagnosticVMOptions to tests where needed. Reviewed-by: lfoltan, acorn, dholmes ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/compiler/linkage/TestLinkageErrorInGenerateOopMap.java ! test/hotspot/jtreg/runtime/Nestmates/privateMethods/TestInvokeErrors.java ! test/hotspot/jtreg/runtime/appcds/VerifierTest.java ! test/hotspot/jtreg/runtime/clone/invokevirtual/HasLocalClone.jasm ! test/hotspot/jtreg/runtime/clone/invokevirtual/NoLocalClone.jasm ! test/hotspot/jtreg/runtime/clone/invokevirtual/NoLocalCloneAbstr.jasm ! test/hotspot/jtreg/runtime/lambda-features/TestStaticandInstance.java ! test/hotspot/jtreg/runtime/verifier/TestSigParse.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/anonloader/stress/parallelLoad/Test.java Changeset: c604234be658 Author: redestad Date: 2019-04-24 15:37 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/c604234be658 8222532: (zipfs) Performance regression when writing ZipFileSystem entries in parallel Reviewed-by: lancea, clanger, alanb ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java ! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipPath.java Changeset: 04857e2cd509 Author: dcubed Date: 2019-04-24 10:20 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/04857e2cd509 8222295: more baseline cleanups from Async Monitor Deflation project Reviewed-by: coleenp, acorn, dholmes ! src/hotspot/share/oops/markOop.cpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/objectMonitor.inline.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectMonitor.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/MonitorCacheDumpPanel.java Changeset: a9ab154b1384 Author: jjg Date: 2019-04-24 11:26 -0700 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/a9ab154b1384 8222669: Create and use new html.Entity class Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeFieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Entity.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/FixedStringContent.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/markup/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/RawHtml.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/StringContent.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java Changeset: bebb82ef3434 Author: mbalao Date: 2019-04-24 16:25 -0300 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/bebb82ef3434 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 Reviewed-by: mullan, xuelei + test/jdk/sun/security/pkcs11/tls/tls12/FipsModeTLS12.java - test/jdk/sun/security/pkcs11/tls/tls12/TestTLS12.java Changeset: 8f7e6b41528f Author: shade Date: 2019-04-26 13:01 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk/rev/8f7e6b41528f Merge ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/macros.hpp - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64IntegerSubstitutions.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements.aarch64/src/org/graalvm/compiler/replacements/aarch64/AArch64LongSubstitutions.java - src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/arraycopy/ArrayCopyWithSlowPathNode.java ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/runtime/MemberName/MemberNameLeak.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAddLambdaExpression.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineDeleteJmethod.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineSubtractLambdaExpression.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002/attach002Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach002/libattach002Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/libattach021Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/attach022Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/libattach022Agent00.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/libap04t003.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t001/bi01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI01/bi01t001/libbi01t001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/BooleanArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/ByteArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/CharArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/DoubleArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/FloatArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/IntArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/LongArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/ShortArrayCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jni/StringCriticalLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIGlobalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNILocalRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIRefLocker.cpp ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/lock/jniref/JNIWeakGlobalRefLocker.cpp - test/jdk/sun/security/pkcs11/tls/tls12/TestTLS12.java From zgu at redhat.com Fri Apr 26 12:50:09 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 26 Apr 2019 08:50:09 -0400 Subject: RFR(M) 8222992: Shenandoah: Pre-evacuate all roots Message-ID: <2f6eeb40-ccf5-9dd8-7ccc-181e993dedf0@redhat.com> Since we switched to strong to-space invariant, if we pre-evacuate all roots, the roots should only contain to-space references, until next evacuation cycle. Therefore, we can avoid a couple of update roots calls in regular paths. Also, make code easy to reason. The change may prolong final_mark pause. It is temporary. I intent to move several pre-evacuated roots to concurrent phase, in followup RFEs. Bug: https://bugs.openjdk.java.net/browse/JDK-8222992 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222992/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu From shade at redhat.com Fri Apr 26 13:02:21 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 26 Apr 2019 15:02:21 +0200 Subject: RFR(M) 8222992: Shenandoah: Pre-evacuate all roots In-Reply-To: <2f6eeb40-ccf5-9dd8-7ccc-181e993dedf0@redhat.com> References: <2f6eeb40-ccf5-9dd8-7ccc-181e993dedf0@redhat.com> Message-ID: On 4/26/19 2:50 PM, Zhengyu Gu wrote: > Since we switched to strong to-space invariant, if we pre-evacuate all roots, the roots should only > contain to-space references, until next evacuation cycle. Therefore, we can avoid a couple of update > roots calls in regular paths. Also, make code easy to reason. > > The change may prolong final_mark pause. It is temporary. I intent to move several pre-evacuated > roots to concurrent phase, in followup RFEs. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222992 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222992/webrev.00/ I'll take a more extensive look next week. Some brief observations here: *) There is a plain store in ShenandoahBarrierSet::AccessBarrier::oop_load_not_in_heap. First, I wonder if it even makes sense to do it here -- it feels awkward to have writes in "loads". Second, shouldn't that be a CAS, on the off-chance something else is storing the another value? *) I wonder if verify_roots() and the associated closure belongs to Verifier (not necessarily protected by ShenandoahVerify) or shenandoahAsserts. In fact, maybe we should just strategically rely on Verifier to catch non-forwarded roots? *) In final-marking, the assert(task_queues()->is_empty(), "Should be empty"); is gone, why? *) Can the per-line DEBUG_ONLY in shenandoahPhaseTimings be turned into #ifdef DEBUG block? *) Typo here, "Verfiy": 322 DEBUG_ONLY(f(verify_roots, "Verfiy Roots")) \ -Aleksey From zgu at redhat.com Fri Apr 26 13:54:30 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 26 Apr 2019 09:54:30 -0400 Subject: RFR(M) 8222992: Shenandoah: Pre-evacuate all roots In-Reply-To: References: <2f6eeb40-ccf5-9dd8-7ccc-181e993dedf0@redhat.com> Message-ID: <3cf86adc-6865-0b8a-23bd-c93884d6d456@redhat.com> Hi Aleksey, Thanks for reviewing. On 4/26/19 9:02 AM, Aleksey Shipilev wrote: > On 4/26/19 2:50 PM, Zhengyu Gu wrote: >> Since we switched to strong to-space invariant, if we pre-evacuate all roots, the roots should only >> contain to-space references, until next evacuation cycle. Therefore, we can avoid a couple of update >> roots calls in regular paths. Also, make code easy to reason. >> >> The change may prolong final_mark pause. It is temporary. I intent to move several pre-evacuated >> roots to concurrent phase, in followup RFEs. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222992 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222992/webrev.00/ > > I'll take a more extensive look next week. Some brief observations here: > > *) There is a plain store in ShenandoahBarrierSet::AccessBarrier BarrierSetT>::oop_load_not_in_heap. First, I wonder if it even makes sense to do it here -- it feels > awkward to have writes in "loads". Second, shouldn't that be a CAS, on the off-chance something else > is storing the another value? I think it is a Copy-on-Read semantics, no? I don't think it needs CAS here, since load-reference-barrier should return to-space oop, and we should only have one to-space copy. > > *) I wonder if verify_roots() and the associated closure belongs to Verifier (not necessarily > protected by ShenandoahVerify) or shenandoahAsserts. In fact, maybe we should just strategically > rely on Verifier to catch non-forwarded roots? Can do this. > > *) In final-marking, the assert(task_queues()->is_empty(), "Should be empty"); is gone, why? My mistake, will revert this part. > > *) Can the per-line DEBUG_ONLY in shenandoahPhaseTimings be turned into #ifdef DEBUG block? Could not get this to work, cause they are embedded inside a macro :-) > > *) Typo here, "Verfiy": > > 322 DEBUG_ONLY(f(verify_roots, "Verfiy Roots")) \ Will fix this. > > -Aleksey > > > From shade at redhat.com Fri Apr 26 16:54:43 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 26 Apr 2019 18:54:43 +0200 Subject: RFR [8u]: Bulk backports to sh/jdk8 Message-ID: <42949d2a-7124-1fce-9dd1-0f4b89b56d26@redhat.com> This backports a few things to sh/jdk8u: [backport] 8217043: Shenandoah: SIGSEGV in Type::meet_helper() at barrier expansion time [backport] 8222843: Print Shenandoah cset map addresses in hs_err [backport] 8222838: Shenandoah: SEGV on accessing cset bitmap for NULL ptr [backport] 8220712: [TESTBUG] gc/shenandoah/compiler/TestMaybeNullUnsafeAccess should run with ... [backport] 8222130: Shenandoah should verify roots after pre-evacuation [backport] 8222185: Shenandoah should report "committed" as capacity [backport] 8222186: Shenandoah should not uncommit below minimum heap size Webrev: http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20190426/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Fri Apr 26 18:03:19 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 26 Apr 2019 20:03:19 +0200 Subject: RFR [8u]: Bulk backports to sh/jdk8 In-Reply-To: <42949d2a-7124-1fce-9dd1-0f4b89b56d26@redhat.com> References: <42949d2a-7124-1fce-9dd1-0f4b89b56d26@redhat.com> Message-ID: <27da86c4-d11e-263d-30fa-c323848de07f@redhat.com> This looks very good. Thank you! Roman > This backports a few things to sh/jdk8u: > [backport] 8217043: Shenandoah: SIGSEGV in Type::meet_helper() at barrier expansion time > [backport] 8222843: Print Shenandoah cset map addresses in hs_err > [backport] 8222838: Shenandoah: SEGV on accessing cset bitmap for NULL ptr > [backport] 8220712: [TESTBUG] gc/shenandoah/compiler/TestMaybeNullUnsafeAccess should run with ... > [backport] 8222130: Shenandoah should verify roots after pre-evacuation > [backport] 8222185: Shenandoah should report "committed" as capacity > [backport] 8222186: Shenandoah should not uncommit below minimum heap size > > Webrev: > http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20190426/webrev.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Fri Apr 26 20:11:29 2019 From: shade at redhat.com (shade at redhat.com) Date: Fri, 26 Apr 2019 20:11:29 +0000 Subject: hg: shenandoah/jdk8u/hotspot: 7 new changesets Message-ID: <201904262011.x3QKBTO0008402@aojmv0008.oracle.com> Changeset: 34b1ceb7e8b7 Author: roland Date: 2019-01-14 13:53 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/34b1ceb7e8b7 [backport] 8217043: Shenandoah: SIGSEGV in Type::meet_helper() at barrier expansion time Reviewed-by: shade, rkennke, thartmann ! src/share/vm/opto/shenandoahSupport.cpp Changeset: 5f9bdc7dfcff Author: shade Date: 2019-04-24 11:39 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/5f9bdc7dfcff [backport] 8222843: Print Shenandoah cset map addresses in hs_err Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 3c3e7ca4c0f6 Author: shade Date: 2019-04-24 11:40 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/3c3e7ca4c0f6 [backport] 8222838: Shenandoah: SEGV on accessing cset bitmap for NULL ptr Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 3cef3e798541 Author: shade Date: 2019-03-15 13:01 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/3cef3e798541 [backport] 8220712: [TESTBUG] gc/shenandoah/compiler/TestMaybeNullUnsafeAccess should run with Shenandoah enabled Reviewed-by: rkennke, roland ! test/gc/shenandoah/compiler/TestMaybeNullUnsafeAccess.java Changeset: e8b0f8fd95cf Author: shade Date: 2019-04-08 19:43 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/e8b0f8fd95cf [backport] 8222130: Shenandoah should verify roots after pre-evacuation Reviewed-by: rkennke, zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp Changeset: d6c5e9e4159c Author: shade Date: 2019-04-09 21:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/d6c5e9e4159c [backport] 8222185: Shenandoah should report "committed" as capacity Reviewed-by: zgu, rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Changeset: 388e314ebde2 Author: shade Date: 2019-04-09 21:20 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/388e314ebde2 [backport] 8222186: Shenandoah should not uncommit below minimum heap size Reviewed-by: zgu, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/runtime/arguments.cpp ! test/gc/shenandoah/mxbeans/TestMemoryMXBeans.java From shade at redhat.com Fri Apr 26 20:11:47 2019 From: shade at redhat.com (shade at redhat.com) Date: Fri, 26 Apr 2019 20:11:47 +0000 Subject: hg: shenandoah/jdk11: 5 new changesets Message-ID: <201904262011.x3QKBlv8008516@aojmv0008.oracle.com> Changeset: 250cfd01cd30 Author: rkennke Date: 2019-03-27 22:25 +0100 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/250cfd01cd30 [backport] 8220664: Simplify ShenandoahUpdateHeapRefsClosure Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp ! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.inline.hpp Changeset: ab311cec4cb5 Author: zgu Date: 2019-04-12 09:55 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/ab311cec4cb5 [backport] 8222403: Shenandoah: Remove ShenandoahAlwaysTrueClosure, use AlwaysTrueClosure instead Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.cpp Changeset: 2d730c196ae5 Author: zgu Date: 2019-04-15 13:07 -0400 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/2d730c196ae5 [backport] 8222425: Shenandoah: Move commonly used closures to separate files Reviewed-by: shade + src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp + src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp Changeset: fed482384541 Author: shade Date: 2019-04-24 11:39 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/fed482384541 [backport] 8222843: Print Shenandoah cset map addresses in hs_err Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: 32d81b0ed99c Author: shade Date: 2019-04-24 11:40 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk11/rev/32d81b0ed99c [backport] 8222838: Shenandoah: SEGV on accessing cset bitmap for NULL ptr Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp From shade at redhat.com Sat Apr 27 23:32:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 28 Apr 2019 01:32:58 +0200 Subject: RFR [8u]: Prettify Shenandoah JDK 8 logging Message-ID: Webrev: http://cr.openjdk.java.net/~shade/shenandoah/8u-logging-pretty/webrev.01/ Wanted to do this for a while now. Our 8u logging uses our own translation layer to use Unified Logging -like interface in Shenandoah code. However, that translation code produces weirdly formatted result, which complicates parsing/following GC logs that our adopters report. We can significantly improve that! It requires fiddling with the mess that C varargs are, but the improvement is worth it. Logs before/after: http://cr.openjdk.java.net/~shade/shenandoah/8u-logging-pretty/before.txt http://cr.openjdk.java.net/~shade/shenandoah/8u-logging-pretty/after.txt Testing: hotspot_gc_shenandoah; eyeballing GC logs with different logging options -- Thanks, -Aleksey From rkennke at redhat.com Mon Apr 29 10:10:10 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 29 Apr 2019 12:10:10 +0200 Subject: RFR [8u]: Prettify Shenandoah JDK 8 logging In-Reply-To: References: Message-ID: <2c7d5747-31f8-199e-672e-a2fa27742e3b@redhat.com> Very good! Let's do this! Thanks, Roman > Webrev: > http://cr.openjdk.java.net/~shade/shenandoah/8u-logging-pretty/webrev.01/ > > Wanted to do this for a while now. Our 8u logging uses our own translation layer to use Unified > Logging -like interface in Shenandoah code. However, that translation code produces weirdly > formatted result, which complicates parsing/following GC logs that our adopters report. We can > significantly improve that! It requires fiddling with the mess that C varargs are, but the > improvement is worth it. > > Logs before/after: > http://cr.openjdk.java.net/~shade/shenandoah/8u-logging-pretty/before.txt > http://cr.openjdk.java.net/~shade/shenandoah/8u-logging-pretty/after.txt > > Testing: hotspot_gc_shenandoah; eyeballing GC logs with different logging options > From shade at redhat.com Mon Apr 29 10:40:03 2019 From: shade at redhat.com (shade at redhat.com) Date: Mon, 29 Apr 2019 10:40:03 +0000 Subject: hg: shenandoah/jdk8u/hotspot: Prettify Shenandoah JDK 8 logging Message-ID: <201904291040.x3TAe30J002695@aojmv0008.oracle.com> Changeset: a994d7874724 Author: shade Date: 2019-04-28 01:42 +0200 URL: http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot/rev/a994d7874724 Prettify Shenandoah JDK 8 logging ! src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahLogging.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahLogging.hpp From shade at redhat.com Mon Apr 29 10:40:12 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 29 Apr 2019 12:40:12 +0200 Subject: RFR [8u]: Prettify Shenandoah JDK 8 logging In-Reply-To: <2c7d5747-31f8-199e-672e-a2fa27742e3b@redhat.com> References: <2c7d5747-31f8-199e-672e-a2fa27742e3b@redhat.com> Message-ID: <5a3b185e-73d9-b2f8-4576-c655dd631c33@redhat.com> On 4/29/19 12:10 PM, Roman Kennke wrote: > Very good! Let's do this! Thanks, pushed. -Aleksey From gnu.andrew at redhat.com Mon Apr 29 13:00:34 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 29 Apr 2019 14:00:34 +0100 Subject: [aarch64-port-dev ] RFR: RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2018-12-13 In-Reply-To: References: <2ef19d5c-e524-3d9b-a52a-6c968926f868@redhat.com> <509ab726-539e-bc34-8cf9-45afb44855ad@redhat.com> <6c7ef38b-678d-4cdc-49d9-c6c03163ceb4@redhat.com> Message-ID: <77d5861f-9479-f5fb-c270-7a68853225f9@redhat.com> On 29/04/2019 09:58, Roman Kennke wrote: > Hi there, > > now that the CPU is done, I'd like to integrate this (already reviewed > and discussed) batch of Shenandoah changes into > aarch64-port/jdk8u-shenandoah. Is that ok by you? > > When this is done, I'll bring over the remaining batch of new stuff from > sh/jdk8u to aarch64/jdk8u-sh. > > Roman > Yes, now would be a good time. With the changes in upstream jdk8u operation, we don't have the same issue with a big backlog after the CPU. I intend to start weekly merges with upstream once the first build for 8u222 goes into jdk8u on Wednesday. That should keep merges down to smaller, manageable chunks. I guess Aleksey may want to do something similar with 11u. Incidentally, i've CCed the Shenandoah list on this mail as they seem to have been missed in the original post. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Mon Apr 29 13:17:47 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 29 Apr 2019 15:17:47 +0200 Subject: [aarch64-port-dev ] RFR: RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2018-12-13 In-Reply-To: <77d5861f-9479-f5fb-c270-7a68853225f9@redhat.com> References: <2ef19d5c-e524-3d9b-a52a-6c968926f868@redhat.com> <509ab726-539e-bc34-8cf9-45afb44855ad@redhat.com> <6c7ef38b-678d-4cdc-49d9-c6c03163ceb4@redhat.com> <77d5861f-9479-f5fb-c270-7a68853225f9@redhat.com> Message-ID: <1b5cbafa-500d-6ff8-8264-7fad8a312ae1@redhat.com> On 4/29/19 3:00 PM, Andrew John Hughes wrote: > I intend to start weekly merges with upstream once the first build for > 8u222 goes into jdk8u on Wednesday. That should keep merges down to > smaller, manageable chunks. I guess Aleksey may want to do something > similar with 11u. We do exactly that with jdk-updates/jdk11u -> sh/jdk11 merges :) -Aleksey From shade at redhat.com Mon Apr 29 15:52:08 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 29 Apr 2019 17:52:08 +0200 Subject: Troubles with Shenandoah In-Reply-To: <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> References: <3af88fcc-481a-f685-1a11-14a6bad94e96@redhat.com> <096296e24454fb31ce075bafd54a89a8bffb5bab.camel@redhat.com> <0ef0b42d-2d13-945c-1ab2-261c88c94320@redhat.com> Message-ID: <39adac14-d332-09bf-75e1-64dab9de55e1@redhat.com> On 4/7/19 11:09 PM, Aleksey Shipilev wrote: > On 4/7/19 10:57 PM, Simone Bordet wrote: >> On Sun, Apr 7, 2019 at 7:52 PM Simone Bordet wrote: >>> Will try the fastdebug build and report back. >> >> I got a crash with fastdebug, attached hs_err. >> >> Let me know if it's helpful. >> I'm interested in the details of the failure, if the file has enough >> information. > > I think it has. > > Signal is raised trying to access 0x00007f006b8a54fc: > siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x00007f006b8a54fc > > ...which looks to come from %rbx: > RBX=0x00007f006b8a54fc: in /lib/x86_64-linux-gnu/libnsl.so.1 at > 0x00007f006b7c5000 > > ...and Instructions section disassembly shows this: > https://onlinedisassembler.com/odaweb/uV5P7D1q/0 > > 00000016 48 bb fc 54 8a 6b 00 7f 00 00 movabs rbx,0x7f006b8a54fc > 00000020 80 3c 0b 00 cmp BYTE PTR [rbx+rcx*1],0x0 <-- SEGV here > > It looks like bad constant oop in the generated code. -XX:ScavengeRootsInCode=0 might be a plausible > workaround. FYI, this one is actually: https://bugs.openjdk.java.net/browse/JDK-8222838 ...and it is fixed and backported to 12u, 11u, 8u. -Aleksey From rkennke at redhat.com Mon Apr 29 19:14:15 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 29 Apr 2019 21:14:15 +0200 Subject: RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2019-04-29 Message-ID: <51050c8d-92dd-b0f0-3657-65d91a34fec0@redhat.com> Please review the following proposed changes: This integrates changes from shenandoah/jdk8u into aarch64-port/jdk8u-shenandoah repository, reaching back to December 2018. It's bugfixes, improvements and new features that have been originally done in Shenandoah dev repo, and then backported to Shenandoah JDK8u repo and tested there for a while too. Most of it is Shenandoah-only changes. Short tour of shared-code changes: - Change in classLoaderStats.cpp introduces a new required+missing object equals barrier. - Change in subnode.cpp *reverts* back to orginal upstream code because of changed object equal barrier in C2. - arguments.cpp change is in fact in Shenandoah-only path. List of changes: http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2019-04-29/changes.txt Complete Webrev: http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2019-04-29/webrev-all.00/ Thanks for reviewing! Roman From zgu at redhat.com Mon Apr 29 19:19:32 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 29 Apr 2019 15:19:32 -0400 Subject: RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2019-04-29 In-Reply-To: <51050c8d-92dd-b0f0-3657-65d91a34fec0@redhat.com> References: <51050c8d-92dd-b0f0-3657-65d91a34fec0@redhat.com> Message-ID: <1994c064-64a7-8bee-9dfd-450467ffed83@redhat.com> Good to me. -Zhengyu On 4/29/19 3:14 PM, Roman Kennke wrote: > Please review the following proposed changes: > > This integrates changes from shenandoah/jdk8u into > aarch64-port/jdk8u-shenandoah repository, reaching back to December 2018. > It's bugfixes, improvements and new features that have been originally > done in Shenandoah dev repo, and then backported to Shenandoah JDK8u > repo and tested there for a while too. > > Most of it is Shenandoah-only changes. > > Short tour of shared-code changes: > - Change in classLoaderStats.cpp introduces a new required+missing > object equals barrier. > - Change in subnode.cpp *reverts* back to orginal upstream code because > of changed object equal barrier in C2. > - arguments.cpp change is in fact in Shenandoah-only path. > > List of changes: > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2019-04-29/changes.txt > > > Complete Webrev: > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2019-04-29/webrev-all.00/ > > > Thanks for reviewing! > Roman From shade at redhat.com Mon Apr 29 20:19:43 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 29 Apr 2019 22:19:43 +0200 Subject: RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2019-04-29 In-Reply-To: <51050c8d-92dd-b0f0-3657-65d91a34fec0@redhat.com> References: <51050c8d-92dd-b0f0-3657-65d91a34fec0@redhat.com> Message-ID: <1a56142c-c531-ee06-f271-d6854dc6a72f@redhat.com> On 4/29/19 9:14 PM, Roman Kennke wrote: > List of changes: > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2019-04-29/changes.txt > > Complete Webrev: > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2019-04-29/webrev-all.00/ Looks okay to me. My only wish is to wait a little while a few last (pretty innocuous in themselves) fixes pass the builds and tests in a day or two. -Aleksey From rkennke at redhat.com Mon Apr 29 20:35:42 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 29 Apr 2019 22:35:42 +0200 Subject: RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2019-04-29 In-Reply-To: <1a56142c-c531-ee06-f271-d6854dc6a72f@redhat.com> References: <51050c8d-92dd-b0f0-3657-65d91a34fec0@redhat.com> <1a56142c-c531-ee06-f271-d6854dc6a72f@redhat.com> Message-ID: <084dff65-c8c2-dea4-6d36-9f7f4656dede@redhat.com> >> List of changes: >> http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2019-04-29/changes.txt >> >> Complete Webrev: >> http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2019-04-29/webrev-all.00/ > > Looks okay to me. My only wish is to wait a little while a few last (pretty innocuous in themselves) > fixes pass the builds and tests in a day or two. Right, no problem. Just ping me when it's good. ;-) Also, I'd like to tag the forest after it's all pushed+tested. Maybe something like aarch64-shenandoah-jdk-jdk8u212-b05? Any suggestions? Roman From shade at redhat.com Tue Apr 30 12:27:01 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 30 Apr 2019 14:27:01 +0200 Subject: RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2019-04-29 In-Reply-To: <084dff65-c8c2-dea4-6d36-9f7f4656dede@redhat.com> References: <51050c8d-92dd-b0f0-3657-65d91a34fec0@redhat.com> <1a56142c-c531-ee06-f271-d6854dc6a72f@redhat.com> <084dff65-c8c2-dea4-6d36-9f7f4656dede@redhat.com> Message-ID: <8bf2849b-002e-3eb0-15e4-7c49f840f683@redhat.com> On 4/29/19 10:35 PM, Roman Kennke wrote: >>> List of changes: >>> http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2019-04-29/changes.txt >>> >>> Complete Webrev: >>> http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2019-04-29/webrev-all.00/ >> >> Looks okay to me. My only wish is to wait a little while a few last (pretty innocuous in themselves) >> fixes pass the builds and tests in a day or two. > > Right, no problem. Just ping me when it's good. ;-) Two rounds of build-tests have finished on sh/jdk8 that include all of the changesets this RFR suggests to integrate. Thumbs up from me. Andrew(s) need to ack the push now. -Aleksey From rkennke at redhat.com Tue Apr 30 13:26:20 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 30 Apr 2019 15:26:20 +0200 Subject: RFR(12u): 8223144: Remove obsolete null-handling block in ShenandoahBarrierNode::skip_through_barrier() Message-ID: <5109b413-45a6-893f-2264-7eedc1a0e48b@redhat.com> There is a block that attempts to skip a Shenandoah barrier that is wrapped in a null-check. This appears to be a left-over from when we expanded barriers in .ad. We should have no business dealing with null-checks that we haven't generated ourselves. This affects a bug-fix that we need to do for shenandoah/jdk11, where we seem to be break the graph when keeping that code. The block is already gone in jdk/jdk. Bug: https://bugs.openjdk.java.net/browse/JDK-8223144 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8223144/webrev.00/ Testing: hotspot_gc_shenandoah passes Roman From shade at redhat.com Tue Apr 30 13:30:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 30 Apr 2019 15:30:58 +0200 Subject: RFR(12u): 8223144: Remove obsolete null-handling block in ShenandoahBarrierNode::skip_through_barrier() In-Reply-To: <5109b413-45a6-893f-2264-7eedc1a0e48b@redhat.com> References: <5109b413-45a6-893f-2264-7eedc1a0e48b@redhat.com> Message-ID: <496318c9-dd44-fcb0-b875-e3a7903bd19e@redhat.com> On 4/30/19 3:26 PM, Roman Kennke wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8223144 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8223144/webrev.00/ It looks okay to me. Roland might need to take a look. -Aleksey From shade at redhat.com Tue Apr 30 14:25:56 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 30 Apr 2019 16:25:56 +0200 Subject: RFR(M) 8222992: Shenandoah: Pre-evacuate all roots In-Reply-To: <3cf86adc-6865-0b8a-23bd-c93884d6d456@redhat.com> References: <2f6eeb40-ccf5-9dd8-7ccc-181e993dedf0@redhat.com> <3cf86adc-6865-0b8a-23bd-c93884d6d456@redhat.com> Message-ID: <0f6499ee-7b2e-818d-96f8-2d8787b7a10f@redhat.com> On 4/26/19 3:54 PM, Zhengyu Gu wrote: >> *) There is a plain store in ShenandoahBarrierSet::AccessBarrier> BarrierSetT>::oop_load_not_in_heap. First, I wonder if it even makes sense to do it here -- it feels >> awkward to have writes in "loads". Second, shouldn't that be a CAS, on the off-chance something else >> is storing the another value? > > I think it is a Copy-on-Read semantics, no? I don't think it needs CAS here, since > load-reference-barrier should return to-space oop, and we should only have one to-space copy. Yes, but the issue is different. You have the conflicting stores: a) fwd fixup: A' -> A; b) other store B. What this can do is to store A, overwriting (losing!) the store of B. Rule: the fwd fixups should always be with CAS, unless you guarantee nothing else is writing. -Aleksey From aph at redhat.com Tue Apr 30 15:14:01 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 30 Apr 2019 16:14:01 +0100 Subject: RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2019-04-29 In-Reply-To: <51050c8d-92dd-b0f0-3657-65d91a34fec0@redhat.com> References: <51050c8d-92dd-b0f0-3657-65d91a34fec0@redhat.com> Message-ID: <33f8eac1-c521-4433-8455-32352eb751b5@redhat.com> On 4/29/19 8:14 PM, Roman Kennke wrote: > Short tour of shared-code changes: > - Change in classLoaderStats.cpp introduces a new required+missing > object equals barrier. > - Change in subnode.cpp *reverts* back to orginal upstream code because > of changed object equal barrier in C2. > - arguments.cpp change is in fact in Shenandoah-only path. > > List of changes: > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2019-04-29/changes.txt > > Complete Webrev: > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2019-04-29/webrev-all.00/ Thanks, looks fine. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zgu at redhat.com Tue Apr 30 19:51:20 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 30 Apr 2019 15:51:20 -0400 Subject: RFR(M) 8222992: Shenandoah: Pre-evacuate all roots In-Reply-To: <0f6499ee-7b2e-818d-96f8-2d8787b7a10f@redhat.com> References: <2f6eeb40-ccf5-9dd8-7ccc-181e993dedf0@redhat.com> <3cf86adc-6865-0b8a-23bd-c93884d6d456@redhat.com> <0f6499ee-7b2e-818d-96f8-2d8787b7a10f@redhat.com> Message-ID: <22cabc5f-5116-07da-30f7-854248e1b932@redhat.com> On 4/30/19 10:25 AM, Aleksey Shipilev wrote: > On 4/26/19 3:54 PM, Zhengyu Gu wrote: >>> *) There is a plain store in ShenandoahBarrierSet::AccessBarrier>> BarrierSetT>::oop_load_not_in_heap. First, I wonder if it even makes sense to do it here -- it feels >>> awkward to have writes in "loads". Second, shouldn't that be a CAS, on the off-chance something else >>> is storing the another value? >> >> I think it is a Copy-on-Read semantics, no? I don't think it needs CAS here, since >> load-reference-barrier should return to-space oop, and we should only have one to-space copy. > > Yes, but the issue is different. You have the conflicting stores: a) fwd fixup: A' -> A; b) other > store B. What this can do is to store A, overwriting (losing!) the store of B. Rule: the fwd fixups > should always be with CAS, unless you guarantee nothing else is writing. You are right, I reverted the changes. Also, as you suggested offline, I folded verify roots into shenandoah verifier and added missing roots in ShenandoahRootProcessor::process_all_roots_slow() Updated webrev: http://cr.openjdk.java.net/~zgu/JDK-8222992/webrev.01/index.html Test: hotspot_gc_shenandoah (fastdebug and release) with -XX:+ShenandoahVerify. Thanks, -Zhengyu > > -Aleksey > From erik.osterlund at oracle.com Mon Apr 8 12:57:36 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 08 Apr 2019 12:57:36 -0000 Subject: RFR(T) 8222086: CodeCache::UnloadingScope needs to preserve and restore previous IsUnloadingBehavior In-Reply-To: <4aee03db-ad25-23b9-04a9-1c4c72f7165c@redhat.com> References: <4aee03db-ad25-23b9-04a9-1c4c72f7165c@redhat.com> Message-ID: Hi Zhengyu, Looks good. /Erik On 2019-04-08 02:57, Zhengyu Gu wrote: > Shenandoah can (will) do concurrent class unloading, but also unloads > classes at pauses, e.g. during full gc. > > Currently, CodeCache::UnloadingScope's destructor resets > IsUnloadingBehaviour that is setup for concurrent class unloading, > which results fatal crash during next concurrent unloading cycle. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222086 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8222086/webrev.00/ > > > Test: > ? hotspot_gc on Linux x64 (fastdebug and release) > ? Submit tests. > > Thanks, > > -Zhengyu