From kilyukhin at gmail.com  Mon Jun  1 03:51:37 2020
From: kilyukhin at gmail.com (Kirill Ilyukhin)
Date: Mon, 1 Jun 2020 12:51:37 +0900
Subject: GC duration and pause time grow linearly
Message-ID: <CAB944-pt2V_OP64qW9nKJ6C5cyqZ2PgpD02DxuKacGVoWP4yWA@mail.gmail.com>

Dear Shenandoah developers,

Please look at the attached images, these are charts built by cgeasy.io for
my GC log. GC/pause time grows as if it were a linear function of JVM
uptime. Is this an expected behavior? I am not complaining, performance is
good enough, but GC/pause time trend looks a bit suspicious.

This JVM is a standby instance of Tomcat 9.0.22 as a Windows service, doing
almost nothing. Most of GC are time-triggered, every 5 minutes.
Please let me know if you need more information.

Java:
openjdk version "13-internal" 2019-09-17
OpenJDK Runtime Environment (build 13-internal+0-adhoc..build)
OpenJDK 64-Bit Server VM (build 13-internal+0-adhoc..build, mixed mode,
sharing)

Command line arguments:
-XX:+UseStringDeduplication
-Xlog:gc*,safepoint:file=\logs\gc.%t.log:time,level,tags:filecount=1000,filesize=100M
-XX:+UnlockExperimentalVMOptions
-XX:+UseShenandoahGC
-XX:+AlwaysPreTouch
-Xms1024m
-Xmx1024m

OS:
Windows Server 2008 R2, version 6.2 (build 7601: Service Pack 1)

Thanks a lot,
Kirill


[image: image.png]

[image: image.png]

[image: image.png]

From shade at redhat.com  Mon Jun  1 06:34:38 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Jun 2020 08:34:38 +0200
Subject: GC duration and pause time grow linearly
In-Reply-To: <CAB944-pt2V_OP64qW9nKJ6C5cyqZ2PgpD02DxuKacGVoWP4yWA@mail.gmail.com>
References: <CAB944-pt2V_OP64qW9nKJ6C5cyqZ2PgpD02DxuKacGVoWP4yWA@mail.gmail.com>
Message-ID: <9cdd465b-43d8-71af-4913-0de56ae8e0a0@redhat.com>

On 6/1/20 5:51 AM, Kirill Ilyukhin wrote:
> Please look at the attached images, these are charts built by cgeasy.io for
> my GC log. GC/pause time grows as if it were a linear function of JVM
> uptime. Is this an expected behavior? I am not complaining, performance is
> good enough, but GC/pause time trend looks a bit suspicious.

If application does not change its load profile, then it is not the intended behavior.

> This JVM is a standby instance of Tomcat 9.0.22 as a Windows service, doing
> almost nothing. Most of GC are time-triggered, every 5 minutes.
> Please let me know if you need more information.

Unfortunately, JDK 13 is past its support lifetime. And it lacks the more extensive per-cycle
logging to really follow up on this. Take either 14u or 11u nightlies?

> [image: image.png]
> [image: image.png]
> [image: image.png]

Attachments are stripped on this list, please post URLs to somewhere else? Verbatim GC logs would be
even better, from either 14u or 11u nightlies.

-- 
Thanks,
-Aleksey


From kilyukhin at gmail.com  Mon Jun  1 07:16:00 2020
From: kilyukhin at gmail.com (Kirill Ilyukhin)
Date: Mon, 1 Jun 2020 16:16:00 +0900
Subject: GC duration and pause time grow linearly
In-Reply-To: <9cdd465b-43d8-71af-4913-0de56ae8e0a0@redhat.com>
References: <CAB944-pt2V_OP64qW9nKJ6C5cyqZ2PgpD02DxuKacGVoWP4yWA@mail.gmail.com>
 <9cdd465b-43d8-71af-4913-0de56ae8e0a0@redhat.com>
Message-ID: <CAB944-oUGBWsNcnAfHgrLVcYasGJK-3cacJ0+CJg76ux8oTfjQ@mail.gmail.com>

Aleksey,

Understood about JDK 13. Will try updating to 14u, but it is going to take
a month or two to get the data because CG/Pause time grows very slowly.

Please try the URL below, this is gceasy.io report I was referring to.
https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMjAvMDYvMS8tLWdjLnN3MTIubG9nLmd6LS02LTU5LTI3&channel=WEB

Thank you,
Kirill

On Mon, 1 Jun 2020 at 15:34, Aleksey Shipilev <shade at redhat.com> wrote:

> On 6/1/20 5:51 AM, Kirill Ilyukhin wrote:
> > Please look at the attached images, these are charts built by cgeasy.io
> for
> > my GC log. GC/pause time grows as if it were a linear function of JVM
> > uptime. Is this an expected behavior? I am not complaining, performance
> is
> > good enough, but GC/pause time trend looks a bit suspicious.
>
> If application does not change its load profile, then it is not the
> intended behavior.
>
> > This JVM is a standby instance of Tomcat 9.0.22 as a Windows service,
> doing
> > almost nothing. Most of GC are time-triggered, every 5 minutes.
> > Please let me know if you need more information.
>
> Unfortunately, JDK 13 is past its support lifetime. And it lacks the more
> extensive per-cycle
> logging to really follow up on this. Take either 14u or 11u nightlies?
>
> > [image: image.png]
> > [image: image.png]
> > [image: image.png]
>
> Attachments are stripped on this list, please post URLs to somewhere else?
> Verbatim GC logs would be
> even better, from either 14u or 11u nightlies.
>
> --
> Thanks,
> -Aleksey
>
>

From shade at redhat.com  Mon Jun  1 08:33:03 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Jun 2020 10:33:03 +0200
Subject: GC duration and pause time grow linearly
In-Reply-To: <CAB944-oUGBWsNcnAfHgrLVcYasGJK-3cacJ0+CJg76ux8oTfjQ@mail.gmail.com>
References: <CAB944-pt2V_OP64qW9nKJ6C5cyqZ2PgpD02DxuKacGVoWP4yWA@mail.gmail.com>
 <9cdd465b-43d8-71af-4913-0de56ae8e0a0@redhat.com>
 <CAB944-oUGBWsNcnAfHgrLVcYasGJK-3cacJ0+CJg76ux8oTfjQ@mail.gmail.com>
Message-ID: <db772131-3e29-ad66-76ff-f6a022c0d72c@redhat.com>

On 6/1/20 9:16 AM, Kirill Ilyukhin wrote:
> Understood about JDK 13. Will try updating to 14u, but it is going to take a month?or two to get the
> data because CG/Pause time grows very slowly.

If you have a staging environment for experiments, forcing back-to-back GCs with
-XX:ShenandoahGCHeuristics=aggressive might be interesting to stress out the workload without
waiting for months.

14u nightlies (targeting 14.0.2 to be released in July) have the verbose per-cycle logging (enabled
with -Xlog:gc+stats), and that should point to the which work actually goes up and up:
  https://builds.shipilev.net/openjdk-jdk14/

> Please try the URL below, this is gceasy.io <http://gceasy.io> report I was referring to.
> https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMjAvMDYvMS8tLWdjLnN3MTIubG9nLmd6LS02LTU5LTI3&channel=WEB

Thanks! It is weird to see most pauses growing. Something is definitely off.

-- 
-Aleksey


From rkennke at redhat.com  Mon Jun  1 08:40:39 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 1 Jun 2020 10:40:39 +0200
Subject: GC duration and pause time grow linearly
In-Reply-To: <db772131-3e29-ad66-76ff-f6a022c0d72c@redhat.com>
References: <CAB944-pt2V_OP64qW9nKJ6C5cyqZ2PgpD02DxuKacGVoWP4yWA@mail.gmail.com>
 <9cdd465b-43d8-71af-4913-0de56ae8e0a0@redhat.com>
 <CAB944-oUGBWsNcnAfHgrLVcYasGJK-3cacJ0+CJg76ux8oTfjQ@mail.gmail.com>
 <db772131-3e29-ad66-76ff-f6a022c0d72c@redhat.com>
Message-ID: <CAAN-KyjthbnCNF83QV=9+ZTA+4U05gdgBEXmnzmQgBV4kwtGzA@mail.gmail.com>

Could be -ClassUnloading biting because it keeps piling up
Classes/ClassLoaders.

Roman

Aleksey Shipilev <shade at redhat.com> schrieb am Mo., 1. Juni 2020, 10:34:

> On 6/1/20 9:16 AM, Kirill Ilyukhin wrote:
> > Understood about JDK 13. Will try updating to 14u, but it is going to
> take a month or two to get the
> > data because CG/Pause time grows very slowly.
>
> If you have a staging environment for experiments, forcing back-to-back
> GCs with
> -XX:ShenandoahGCHeuristics=aggressive might be interesting to stress out
> the workload without
> waiting for months.
>
> 14u nightlies (targeting 14.0.2 to be released in July) have the verbose
> per-cycle logging (enabled
> with -Xlog:gc+stats), and that should point to the which work actually
> goes up and up:
>   https://builds.shipilev.net/openjdk-jdk14/
>
> > Please try the URL below, this is gceasy.io <http://gceasy.io> report I
> was referring to.
> >
> https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMjAvMDYvMS8tLWdjLnN3MTIubG9nLmd6LS02LTU5LTI3&channel=WEB
>
> Thanks! It is weird to see most pauses growing. Something is definitely
> off.
>
> --
> -Aleksey
>
>

From shade at redhat.com  Mon Jun  1 10:24:57 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Jun 2020 12:24:57 +0200
Subject: RFR (S) 8246100: Shenandoah: walk roots in more efficient order
Message-ID: <4a733745-6f94-b6aa-b8c9-8daedace22f2@redhat.com>

RFE:
  https://bugs.openjdk.java.net/browse/JDK-8246100

See the rationale in the RFE.

Webrev:
  https://cr.openjdk.java.net/~shade/8246100/webrev.02/

Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Jun  1 10:38:44 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Jun 2020 12:38:44 +0200
Subject: RFR (S) 8246097: Shenandoah: limit parallelism in CLDG root handling
Message-ID: <31edeb90-b199-0ba2-e782-c38792d3bb4c@redhat.com>

RFE:
  https://bugs.openjdk.java.net/browse/JDK-8246097

See the details in the RFE.

Webrev:
  https://cr.openjdk.java.net/~shade/8246097/webrev.02/

Testing: hotspot_gc_shenandoah, benchmarks.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Jun  1 13:28:46 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Jun 2020 15:28:46 +0200
Subject: RFC: Instrumentation to Help Understand Shenandoah Performance
 and Latency
In-Reply-To: <35BE8496-E5D7-420D-8E90-2C7A099A162C@amazon.com>
References: <35BE8496-E5D7-420D-8E90-2C7A099A162C@amazon.com>
Message-ID: <09a3b64b-9ffa-c697-1add-1bfe0ca2a4e7@redhat.com>

Hi,

On 5/27/20 10:15 PM, Nilsen, Kelvin wrote:
> 1. Number of GC pacing pauses imposed on thread 
> 2. Total number of accumulated ms of pacing pauses imposed on thread A

These are not available, but doable. You can hack it in the current source like this:
  http://cr.openjdk.java.net/~shade/shenandoah/pacing-stats.patch

That thing is probably doable for product configuration, as it is not on performance-sensitive path.
I'll try to massage it in.

> 3. ?Number of "slow" paths taken through the reference load barrier for thread A.
> Of these: a) How many required thread A to copy the referenced object?> b) How many total bytes of data were copied?
> c) How many times did thread A have to abandon its copy of the referenced object?
> d) How many total bytes of data were abandoned?

These are not available, but doable. LRB slowpath is quite performance-sensitive, so I would be
cautious to introduce accidental bottlenecks there. The counters above do not seem too intrusive,
though. Any LRB slowpath counter that involves timestamps would be a no-go.

> 4. Can my application thread "know" about transitions between GC phases? > Would be nice if a thread could ask :
> a) What is the sequence number of the most recently initiated GC cycle? 
> b) What is the current phase of GC within this cycle?

These require more thorough hacking in through JMX. I believe at some point the hassle of pushing
the data across to Java level would not pay off for the small observability benefits it gives. This
one seems a bit over that arbitrary line.

> For my purposes, these metrics are primarily for use during "research" on performance of
> particular workloads and of particular alternative GC implementation approaches.  I would
> personally be satisfied if these metrics were only available in a JVM that is compiled "with
> instrumentation".  Whether it might be appropriate to deploy "production releases" with this
> instrumentation in place would depend on how much performance overhead it incurs.

Technically, there is the "optimized" build configuration that compiles like "release", but enables
the block of code protected by OPTIMIZED macro. But, I have doubts we want to support yet another
build configuration. The counters that are not available in release VMs are known to bit-rot very
quickly.

So it seems to me there are realistically two types of counters we should be doing:
  a) Those we can make arbitrarily low-overhead, especially when disabled with runtime flag;
  b) Those we can only make as self-patched/self-built VM;

> I am suggesting that these metrics might be gathered on a per-thread basis to reduce
> synchronization overheads.  The results of individual threads can be accumulated by user code
> when desired.  Each thread accumulates its thread-local data into a global accumulator, using
> synchronization to coordinate access to the global accumulator.

See the patch above, that's almost exactly how our usual hacks work.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Jun  1 18:12:43 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 1 Jun 2020 20:12:43 +0200
Subject: [8] RFR: Move barrier sets to their proper locations
In-Reply-To: <d39b61295169a2a0b73d2eb950545b8e576d93ec.camel@redhat.com>
References: <ac90ffce-f0db-7030-1241-776da594659e@redhat.com>
 <d39b61295169a2a0b73d2eb950545b8e576d93ec.camel@redhat.com>
Message-ID: <1723f979-7989-ac81-86d6-485301e53e54@redhat.com>

On 5/20/20 5:56 PM, Roman Kennke wrote:
> Ok. I was wondering the same for a while, but always assumed we'd need
> build-machinery changes to pick up stuff under subdirectories.

You know what? You are right, we need to do special things for Windows and Minimal VM:
  https://cr.openjdk.java.net/~shade/shenandoah/8u-move-sbs/webrev.02/

...like we did here:
  https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/4fd7bc699d62

Testing: Linux, Windows builds

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Mon Jun  1 18:23:15 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 1 Jun 2020 14:23:15 -0400
Subject: [15] RFR 8245961: Shenandoah: move some root marking to concurrent
 phase
Message-ID: <61efdf04-5d74-8a59-a193-576b115738ef@redhat.com>

Please review this patch that moves following root scanning to 
concurrent phase.

1) JNIHandle roots
2) VM global roots
3) CLD roots

and also consolidates code cache root marking.


Bug: https://bugs.openjdk.java.net/browse/JDK-8245961
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245961/webrev.00/

Test:
   hotspot_gc_shenandoah

Thanks,

-Zhengyu


From zgu at redhat.com  Mon Jun  1 19:03:47 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 1 Jun 2020 15:03:47 -0400
Subject: RFR (S) 8246100: Shenandoah: walk roots in more efficient order
In-Reply-To: <4a733745-6f94-b6aa-b8c9-8daedace22f2@redhat.com>
References: <4a733745-6f94-b6aa-b8c9-8daedace22f2@redhat.com>
Message-ID: <3a8331ad-9ec1-dda9-058d-6edcdd594e4d@redhat.com>

Looks good in general. But not sure why call vm/weak/dedup roots limited 
parallel, I think they are fully parallel.

-Zhengyu

On 6/1/20 6:24 AM, Aleksey Shipilev wrote:
> RFE:
>    https://bugs.openjdk.java.net/browse/JDK-8246100
> 
> See the rationale in the RFE.
> 
> Webrev:
>    https://cr.openjdk.java.net/~shade/8246100/webrev.02/
> 
> Testing: hotspot_gc_shenandoah
> 


From zgu at redhat.com  Mon Jun  1 19:26:43 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 1 Jun 2020 15:26:43 -0400
Subject: RFR (S) 8246100: Shenandoah: walk roots in more efficient order
In-Reply-To: <3a8331ad-9ec1-dda9-058d-6edcdd594e4d@redhat.com>
References: <4a733745-6f94-b6aa-b8c9-8daedace22f2@redhat.com>
 <3a8331ad-9ec1-dda9-058d-6edcdd594e4d@redhat.com>
Message-ID: <f774ec7b-22a3-b8ee-3541-8a6f6c476ede@redhat.com>

Wait, should we process CLDG early? CLD likely uneven, e.g. boot class 
loader may take a lot longer than others.

Thanks,

-Zhengyu

On 6/1/20 3:03 PM, Zhengyu Gu wrote:
> Looks good in general. But not sure why call vm/weak/dedup roots limited 
> parallel, I think they are fully parallel.
> 
> -Zhengyu
> 
> On 6/1/20 6:24 AM, Aleksey Shipilev wrote:
>> RFE:
>> ?? https://bugs.openjdk.java.net/browse/JDK-8246100
>>
>> See the rationale in the RFE.
>>
>> Webrev:
>> ?? https://cr.openjdk.java.net/~shade/8246100/webrev.02/
>>
>> Testing: hotspot_gc_shenandoah
>>


From shade at redhat.com  Tue Jun  2 09:49:29 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 2 Jun 2020 11:49:29 +0200
Subject: [15] RFR 8245961: Shenandoah: move some root marking to
 concurrent phase
In-Reply-To: <61efdf04-5d74-8a59-a193-576b115738ef@redhat.com>
References: <61efdf04-5d74-8a59-a193-576b115738ef@redhat.com>
Message-ID: <ef70f68f-c69c-f18e-c510-192c285fabf7@redhat.com>

On 6/1/20 8:23 PM, Zhengyu Gu wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8245961
> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245961/webrev.00/

Let me push 8246097 and 8246100 before this, so we would have the backport base.

Mostly stylistic nits follow:

*) Does it make sense to move ShenandoahConcurrentRootsIterator to shenandoahRootProcessor? And do
something like ShenandoahConcurrentRootScanner?

*) conc_mark_roots can be just "  Concurrent Roots", no need to duplicate "Concurrent Mark":

  70   f(conc_mark,                                      "Concurrent Marking")              \
  71   f(conc_mark_roots,                                "  Concurrent Mark Roots ")        \
  72   SHENANDOAH_PAR_PHASE_DO(conc_mark_roots,          "    CM: ", f)                     \

*) Typo: "Concurrnet":

 145   f(full_gc_scan_conc_roots,                        "  Scan Concurrnet Roots")         \


-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Jun  2 09:52:37 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 2 Jun 2020 11:52:37 +0200
Subject: RFR (S) 8246100: Shenandoah: walk roots in more efficient order
In-Reply-To: <f774ec7b-22a3-b8ee-3541-8a6f6c476ede@redhat.com>
References: <4a733745-6f94-b6aa-b8c9-8daedace22f2@redhat.com>
 <3a8331ad-9ec1-dda9-058d-6edcdd594e4d@redhat.com>
 <f774ec7b-22a3-b8ee-3541-8a6f6c476ede@redhat.com>
Message-ID: <7945aaf1-da2c-83ef-44d5-caf34e7ed607@redhat.com>

On 6/1/20 9:26 PM, Zhengyu Gu wrote:
> Wait, should we process CLDG early? CLD likely uneven, e.g. boot class 
> loader may take a lot longer than others.

It is not uneven in my tests. But even if it is, we want to do CLDG before thread/code roots, which
is what the patch does. With 8246097, it would be moved to the "lightweight/limited" block before.

> On 6/1/20 3:03 PM, Zhengyu Gu wrote:
>> Looks good in general. But not sure why call vm/weak/dedup roots limited 
>> parallel, I think they are fully parallel.

Yes. But they are also lightweight, that's what block does: both lightweight or limited-parallel.

>>> Webrev:
>>> ?? https://cr.openjdk.java.net/~shade/8246100/webrev.02/

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Jun  2 10:34:05 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 2 Jun 2020 12:34:05 +0200
Subject: [11] 2020-05-28: Bulk backports to sh/jdk11
Message-ID: <1e837455-f174-b820-41aa-519cdc9a5fbe@redhat.com>

https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200602/webrev.01/

This backports a few easy leftovers to sh/jdk11:
 [backport] 8246162: Shenandoah: full GC does not mark code roots when class unloading is off
 [backport] 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits
 [backport] 8245464: Shenandoah: allocate collection set bitmap at lower addresses
 [backport] 8245773: Shenandoah: Windows assertion failure after JDK-8245464
 [backport] 8245465: Shenandoah: test_in_cset can use more efficient encoding

Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Jun  2 11:04:38 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 2 Jun 2020 13:04:38 +0200
Subject: [8] Shenandoah: Fix build failure with +JFR -PCH
Message-ID: <2befc151-53e5-2998-6be2-53866f68f58d@redhat.com>

Hi,

Current sh/jdk8 build fails if configured --enable-jfr and --disable-precompiled-headers like this:

In file included from
/home/shade/trunks/shenandoah-jdk8/hotspot/src/share/vm/jfr/instrumentation/jfrJvmtiAgent.cpp:29:0:
/home/shade/trunks/shenandoah-jdk8/hotspot/src/share/vm/jfr/jni/jfrUpcalls.hpp:57:10: error:
?instanceKlassHandle? does not name a type; did you mean ?InstanceKlass??
   static instanceKlassHandle load_event_handler_proxy_class(TRAPS);
          ^~~~~~~~~~~~~~~~~~~
          InstanceKlass

I notice we already have this upstream difference in os.hpp that unties the header circularity:

--- old/src/share/vm/runtime/os.hpp	2020-06-02 01:08:37.190316031 +0200
+++ new/src/share/vm/runtime/os.hpp	2020-06-02 01:08:37.110316134 +0200
@@ -28,7 +28,6 @@
 #include "jvmtifiles/jvmti.h"
 #include "runtime/atomic.hpp"
 #include "runtime/extendedPC.hpp"
-#include "runtime/handles.hpp"
 #include "utilities/top.hpp"
 #ifdef TARGET_OS_FAMILY_linux
 # include "jvm_linux.h"
@@ -54,6 +53,7 @@
 #endif

 class AgentLibrary;
+class methodHandle;

I tried to revert that block and solve it by rearranging Shenandoah includes a bit, but to no avail.
So, this is my plan B that seems to solve the build failure:

diff -r 4439a43801a4 src/share/vm/runtime/os.hpp
--- a/src/share/vm/runtime/os.hpp       Mon Jun 01 19:14:49 2020 +0200
+++ b/src/share/vm/runtime/os.hpp       Tue Jun 02 11:17:51 2020 +0200
@@ -52,10 +52,11 @@
 # endif
 #endif

 class AgentLibrary;
 class methodHandle;
+class instanceKlassHandle;

 // os defines the interface to operating system; this includes traditional
 // OS services (time, I/O) as well as other functionality with system-
 // dependent code.

Testing: Linux x86_64 builds with {+JFR, -JFR} x {+PCH, -PCH} x {release, fastdebug, slowdebug}

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Tue Jun  2 11:22:02 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 2 Jun 2020 07:22:02 -0400
Subject: RFR (S) 8246100: Shenandoah: walk roots in more efficient order
In-Reply-To: <7945aaf1-da2c-83ef-44d5-caf34e7ed607@redhat.com>
References: <4a733745-6f94-b6aa-b8c9-8daedace22f2@redhat.com>
 <3a8331ad-9ec1-dda9-058d-6edcdd594e4d@redhat.com>
 <f774ec7b-22a3-b8ee-3541-8a6f6c476ede@redhat.com>
 <7945aaf1-da2c-83ef-44d5-caf34e7ed607@redhat.com>
Message-ID: <77219dc7-6dfe-9f45-61d1-20b5da789237@redhat.com>



On 6/2/20 5:52 AM, Aleksey Shipilev wrote:
> On 6/1/20 9:26 PM, Zhengyu Gu wrote:
>> Wait, should we process CLDG early? CLD likely uneven, e.g. boot class
>> loader may take a lot longer than others.
> 
> It is not uneven in my tests. But even if it is, we want to do CLDG before thread/code roots, which
> is what the patch does. With 8246097, it would be moved to the "lightweight/limited" block before.
> 
>> On 6/1/20 3:03 PM, Zhengyu Gu wrote:
>>> Looks good in general. But not sure why call vm/weak/dedup roots limited
>>> parallel, I think they are fully parallel.
> 
> Yes. But they are also lightweight, that's what block does: both lightweight or limited-parallel.
> 

Okay, then.

-Zhengyu

>>>> Webrev:
>>>>  ?? https://cr.openjdk.java.net/~shade/8246100/webrev.02/
> 


From zgu at redhat.com  Tue Jun  2 11:28:08 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 2 Jun 2020 07:28:08 -0400
Subject: [11] 2020-05-28: Bulk backports to sh/jdk11
In-Reply-To: <1e837455-f174-b820-41aa-519cdc9a5fbe@redhat.com>
References: <1e837455-f174-b820-41aa-519cdc9a5fbe@redhat.com>
Message-ID: <f34fdac6-af5c-72d7-a64e-c0927bb81e87@redhat.com>

Okay.

-Zhengyu

On 6/2/20 6:34 AM, Aleksey Shipilev wrote:
> https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200602/webrev.01/
> 
> This backports a few easy leftovers to sh/jdk11:
>   [backport] 8246162: Shenandoah: full GC does not mark code roots when class unloading is off
>   [backport] 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits
>   [backport] 8245464: Shenandoah: allocate collection set bitmap at lower addresses
>   [backport] 8245773: Shenandoah: Windows assertion failure after JDK-8245464
>   [backport] 8245465: Shenandoah: test_in_cset can use more efficient encoding
> 
> Testing: hotspot_gc_shenandoah
> 


From shade at redhat.com  Tue Jun  2 11:54:47 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 2 Jun 2020 13:54:47 +0200
Subject: [11] 2020-05-28: Bulk backports to sh/jdk11
In-Reply-To: <f34fdac6-af5c-72d7-a64e-c0927bb81e87@redhat.com>
References: <1e837455-f174-b820-41aa-519cdc9a5fbe@redhat.com>
 <f34fdac6-af5c-72d7-a64e-c0927bb81e87@redhat.com>
Message-ID: <77d6637d-6122-e5c4-fc3b-ed53c3600555@redhat.com>

On 6/2/20 1:28 PM, Zhengyu Gu wrote:
> Okay.

Thanks, pushed.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Jun  2 11:54:41 2020
From: shade at redhat.com (shade at redhat.com)
Date: Tue, 02 Jun 2020 11:54:41 +0000
Subject: hg: shenandoah/jdk11: 5 new changesets
Message-ID: <202006021154.052Bsg1i005229@aojmv0008.oracle.com>

Changeset: c9f5c3a4ff0d
Author:    zgu
Date:      2020-05-29 13:44 -0400
URL:       https://hg.openjdk.java.net/shenandoah/jdk11/rev/c9f5c3a4ff0d

[backport] 8246162: Shenandoah: full GC does not mark code roots when class unloading is off
Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp

Changeset: 04abcd953200
Author:    shade
Date:      2020-05-26 09:31 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk11/rev/04abcd953200

[backport] 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits
Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp

Changeset: 581f98731824
Author:    shade
Date:      2020-05-25 11:05 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk11/rev/581f98731824

[backport] 8245464: Shenandoah: allocate collection set bitmap at lower addresses
Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp

Changeset: 1d7bad3b4490
Author:    shade
Date:      2020-05-26 13:07 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk11/rev/1d7bad3b4490

[backport] 8245773: Shenandoah: Windows assertion failure after JDK-8245464
Reviewed-by: stuefe

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 9ca146482229
Author:    shade
Date:      2020-05-25 11:05 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk11/rev/9ca146482229

[backport] 8245465: Shenandoah: test_in_cset can use more efficient encoding
Reviewed-by: rkennke, roland

! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp


From zgu at redhat.com  Tue Jun  2 12:44:23 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 2 Jun 2020 08:44:23 -0400
Subject: RFR (S) 8246097: Shenandoah: limit parallelism in CLDG root
 handling
In-Reply-To: <31edeb90-b199-0ba2-e782-c38792d3bb4c@redhat.com>
References: <31edeb90-b199-0ba2-e782-c38792d3bb4c@redhat.com>
Message-ID: <819d513f-ad38-7287-6e0a-dfbbf0f179db@redhat.com>

Looks good.

-Zhengyu

On 6/1/20 6:38 AM, Aleksey Shipilev wrote:
> RFE:
>    https://bugs.openjdk.java.net/browse/JDK-8246097
> 
> See the details in the RFE.
> 
> Webrev:
>    https://cr.openjdk.java.net/~shade/8246097/webrev.02/
> 
> Testing: hotspot_gc_shenandoah, benchmarks.
> 


From zgu at redhat.com  Tue Jun  2 13:12:41 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 2 Jun 2020 09:12:41 -0400
Subject: [15] RFR 8245961: Shenandoah: move some root marking to
 concurrent phase
In-Reply-To: <ef70f68f-c69c-f18e-c510-192c285fabf7@redhat.com>
References: <61efdf04-5d74-8a59-a193-576b115738ef@redhat.com>
 <ef70f68f-c69c-f18e-c510-192c285fabf7@redhat.com>
Message-ID: <5b7385d8-8b08-fd52-4ef0-d846fc0c3e11@redhat.com>



On 6/2/20 5:49 AM, Aleksey Shipilev wrote:
> On 6/1/20 8:23 PM, Zhengyu Gu wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245961
>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245961/webrev.00/
> 
> Let me push 8246097 and 8246100 before this, so we would have the backport base.
Sure.

> 
> Mostly stylistic nits follow:
> 
> *) Does it make sense to move ShenandoahConcurrentRootsIterator to shenandoahRootProcessor? And do
> something like ShenandoahConcurrentRootScanner?

Okay.

> 
> *) conc_mark_roots can be just "  Concurrent Roots", no need to duplicate "Concurrent Mark":
> 
>    70   f(conc_mark,                                      "Concurrent Marking")              \
>    71   f(conc_mark_roots,                                "  Concurrent Mark Roots ")        \
>    72   SHENANDOAH_PAR_PHASE_DO(conc_mark_roots,          "    CM: ", f)                     \
> 

Fixed
> *) Typo: "Concurrnet":
> 
>   145   f(full_gc_scan_conc_roots,                        "  Scan Concurrnet Roots")         \
> 
Fixed.

http://cr.openjdk.java.net/~zgu/JDK-8245961/webrev.01/index.html


Thanks,

-Zhengyu
> 


From shade at redhat.com  Tue Jun  2 13:34:45 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 2 Jun 2020 15:34:45 +0200
Subject: RFR (S) 8246097: Shenandoah: limit parallelism in CLDG root
 handling
In-Reply-To: <819d513f-ad38-7287-6e0a-dfbbf0f179db@redhat.com>
References: <31edeb90-b199-0ba2-e782-c38792d3bb4c@redhat.com>
 <819d513f-ad38-7287-6e0a-dfbbf0f179db@redhat.com>
Message-ID: <a74e2c1d-4056-0929-dc03-e3e4e67eaa65@redhat.com>

On 6/2/20 2:44 PM, Zhengyu Gu wrote:
> Looks good.

Thanks, pushed.

-- 
-Aleksey


From shade at redhat.com  Tue Jun  2 14:13:43 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 2 Jun 2020 16:13:43 +0200
Subject: [15] RFR 8245961: Shenandoah: move some root marking to
 concurrent phase
In-Reply-To: <5b7385d8-8b08-fd52-4ef0-d846fc0c3e11@redhat.com>
References: <61efdf04-5d74-8a59-a193-576b115738ef@redhat.com>
 <ef70f68f-c69c-f18e-c510-192c285fabf7@redhat.com>
 <5b7385d8-8b08-fd52-4ef0-d846fc0c3e11@redhat.com>
Message-ID: <06e40ce2-9f0d-e90a-8929-9600c3bbf4c5@redhat.com>

On 6/2/20 3:12 PM, Zhengyu Gu wrote:
> http://cr.openjdk.java.net/~zgu/JDK-8245961/webrev.01/index.html

Looks OK. A few more minor nits (after rebasing to jdk/jdk):
  https://cr.openjdk.java.net/~shade/shenandoah/8245961-shade-updates.patch

Does it pass hotspot_gc_shenandoah?

Just got a failure while testing a patch above. Shouldn't we also except the newly handled
concurrent roots from this verification?

#  Internal Error
(/home/shade/trunks/jdk-jdk/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:943), pid=14874,
tid=14881
#  Error: Verify Roots; Should not be forwarded

Referenced from:
  interior location: 0x00007fb898447a18
  outside of Java heap
  0x00007fb898447a18 is at entry_point+440 in (nmethod*)0x00007fb898447690

Object:
  0x00000000c0304350 - klass 0x000000080008bbf8 jdk.internal.loader.ClassLoaders$AppClassLoader
    not allocated after mark start
        marked
        in collection set
  mark: marked(0x00000000fff80003)
  region: |    6|CS |BTE     c0300000,     c0380000,     c0380000|TAMS     c0380000|UWM
c0380000|U   512K|T   494K|G     0B|S 17472B|L 17472B|CP   0

Forwardee:
  0x00000000fff80000 - klass 0x000000080008bbf8 jdk.internal.loader.ClassLoaders$AppClassLoader
        allocated after mark start
        marked
    not in collection set
  mark: mark(is_neutral hash=0x000000000c387f44 age=0)
  region: | 2047|R  |BTE     fff80000,    100000000,    100000000|TAMS     fff80000|UWM
100000000|U   512K|T     0B|G   512K|S     0B|L     0B|CP   0

Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V  [libjvm.so+0x17246ee]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*,
Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x37e
V  [libjvm.so+0x17253ff]  VMError::report_and_die(Thread*, void*, char const*, int, char const*,
char const*, __va_list_tag*)+0x2f
V  [libjvm.so+0x8c8301]  report_vm_error(char const*, int, char const*, char const*, ...)+0x111
V  [libjvm.so+0x1420dbd]  ShenandoahAsserts::print_failure(ShenandoahAsserts::SafeLevel, oop, void*,
oop, char const*, char const*, char const*, int)+0x3ed
V  [libjvm.so+0x150fe53]  ShenandoahVerifyNoForwared::do_oop(oop*)+0xa3
V  [libjvm.so+0x11fe150]  nmethod::oops_do(OopClosure*, bool)+0x120
V  [libjvm.so+0xc41907]  CodeBlobToOopClosure::do_code_blob(CodeBlob*)+0x37
V  [libjvm.so+0x16576d7]  JavaThread::oops_do(OopClosure*, CodeBlobClosure*)+0x187
V  [libjvm.so+0x1662dab]  Threads::possibly_parallel_oops_do(bool, OopClosure*, CodeBlobClosure*)+0x7b
V  [libjvm.so+0x14e7730]  ShenandoahRootVerifier::oops_do(OopClosure*)+0x290
V  [libjvm.so+0x150e171]
ShenandoahVerifier::verify_roots_no_forwarded_except(ShenandoahRootVerifier::RootTypes)+0x41
V  [libjvm.so+0x149d1e0]  ShenandoahHeap::op_final_mark()+0x4e0
V  [libjvm.so+0x149d85f]  ShenandoahHeap::entry_final_mark()+0xbf
V  [libjvm.so+0x150dd54]  VM_ShenandoahFinalMarkStartEvac::doit()+0x34
V  [libjvm.so+0x172683d]  VM_Operation::evaluate()+0x1cd
V  [libjvm.so+0x175562b]  VMThread::evaluate_operation(VM_Operation*) [clone .constprop.71]+0x13b
V  [libjvm.so+0x175606d]  VMThread::loop()+0x7bd
V  [libjvm.so+0x17564ba]  VMThread::run()+0xca
V  [libjvm.so+0x1664616]  Thread::call_run()+0xf6
V  [libjvm.so+0x12907de]  thread_native_entry(Thread*)+0x10e



-- 
Thanks,
-Aleksey


From zgu at redhat.com  Tue Jun  2 17:50:50 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 2 Jun 2020 13:50:50 -0400
Subject: [15] RFR 8245961: Shenandoah: move some root marking to
 concurrent phase
In-Reply-To: <06e40ce2-9f0d-e90a-8929-9600c3bbf4c5@redhat.com>
References: <61efdf04-5d74-8a59-a193-576b115738ef@redhat.com>
 <ef70f68f-c69c-f18e-c510-192c285fabf7@redhat.com>
 <5b7385d8-8b08-fd52-4ef0-d846fc0c3e11@redhat.com>
 <06e40ce2-9f0d-e90a-8929-9600c3bbf4c5@redhat.com>
Message-ID: <57228404-acb5-9537-caef-35919cbff493@redhat.com>



On 6/2/20 10:13 AM, Aleksey Shipilev wrote:
> On 6/2/20 3:12 PM, Zhengyu Gu wrote:
>> http://cr.openjdk.java.net/~zgu/JDK-8245961/webrev.01/index.html
> 
> Looks OK. A few more minor nits (after rebasing to jdk/jdk):
>    https://cr.openjdk.java.net/~shade/shenandoah/8245961-shade-updates.patch

Rebased webrev.01 to jdk/jdk and manually folded some of your suggested 
changes:

http://cr.openjdk.java.net/~zgu/JDK-8245961/webrev.02/

Test:
   hotspot_gc_shenandoah (with +ShenandoahVerify), all clear.

Thanks,

-Zhengyu

> 
> Does it pass hotspot_gc_shenandoah?
> 
> Just got a failure while testing a patch above. Shouldn't we also except the newly handled
> concurrent roots from this verification?
> 
> #  Internal Error
> (/home/shade/trunks/jdk-jdk/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:943), pid=14874,
> tid=14881
> #  Error: Verify Roots; Should not be forwarded
> 
> Referenced from:
>    interior location: 0x00007fb898447a18
>    outside of Java heap
>    0x00007fb898447a18 is at entry_point+440 in (nmethod*)0x00007fb898447690
> 
> Object:
>    0x00000000c0304350 - klass 0x000000080008bbf8 jdk.internal.loader.ClassLoaders$AppClassLoader
>      not allocated after mark start
>          marked
>          in collection set
>    mark: marked(0x00000000fff80003)
>    region: |    6|CS |BTE     c0300000,     c0380000,     c0380000|TAMS     c0380000|UWM
> c0380000|U   512K|T   494K|G     0B|S 17472B|L 17472B|CP   0
> 
> Forwardee:
>    0x00000000fff80000 - klass 0x000000080008bbf8 jdk.internal.loader.ClassLoaders$AppClassLoader
>          allocated after mark start
>          marked
>      not in collection set
>    mark: mark(is_neutral hash=0x000000000c387f44 age=0)
>    region: | 2047|R  |BTE     fff80000,    100000000,    100000000|TAMS     fff80000|UWM
> 100000000|U   512K|T     0B|G   512K|S     0B|L     0B|CP   0
> 
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V  [libjvm.so+0x17246ee]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*,
> Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x37e
> V  [libjvm.so+0x17253ff]  VMError::report_and_die(Thread*, void*, char const*, int, char const*,
> char const*, __va_list_tag*)+0x2f
> V  [libjvm.so+0x8c8301]  report_vm_error(char const*, int, char const*, char const*, ...)+0x111
> V  [libjvm.so+0x1420dbd]  ShenandoahAsserts::print_failure(ShenandoahAsserts::SafeLevel, oop, void*,
> oop, char const*, char const*, char const*, int)+0x3ed
> V  [libjvm.so+0x150fe53]  ShenandoahVerifyNoForwared::do_oop(oop*)+0xa3
> V  [libjvm.so+0x11fe150]  nmethod::oops_do(OopClosure*, bool)+0x120
> V  [libjvm.so+0xc41907]  CodeBlobToOopClosure::do_code_blob(CodeBlob*)+0x37
> V  [libjvm.so+0x16576d7]  JavaThread::oops_do(OopClosure*, CodeBlobClosure*)+0x187
> V  [libjvm.so+0x1662dab]  Threads::possibly_parallel_oops_do(bool, OopClosure*, CodeBlobClosure*)+0x7b
> V  [libjvm.so+0x14e7730]  ShenandoahRootVerifier::oops_do(OopClosure*)+0x290
> V  [libjvm.so+0x150e171]
> ShenandoahVerifier::verify_roots_no_forwarded_except(ShenandoahRootVerifier::RootTypes)+0x41
> V  [libjvm.so+0x149d1e0]  ShenandoahHeap::op_final_mark()+0x4e0
> V  [libjvm.so+0x149d85f]  ShenandoahHeap::entry_final_mark()+0xbf
> V  [libjvm.so+0x150dd54]  VM_ShenandoahFinalMarkStartEvac::doit()+0x34
> V  [libjvm.so+0x172683d]  VM_Operation::evaluate()+0x1cd
> V  [libjvm.so+0x175562b]  VMThread::evaluate_operation(VM_Operation*) [clone .constprop.71]+0x13b
> V  [libjvm.so+0x175606d]  VMThread::loop()+0x7bd
> V  [libjvm.so+0x17564ba]  VMThread::run()+0xca
> V  [libjvm.so+0x1664616]  Thread::call_run()+0xf6
> V  [libjvm.so+0x12907de]  thread_native_entry(Thread*)+0x10e
> 
> 
> 


From zgu at redhat.com  Tue Jun  2 18:24:19 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 2 Jun 2020 14:24:19 -0400
Subject: [15] RFR(T) 8246342: Shenandoah: remove unused
 ShenandoahIsMarkedNextClosure
Message-ID: <80d72c1b-700e-df7a-8f43-c0368139e541@redhat.com>

Please review this trivial patch that removes unused 
ShenandoahIsMarkedNextClosure.

Bug: https://bugs.openjdk.java.net/browse/JDK-8246342
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246342/webrev.00/

Test:
   Built on Linux x86_64

Thanks,

-Zhengyu


From shade at redhat.com  Tue Jun  2 18:49:31 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 2 Jun 2020 20:49:31 +0200
Subject: [15] RFR 8245961: Shenandoah: move some root marking to
 concurrent phase
In-Reply-To: <57228404-acb5-9537-caef-35919cbff493@redhat.com>
References: <61efdf04-5d74-8a59-a193-576b115738ef@redhat.com>
 <ef70f68f-c69c-f18e-c510-192c285fabf7@redhat.com>
 <5b7385d8-8b08-fd52-4ef0-d846fc0c3e11@redhat.com>
 <06e40ce2-9f0d-e90a-8929-9600c3bbf4c5@redhat.com>
 <57228404-acb5-9537-caef-35919cbff493@redhat.com>
Message-ID: <f3793813-98cf-cf9a-5e7c-30ca6c5e030e@redhat.com>

On 6/2/20 7:50 PM, Zhengyu Gu wrote:
> On 6/2/20 10:13 AM, Aleksey Shipilev wrote:
>> On 6/2/20 3:12 PM, Zhengyu Gu wrote:
>>> http://cr.openjdk.java.net/~zgu/JDK-8245961/webrev.01/index.html
>>
>> Looks OK. A few more minor nits (after rebasing to jdk/jdk):
>>    https://cr.openjdk.java.net/~shade/shenandoah/8245961-shade-updates.patch
> 
> Rebased webrev.01 to jdk/jdk and manually folded some of your suggested 
> changes:
> 
> http://cr.openjdk.java.net/~zgu/JDK-8245961/webrev.02/

Looks OK.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Jun  2 18:50:22 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 2 Jun 2020 20:50:22 +0200
Subject: [15] RFR(T) 8246342: Shenandoah: remove unused
 ShenandoahIsMarkedNextClosure
In-Reply-To: <80d72c1b-700e-df7a-8f43-c0368139e541@redhat.com>
References: <80d72c1b-700e-df7a-8f43-c0368139e541@redhat.com>
Message-ID: <12e52d7d-1106-34e6-d462-ae7350e0e309@redhat.com>

On 6/2/20 8:24 PM, Zhengyu Gu wrote:
> Please review this trivial patch that removes unused 
> ShenandoahIsMarkedNextClosure.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246342
> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246342/webrev.00/

Looks good!

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Tue Jun  2 20:27:27 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 2 Jun 2020 22:27:27 +0200
Subject: [8] RFR: Move barrier sets to their proper locations
In-Reply-To: <1723f979-7989-ac81-86d6-485301e53e54@redhat.com>
References: <ac90ffce-f0db-7030-1241-776da594659e@redhat.com>
 <d39b61295169a2a0b73d2eb950545b8e576d93ec.camel@redhat.com>
 <1723f979-7989-ac81-86d6-485301e53e54@redhat.com>
Message-ID: <CAAN-Kyhkrfk8vawx9Z-L9NrQ556ZKq14852fMgiHsca61E_Uew@mail.gmail.com>

OK looks good!

Thanks,
Roman

Aleksey Shipilev <shade at redhat.com> schrieb am Mo., 1. Juni 2020, 20:13:

> On 5/20/20 5:56 PM, Roman Kennke wrote:
> > Ok. I was wondering the same for a while, but always assumed we'd need
> > build-machinery changes to pick up stuff under subdirectories.
>
> You know what? You are right, we need to do special things for Windows and
> Minimal VM:
>   https://cr.openjdk.java.net/~shade/shenandoah/8u-move-sbs/webrev.02/
>
> ...like we did here:
>   https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/4fd7bc699d62
>
> Testing: Linux, Windows builds
>
> --
> Thanks,
> -Aleksey
>
>

From rkennke at redhat.com  Tue Jun  2 20:29:59 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 2 Jun 2020 22:29:59 +0200
Subject: [8] Shenandoah: Fix build failure with +JFR -PCH
In-Reply-To: <2befc151-53e5-2998-6be2-53866f68f58d@redhat.com>
References: <2befc151-53e5-2998-6be2-53866f68f58d@redhat.com>
Message-ID: <CAAN-KyiRaeByP4j+fyZP0ZwKLmkhu1_o11e0SRY_tHy-OFwFZA@mail.gmail.com>

JFC :-) Looks good, thank you!

Roman

Aleksey Shipilev <shade at redhat.com> schrieb am Di., 2. Juni 2020, 13:05:

> Hi,
>
> Current sh/jdk8 build fails if configured --enable-jfr and
> --disable-precompiled-headers like this:
>
> In file included from
>
> /home/shade/trunks/shenandoah-jdk8/hotspot/src/share/vm/jfr/instrumentation/jfrJvmtiAgent.cpp:29:0:
> /home/shade/trunks/shenandoah-jdk8/hotspot/src/share/vm/jfr/jni/jfrUpcalls.hpp:57:10:
> error:
> ?instanceKlassHandle? does not name a type; did you mean ?InstanceKlass??
>    static instanceKlassHandle load_event_handler_proxy_class(TRAPS);
>           ^~~~~~~~~~~~~~~~~~~
>           InstanceKlass
>
> I notice we already have this upstream difference in os.hpp that unties
> the header circularity:
>
> --- old/src/share/vm/runtime/os.hpp     2020-06-02 01:08:37.190316031 +0200
> +++ new/src/share/vm/runtime/os.hpp     2020-06-02 01:08:37.110316134 +0200
> @@ -28,7 +28,6 @@
>  #include "jvmtifiles/jvmti.h"
>  #include "runtime/atomic.hpp"
>  #include "runtime/extendedPC.hpp"
> -#include "runtime/handles.hpp"
>  #include "utilities/top.hpp"
>  #ifdef TARGET_OS_FAMILY_linux
>  # include "jvm_linux.h"
> @@ -54,6 +53,7 @@
>  #endif
>
>  class AgentLibrary;
> +class methodHandle;
>
> I tried to revert that block and solve it by rearranging Shenandoah
> includes a bit, but to no avail.
> So, this is my plan B that seems to solve the build failure:
>
> diff -r 4439a43801a4 src/share/vm/runtime/os.hpp
> --- a/src/share/vm/runtime/os.hpp       Mon Jun 01 19:14:49 2020 +0200
> +++ b/src/share/vm/runtime/os.hpp       Tue Jun 02 11:17:51 2020 +0200
> @@ -52,10 +52,11 @@
>  # endif
>  #endif
>
>  class AgentLibrary;
>  class methodHandle;
> +class instanceKlassHandle;
>
>  // os defines the interface to operating system; this includes traditional
>  // OS services (time, I/O) as well as other functionality with system-
>  // dependent code.
>
> Testing: Linux x86_64 builds with {+JFR, -JFR} x {+PCH, -PCH} x {release,
> fastdebug, slowdebug}
>
> --
> Thanks,
> -Aleksey
>
>

From shade at redhat.com  Tue Jun  2 20:35:11 2020
From: shade at redhat.com (shade at redhat.com)
Date: Tue, 02 Jun 2020 20:35:11 +0000
Subject: hg: shenandoah/jdk8/hotspot: 2 new changesets
Message-ID: <202006022035.052KZB4v019311@aojmv0008.oracle.com>

Changeset: db0c4aad24d9
Author:    shade
Date:      2020-06-02 22:34 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/db0c4aad24d9

Shenandoah: move barrier sets to their proper locations
Reviewed-by: rkennke

! make/excludeSrc.make
! make/windows/create_obj_files.sh
! make/windows/makefiles/vm.make
! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp
! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp
! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp
! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
+ src/share/vm/gc_implementation/shenandoah/c1/shenandoahBarrierSetC1.cpp
+ src/share/vm/gc_implementation/shenandoah/c1/shenandoahBarrierSetC1.hpp
+ src/share/vm/gc_implementation/shenandoah/c2/shenandoahBarrierSetC2.cpp
+ src/share/vm/gc_implementation/shenandoah/c2/shenandoahBarrierSetC2.hpp
+ src/share/vm/gc_implementation/shenandoah/c2/shenandoahSupport.cpp
+ src/share/vm/gc_implementation/shenandoah/c2/shenandoahSupport.hpp
! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp
- src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp
- src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.hpp
- src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.cpp
- src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.hpp
- src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp
- src/share/vm/gc_implementation/shenandoah/shenandoahSupport.hpp
! src/share/vm/opto/addnode.cpp
! src/share/vm/opto/callnode.cpp
! src/share/vm/opto/cfgnode.cpp
! src/share/vm/opto/classes.cpp
! src/share/vm/opto/compile.cpp
! src/share/vm/opto/escape.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/loopopts.cpp
! src/share/vm/opto/machnode.cpp
! src/share/vm/opto/macro.cpp
! src/share/vm/opto/matcher.cpp
! src/share/vm/opto/memnode.cpp
! src/share/vm/opto/mulnode.cpp
! src/share/vm/opto/multnode.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/phaseX.cpp
! src/share/vm/opto/subnode.cpp

Changeset: e16a3f855bf3
Author:    shade
Date:      2020-06-02 22:34 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e16a3f855bf3

Shenandoah: Fix build failure with +JFR -PCH
Reviewed-by: rkennke

! src/share/vm/runtime/os.hpp


From shade at redhat.com  Wed Jun  3 09:30:23 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 3 Jun 2020 11:30:23 +0200
Subject: RFC: Pick up 11.0.8+6 to sh/jdk11
Message-ID: <69bd1cd8-7b85-9b3d-f1c1-cf93d9f88650@redhat.com>

Upstream had published 11.0.8+6, let's pick it up to sh/jdk11.

Merge is trivial. I would tag it shenandoah-jdk-11.0.8+6 right away.

Testing: hotspot_gc_shenandoah {fastdebug, release}

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Jun  3 09:57:32 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 3 Jun 2020 11:57:32 +0200
Subject: Concurrent marking of root objects
In-Reply-To: <trinity-ef7c1211-26cd-4575-949d-dbf6825a294d-1590765505879@3c-app-webde-bap55>
References: <trinity-83816d97-aa4e-4c21-8490-560e120b842e-1590711423899@3c-app-webde-bap45>
 <fd2ac8aa-192c-35d2-a6f2-92997b8838f7@redhat.com>
 <trinity-ef7c1211-26cd-4575-949d-dbf6825a294d-1590765505879@3c-app-webde-bap55>
Message-ID: <e67601ba-2718-bfea-090f-cc85134d408f@redhat.com>

On 5/29/20 5:18 PM, raell at web.de wrote:
> cool. Thank you very much for the information. 

This is now pushed to jdk/jdk:
  https://hg.openjdk.java.net/jdk/jdk/rev/e94d4a272e4e

You might want to give our jdk/jdk nightlies a spin:
  https://builds.shipilev.net/openjdk-jdk/

You would see something like this with -Xlog:gc+stats:

 Pause Init Mark (G)                1008 us
 Pause Init Mark (N)                 635 us
   Make Parsable                      28 us
   Update Region States               47 us
   Scan Roots                        484 us, parallelism: 2.43x
     S: <total>                     1176 us
     S: Thread Roots                1134 us, workers (us):  76,  41, 274, 101,  72,  67, 439,  65,
     S: Universe Roots                 3 us, workers (us):   3, ---, ---, ---, ---, ---, ---, ---,
     S: Synchronizer Roots             0 us, workers (us):   0, ---, ---, ---, ---, ---, ---, ---,
     S: Management Roots               2 us, workers (us):   2, ---, ---, ---, ---, ---, ---, ---,
     S: System Dict Roots             36 us, workers (us): ---,  36, ---, ---, ---, ---, ---, ---,
     S: JVMTI Roots                    1 us, workers (us):   1, ---, ---, ---, ---, ---, ---, ---,
   Resize TLABs                        7 us
 Concurrent Marking               282653 us
   Roots                             496 us, parallelism: 0.83x
     CM: <total>                     413 us
     CM: JNI Handles Roots             9 us, workers (us):   4,   4,   0,   0, ---, ---, ---, ---,
     CM: VM Global Roots               0 us, workers (us):   0,   0,   0,   0, ---, ---, ---, ---,
     CM: CLDG Roots                  404 us, workers (us): 332, ---,  72, ---, ---, ---, ---, ---,

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Jun  3 10:45:24 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 3 Jun 2020 12:45:24 +0200
Subject: RFR (XS) 8246433: Shenandoah: walk roots in more efficient order in
 ShenandoahRootUpdater
Message-ID: <b998beb4-6a78-5868-2508-be615d90bce3@redhat.com>

RFE:
  https://bugs.openjdk.java.net/browse/JDK-8246433

Missed the spot in ShenandoahRootUpdater while doing JDK-8246100.

Fix:

diff -r d0d06b8be678 src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp        Fri May 29 11:58:00
2020 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp        Wed Jun 03 12:44:47
2020 +0200
@@ -237,18 +237,21 @@
                                   static_cast<CodeBlobToOopClosure*>(&blobs_and_disarm_Cl) :
                                   static_cast<CodeBlobToOopClosure*>(&update_blobs);

   CLDToOopClosure clds(keep_alive, ClassLoaderData::_claim_strong);

+  // Process serial-claiming roots first
   _serial_roots.oops_do(keep_alive, worker_id);
+  _serial_weak_roots.weak_oops_do(is_alive, keep_alive, worker_id);
+
+  // Process light-weight/limited parallel roots then
   _vm_roots.oops_do(keep_alive, worker_id);
+  _weak_roots.weak_oops_do(is_alive, keep_alive, worker_id);
+  _dedup_roots.oops_do(is_alive, keep_alive, worker_id);
+  _cld_roots.cld_do(&clds, worker_id);

-  _cld_roots.cld_do(&clds, worker_id);
+  // Process heavy-weight/fully parallel roots the last
   _code_roots.code_blobs_do(codes_cl, worker_id);
   _thread_roots.oops_do(keep_alive, NULL, worker_id);
-
-  _serial_weak_roots.weak_oops_do(is_alive, keep_alive, worker_id);
-  _weak_roots.weak_oops_do(is_alive, keep_alive, worker_id);
-  _dedup_roots.oops_do(is_alive, keep_alive, worker_id);
 }

 #endif // SHARE_GC_SHENANDOAH_SHENANDOAHROOTPROCESSOR_INLINE_HPP

Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Jun  3 11:50:17 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 3 Jun 2020 13:50:17 +0200
Subject: [8] RFR: Shenandoah: fix runtime linking failure due to non-compiled
 shenandoahBarrierSetC1
Message-ID: <c0382710-a857-5f43-cdec-53a47a6551ae@redhat.com>

Turns out, C1 build configuration is odd: it explicitly lists the directories that contain
C1-related files. Without the patch below, the VM would not start and fail with runtime linking
failure. What is surprising, this would only manifest when you actually try to run the VM. The
builds would succeed either way.

Fix:

diff -r e16a3f855bf3 make/linux/makefiles/vm.make
--- a/make/linux/makefiles/vm.make      Tue Jun 02 22:34:25 2020 +0200
+++ b/make/linux/makefiles/vm.make      Wed Jun 03 13:14:50 2020 +0200
@@ -168,6 +168,7 @@

 COMPILER1_PATHS := $(call altsrc,$(HS_COMMON_SRC)/share/vm/c1)
 COMPILER1_PATHS += $(HS_COMMON_SRC)/share/vm/c1
+COMPILER1_PATHS += $(HS_COMMON_SRC)/share/vm/gc_implementation/shenandoah/c1

 COMPILER2_PATHS := $(call altsrc,$(HS_COMMON_SRC)/share/vm/opto)
 COMPILER2_PATHS += $(call altsrc,$(HS_COMMON_SRC)/share/vm/libadt)

Testing: Linux x86_64 builds and tests

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Wed Jun  3 11:57:35 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 3 Jun 2020 13:57:35 +0200
Subject: [8] RFR: Shenandoah: fix runtime linking failure due to
 non-compiled shenandoahBarrierSetC1
In-Reply-To: <c0382710-a857-5f43-cdec-53a47a6551ae@redhat.com>
References: <c0382710-a857-5f43-cdec-53a47a6551ae@redhat.com>
Message-ID: <CAAN-KyjvM_XgX3Y2k_DLnUhpUQsiCYC7DyjQ4h+DA0=2ZtzAOw@mail.gmail.com>

Yes looks good!

Cheers,
Roman


Aleksey Shipilev <shade at redhat.com> schrieb am Mi., 3. Juni 2020, 13:51:

> Turns out, C1 build configuration is odd: it explicitly lists the
> directories that contain
> C1-related files. Without the patch below, the VM would not start and fail
> with runtime linking
> failure. What is surprising, this would only manifest when you actually
> try to run the VM. The
> builds would succeed either way.
>
> Fix:
>
> diff -r e16a3f855bf3 make/linux/makefiles/vm.make
> --- a/make/linux/makefiles/vm.make      Tue Jun 02 22:34:25 2020 +0200
> +++ b/make/linux/makefiles/vm.make      Wed Jun 03 13:14:50 2020 +0200
> @@ -168,6 +168,7 @@
>
>  COMPILER1_PATHS := $(call altsrc,$(HS_COMMON_SRC)/share/vm/c1)
>  COMPILER1_PATHS += $(HS_COMMON_SRC)/share/vm/c1
> +COMPILER1_PATHS +=
> $(HS_COMMON_SRC)/share/vm/gc_implementation/shenandoah/c1
>
>  COMPILER2_PATHS := $(call altsrc,$(HS_COMMON_SRC)/share/vm/opto)
>  COMPILER2_PATHS += $(call altsrc,$(HS_COMMON_SRC)/share/vm/libadt)
>
> Testing: Linux x86_64 builds and tests
>
> --
> Thanks,
> -Aleksey
>
>

From zgu at redhat.com  Wed Jun  3 12:01:38 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 3 Jun 2020 08:01:38 -0400
Subject: RFR (XS) 8246433: Shenandoah: walk roots in more efficient order
 in ShenandoahRootUpdater
In-Reply-To: <b998beb4-6a78-5868-2508-be615d90bce3@redhat.com>
References: <b998beb4-6a78-5868-2508-be615d90bce3@redhat.com>
Message-ID: <2ebdb1b7-b9a3-301a-1cc6-5ab3e9966eec@redhat.com>

Looks good.

-Zhengyu

On 6/3/20 6:45 AM, Aleksey Shipilev wrote:
> RFE:
>    https://bugs.openjdk.java.net/browse/JDK-8246433
> 
> Missed the spot in ShenandoahRootUpdater while doing JDK-8246100.
> 
> Fix:
> 
> diff -r d0d06b8be678 src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
> --- a/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp        Fri May 29 11:58:00
> 2020 +0200
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp        Wed Jun 03 12:44:47
> 2020 +0200
> @@ -237,18 +237,21 @@
>                                     static_cast<CodeBlobToOopClosure*>(&blobs_and_disarm_Cl) :
>                                     static_cast<CodeBlobToOopClosure*>(&update_blobs);
> 
>     CLDToOopClosure clds(keep_alive, ClassLoaderData::_claim_strong);
> 
> +  // Process serial-claiming roots first
>     _serial_roots.oops_do(keep_alive, worker_id);
> +  _serial_weak_roots.weak_oops_do(is_alive, keep_alive, worker_id);
> +
> +  // Process light-weight/limited parallel roots then
>     _vm_roots.oops_do(keep_alive, worker_id);
> +  _weak_roots.weak_oops_do(is_alive, keep_alive, worker_id);
> +  _dedup_roots.oops_do(is_alive, keep_alive, worker_id);
> +  _cld_roots.cld_do(&clds, worker_id);
> 
> -  _cld_roots.cld_do(&clds, worker_id);
> +  // Process heavy-weight/fully parallel roots the last
>     _code_roots.code_blobs_do(codes_cl, worker_id);
>     _thread_roots.oops_do(keep_alive, NULL, worker_id);
> -
> -  _serial_weak_roots.weak_oops_do(is_alive, keep_alive, worker_id);
> -  _weak_roots.weak_oops_do(is_alive, keep_alive, worker_id);
> -  _dedup_roots.oops_do(is_alive, keep_alive, worker_id);
>   }
> 
>   #endif // SHARE_GC_SHENANDOAH_SHENANDOAHROOTPROCESSOR_INLINE_HPP
> 
> Testing: hotspot_gc_shenandoah
> 


From shade at redhat.com  Wed Jun  3 12:28:47 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 3 Jun 2020 14:28:47 +0200
Subject: [8] 2020-06-03, Bulk backports to sh/jdk8
Message-ID: <f55046dc-e147-cf70-2914-ff0b85caf140@redhat.com>

https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200603/webrev.01/

This backports two bugfixes:
  [backport] 8246162: Shenandoah: full GC does not mark code roots when class unloading is off
  [backport] 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits

Testing: hotspot_gc_shenandoah {fastdebug,release}

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Wed Jun  3 12:45:53 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 3 Jun 2020 08:45:53 -0400
Subject: [8] 2020-06-03, Bulk backports to sh/jdk8
In-Reply-To: <f55046dc-e147-cf70-2914-ff0b85caf140@redhat.com>
References: <f55046dc-e147-cf70-2914-ff0b85caf140@redhat.com>
Message-ID: <e209fba2-4c74-f993-e9f9-3f5567273236@redhat.com>

Okay.

-Zhengyu

On 6/3/20 8:28 AM, Aleksey Shipilev wrote:
> https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200603/webrev.01/
> 
> This backports two bugfixes:
>    [backport] 8246162: Shenandoah: full GC does not mark code roots when class unloading is off
>    [backport] 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits
> 
> Testing: hotspot_gc_shenandoah {fastdebug,release}
> 


From zgu at redhat.com  Wed Jun  3 15:45:01 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 3 Jun 2020 11:45:01 -0400
Subject: [15] RFR 8246458: Shenandoah: TestAllocObjects.java test fail with
 -XX:+ShenandoahVerify
Message-ID: <baa7d70e-8278-7e37-f742-fff81a396ef7@redhat.com>

We should not run root verifier if OOM during evacuating/updating roots 
in final mark phase, cause there is no guarantee that they are consistent.

Bug: https://bugs.openjdk.java.net/browse/JDK-8246458
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246458/weberv.00/

Test:
   hotspot_gc_shenandoah


Thanks,

-Zhengyu


From shade at redhat.com  Wed Jun  3 15:51:45 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 3 Jun 2020 17:51:45 +0200
Subject: [8] 2020-06-03, Bulk backports to sh/jdk8
In-Reply-To: <e209fba2-4c74-f993-e9f9-3f5567273236@redhat.com>
References: <f55046dc-e147-cf70-2914-ff0b85caf140@redhat.com>
 <e209fba2-4c74-f993-e9f9-3f5567273236@redhat.com>
Message-ID: <d9b44e75-c6ee-2d43-456d-bf4adc1818cb@redhat.com>

On 6/3/20 2:45 PM, Zhengyu Gu wrote:
> Okay.

Thanks, pushed.

-- 
-Aleksey


From shade at redhat.com  Wed Jun  3 15:53:37 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 3 Jun 2020 17:53:37 +0200
Subject: [15] RFR 8246458: Shenandoah: TestAllocObjects.java test fail
 with -XX:+ShenandoahVerify
In-Reply-To: <baa7d70e-8278-7e37-f742-fff81a396ef7@redhat.com>
References: <baa7d70e-8278-7e37-f742-fff81a396ef7@redhat.com>
Message-ID: <c6820296-21aa-6b16-c647-40b360e21e9c@redhat.com>

On 6/3/20 5:45 PM, Zhengyu Gu wrote:
> We should not run root verifier if OOM during evacuating/updating roots 
> in final mark phase, cause there is no guarantee that they are consistent.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246458
> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246458/weberv.00/

Looks fine.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Jun  3 15:50:24 2020
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 03 Jun 2020 15:50:24 +0000
Subject: hg: shenandoah/jdk8/hotspot: 2 new changesets
Message-ID: <202006031550.053FoOTL023024@aojmv0008.oracle.com>

Changeset: 381e483af639
Author:    zgu
Date:      2020-05-29 13:44 -0400
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/381e483af639

[backport] 8246162: Shenandoah: full GC does not mark code roots when class unloading is off
Reviewed-by: shade

! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp

Changeset: 6398a22a767e
Author:    shade
Date:      2020-05-26 09:31 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6398a22a767e

[backport] 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits
Reviewed-by: rkennke

! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp
! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp
! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp
! src/share/vm/runtime/arguments.cpp


From zgu at redhat.com  Wed Jun  3 16:09:50 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 3 Jun 2020 12:09:50 -0400
Subject: [15] RFR 8246458: Shenandoah: TestAllocObjects.java test fail
 with -XX:+ShenandoahVerify
In-Reply-To: <c6820296-21aa-6b16-c647-40b360e21e9c@redhat.com>
References: <baa7d70e-8278-7e37-f742-fff81a396ef7@redhat.com>
 <c6820296-21aa-6b16-c647-40b360e21e9c@redhat.com>
Message-ID: <108557b2-0625-7369-3aa9-56a0de781f37@redhat.com>

Thanks and pushed.

-Zhengyu

On 6/3/20 11:53 AM, Aleksey Shipilev wrote:
> On 6/3/20 5:45 PM, Zhengyu Gu wrote:
>> We should not run root verifier if OOM during evacuating/updating roots
>> in final mark phase, cause there is no guarantee that they are consistent.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246458
>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246458/weberv.00/
> 
> Looks fine.
> 


From shade at redhat.com  Wed Jun  3 18:28:54 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 3 Jun 2020 20:28:54 +0200
Subject: [14] RFR: 8246100: Shenandoah: walk roots in more efficient order
Message-ID: <2da2dd1a-64b4-8ad1-6b1d-43d4e6864d8a@redhat.com>

Original RFE:
  https://bugs.openjdk.java.net/browse/JDK-8246100
  https://cr.openjdk.java.net/~shade/8246100/webrev.14u.01/

The context in 14u is a bit different. Re-did the patch, by shuffling the lines in the existing
files. 14u webrev:
  https://cr.openjdk.java.net/~shade/8246100/webrev.14u.01/

Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah enabled

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Jun  3 18:30:24 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 3 Jun 2020 20:30:24 +0200
Subject: [14] RFR 8246097: Shenandoah: limit parallelism in CLDG root handling
Message-ID: <314697e8-dd39-87ec-60d1-4311ebb04587@redhat.com>

Original RFE:
  https://bugs.openjdk.java.net/browse/JDK-8246097
  https://hg.openjdk.java.net/jdk/jdk/rev/c60f06714a9e

The context in 14u is a bit different. Trivial application of the rejected hunks by hand.
  http://cr.openjdk.java.net/~shade/8246097/webrev.14u.01/

Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah enabled

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Wed Jun  3 19:04:52 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 3 Jun 2020 15:04:52 -0400
Subject: RFC: Pick up 11.0.8+6 to sh/jdk11
In-Reply-To: <69bd1cd8-7b85-9b3d-f1c1-cf93d9f88650@redhat.com>
References: <69bd1cd8-7b85-9b3d-f1c1-cf93d9f88650@redhat.com>
Message-ID: <3e11c720-132c-c9f2-d09c-b9865abbc964@redhat.com>

Okay.

Thanks,

-Zhengyu

On 6/3/20 5:30 AM, Aleksey Shipilev wrote:
> Upstream had published 11.0.8+6, let's pick it up to sh/jdk11.
> 
> Merge is trivial. I would tag it shenandoah-jdk-11.0.8+6 right away.
> 
> Testing: hotspot_gc_shenandoah {fastdebug, release}
> 


From zgu at redhat.com  Wed Jun  3 19:42:34 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 3 Jun 2020 15:42:34 -0400
Subject: [14] RFR: 8246100: Shenandoah: walk roots in more efficient order
In-Reply-To: <2da2dd1a-64b4-8ad1-6b1d-43d4e6864d8a@redhat.com>
References: <2da2dd1a-64b4-8ad1-6b1d-43d4e6864d8a@redhat.com>
Message-ID: <fc7f4699-080d-f248-8b4c-43a786b8ece4@redhat.com>

Looks good.

-Zhengyu

On 6/3/20 2:28 PM, Aleksey Shipilev wrote:
> Original RFE:
>    https://bugs.openjdk.java.net/browse/JDK-8246100
>    https://cr.openjdk.java.net/~shade/8246100/webrev.14u.01/
> 
> The context in 14u is a bit different. Re-did the patch, by shuffling the lines in the existing
> files. 14u webrev:
>    https://cr.openjdk.java.net/~shade/8246100/webrev.14u.01/
> 
> Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah enabled
> 


From zgu at redhat.com  Wed Jun  3 19:43:45 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 3 Jun 2020 15:43:45 -0400
Subject: [14] RFR 8246097: Shenandoah: limit parallelism in CLDG root
 handling
In-Reply-To: <314697e8-dd39-87ec-60d1-4311ebb04587@redhat.com>
References: <314697e8-dd39-87ec-60d1-4311ebb04587@redhat.com>
Message-ID: <39a1c24f-c721-3aa8-d671-2038975d80cf@redhat.com>

Good.

-Zhengyu

On 6/3/20 2:30 PM, Aleksey Shipilev wrote:
> Original RFE:
>    https://bugs.openjdk.java.net/browse/JDK-8246097
>    https://hg.openjdk.java.net/jdk/jdk/rev/c60f06714a9e
> 
> The context in 14u is a bit different. Trivial application of the rejected hunks by hand.
>    http://cr.openjdk.java.net/~shade/8246097/webrev.14u.01/
> 
> Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah enabled
> 


From gnu.andrew at redhat.com  Wed Jun  3 21:30:24 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 3 Jun 2020 22:30:24 +0100
Subject: [RFR] [8u] 8u262-b05 Upstream Sync
Message-ID: <0df7cf7b-079a-87f9-34ac-3e6ef1bc7f0c@redhat.com>

Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/

Merge changesets:
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/corba/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jaxp/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jaxws/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/hotspot/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/langtools/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/nashorn/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/root/merge.changeset

Changes in aarch64-shenandoah-jdk8u262-b05:
  - JDK-7147060:
com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java
doesn't run in agentvm mode
  - JDK-8178374: Problematic ByteBuffer handling in
CipherSpi.bufferCrypt method
  - JDK-8181841: A TSA server returns timestamp with precision higher
than milliseconds
  - JDK-8227269: Slow class loading when running with JDWP
  - JDK-8229899: Make java.io.File.isInvalid() less racy
  - JDK-8236996: Incorrect Roboto font rendering on Windows with
subpixel antialiasing
  - JDK-8238842: AIOOBE in GIFImageReader.initializeStringTable
  - JDK-8241750: x86_32 build failure after JDK-8227269
  - JDK-8244407: JVM crashes after transformation in C2
IdealLoopTree::split_fall_in
  - JDK-8244843: JapanEraNameCompatTest fails

Main issues of note:
None, clean merge.

diffstat for root
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for corba
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for jaxp
 b/.hgtags |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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/src/share/back/classTrack.c
         |  357 ++-----
 b/src/share/back/classTrack.h
         |    6
 b/src/share/back/eventHandler.c
         |    3
 b/src/share/back/util.c
         |    2
 b/src/share/back/util.h
         |    2
 b/src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
         |    5
 b/src/share/classes/java/io/File.java
         |   10
 b/src/share/classes/javax/crypto/CipherSpi.java
         |  142 +-
 b/src/share/classes/sun/font/FileFontStrike.java
         |   12
 b/src/share/classes/sun/font/TrueTypeFont.java
         |   11
 b/src/share/classes/sun/security/util/DerInputBuffer.java
         |   48
 b/src/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java
        |   20
 b/src/share/classes/sun/text/resources/in/JavaTimeSupplementary_in.java
        |  497 ++++++++++
 b/src/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java
        |   20
 b/src/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java
        |   20
 b/src/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java
        |   20
 b/src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java    |   20
 b/src/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java
        |   20
 b/src/windows/native/sun/font/lcdglyph.c
         |   15
 b/test/ProblemList.txt
         |    3
 b/test/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java |    6
 b/test/javax/crypto/CipherSpi/TestGCMWithByteBuffer.java
         |  165 +++
 b/test/javax/imageio/plugins/gif/GIFCodeSizeTest.java
         |   52 +
 b/test/sun/security/util/DerInputBuffer/TimeParsing.java
         |   19
 25 files changed, 1139 insertions(+), 337 deletions(-)

diffstat for hotspot
 b/.hgtags                                         |    1
 b/src/share/vm/opto/loopnode.cpp                  |   14 ++-
 b/test/compiler/loopopts/TestBeautifyLoops_2.java |   81
++++++++++++++++++++++
 3 files changed, 93 insertions(+), 3 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


From shade at redhat.com  Thu Jun  4 06:25:22 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Jun 2020 08:25:22 +0200
Subject: RFC: Pick up 11.0.8+6 to sh/jdk11
In-Reply-To: <3e11c720-132c-c9f2-d09c-b9865abbc964@redhat.com>
References: <69bd1cd8-7b85-9b3d-f1c1-cf93d9f88650@redhat.com>
 <3e11c720-132c-c9f2-d09c-b9865abbc964@redhat.com>
Message-ID: <16313aad-3ce2-1f5c-59aa-a5286cee0d9d@redhat.com>

On 6/3/20 9:04 PM, Zhengyu Gu wrote:
> Okay.

Cheers, pushed.

-- 
-Aleksey


From shade at redhat.com  Thu Jun  4 06:36:22 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Jun 2020 08:36:22 +0200
Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b05 Upstream Sync
In-Reply-To: <0df7cf7b-079a-87f9-34ac-3e6ef1bc7f0c@redhat.com>
References: <0df7cf7b-079a-87f9-34ac-3e6ef1bc7f0c@redhat.com>
Message-ID: <3c0dc3ea-354f-56fc-da18-6fc6102f4ed8@redhat.com>

On 6/3/20 11:30 PM, Andrew Hughes wrote:
> Merge changesets:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jaxws/merge.changeset

Look good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset

Looks good.

This would temporarily break Windows builds until 8246223 is here, right?

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/hotspot/merge.changeset

Looks good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/langtools/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/nashorn/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/root/merge.changeset

Look good.

> Ok to push?

Yes.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Thu Jun  4 09:23:58 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Jun 2020 11:23:58 +0200
Subject: RFR: 2020-06-04, Bulk integration of Shenandoah 8u to
 aarch64-port/jdk8u-shenandoah
Message-ID: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com>

https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/webrev.01/

This is another integration of Shenandoah 8u from our shenandoah/jdk8 staging repository. It was
generated by plain pull from shenandoah/jdk8/hotspot repository and automatic merge.

The webrev is not very large, and mostly contains file moves and associated build changes. IMO, the
only thing that deserves explanation is the addition in src/share/vm/runtime/os.hpp:
  https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-June/012413.html

We would negotiate the push order w.r.t. upstream sync with Andrew Hughes.

Changes:
  Shenandoah: move parallelCleaning.* to shenandoah/
  Shenandoah: fix formats in ShenandoahStringSymbolTableUnlinkTask
  [backport] 8245812: Shenandoah: compute root phase parallelism
  [backport] 8245814: Shenandoah: reconsider format specifiers for stats
  [backport] 8245463: Shenandoah: refine ShenandoahPhaseTimings constructor arguments
  [backport] 8245754: Shenandoah: ditch ShenandoahAlwaysPreTouch
  [backport] 8245461: Shenandoah: refine mode name()-s
  [backport] 8245726: Shenandoah: lift/cleanup ShenandoahHeuristics names and properties
  [backport] 8245825: Shenandoah: Remove diagnostic flag ShenandoahConcurrentScanCodeRoots
  Shenandoah: move barrier sets to their proper locations
  Shenandoah: Fix build failure with +JFR -PCH
  Shenandoah: fix runtime linking failure due to non-compiled shenandoahBarrierSetC1
  [backport] 8246162: Shenandoah: full GC does not mark code roots when class unloading is off
  [backport] 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits
   Merge

Testing: hotspot_gc_shenandoah {fastdebug,release}; it was also tested in sh/jdk8 with a few nightlies

-- 
Thanks,
-Aleksey


From shade at redhat.com  Thu Jun  4 09:32:02 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Jun 2020 11:32:02 +0200
Subject: [11] 2020-06-04: Bulk backports to sh/jdk11
Message-ID: <9df4fbfc-ab85-51fc-ed4d-e80f53b860b7@redhat.com>

https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200604/webrev.01/

This backports a few safe-ish performance improvements.

Changes:
 [backport] 8246100: Shenandoah: walk roots in more efficient order
 [backport] 8246097: Shenandoah: limit parallelism in CLDG root handling

Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Thu Jun  4 11:45:30 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 4 Jun 2020 07:45:30 -0400
Subject: [11] 2020-06-04: Bulk backports to sh/jdk11
In-Reply-To: <9df4fbfc-ab85-51fc-ed4d-e80f53b860b7@redhat.com>
References: <9df4fbfc-ab85-51fc-ed4d-e80f53b860b7@redhat.com>
Message-ID: <a6444fbb-9bd5-4cda-3ed6-f8a93ffe3598@redhat.com>

Okay.

Thanks,

-Zhengyu

On 6/4/20 5:32 AM, Aleksey Shipilev wrote:
> https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200604/webrev.01/
> 
> This backports a few safe-ish performance improvements.
> 
> Changes:
>   [backport] 8246100: Shenandoah: walk roots in more efficient order
>   [backport] 8246097: Shenandoah: limit parallelism in CLDG root handling
> 
> Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah
> 


From shade at redhat.com  Thu Jun  4 12:10:27 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Jun 2020 14:10:27 +0200
Subject: [11] 2020-06-04: Bulk backports to sh/jdk11
In-Reply-To: <a6444fbb-9bd5-4cda-3ed6-f8a93ffe3598@redhat.com>
References: <9df4fbfc-ab85-51fc-ed4d-e80f53b860b7@redhat.com>
 <a6444fbb-9bd5-4cda-3ed6-f8a93ffe3598@redhat.com>
Message-ID: <5ee8c363-dc1b-1d3a-5645-752b7d73fd8c@redhat.com>

On 6/4/20 1:45 PM, Zhengyu Gu wrote:
> Okay.

Thanks, pushed.

-- 
-Aleksey


From gnu.andrew at redhat.com  Thu Jun  4 17:01:27 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 4 Jun 2020 18:01:27 +0100
Subject: RFR: 2020-06-04, Bulk integration of Shenandoah 8u to
 aarch64-port/jdk8u-shenandoah
In-Reply-To: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com>
References: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com>
Message-ID: <06aab6d9-803b-212c-79ec-291467c2951e@redhat.com>

On 04/06/2020 10:23, Aleksey Shipilev wrote:
> https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/webrev.01/
> 
> This is another integration of Shenandoah 8u from our shenandoah/jdk8 staging repository. It was
> generated by plain pull from shenandoah/jdk8/hotspot repository and automatic merge.
> 
> The webrev is not very large, and mostly contains file moves and associated build changes. IMO, the
> only thing that deserves explanation is the addition in src/share/vm/runtime/os.hpp:
>   https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-June/012413.html
> 
> We would negotiate the push order w.r.t. upstream sync with Andrew Hughes.
> 
> Changes:
>   Shenandoah: move parallelCleaning.* to shenandoah/
>   Shenandoah: fix formats in ShenandoahStringSymbolTableUnlinkTask
>   [backport] 8245812: Shenandoah: compute root phase parallelism
>   [backport] 8245814: Shenandoah: reconsider format specifiers for stats
>   [backport] 8245463: Shenandoah: refine ShenandoahPhaseTimings constructor arguments
>   [backport] 8245754: Shenandoah: ditch ShenandoahAlwaysPreTouch
>   [backport] 8245461: Shenandoah: refine mode name()-s
>   [backport] 8245726: Shenandoah: lift/cleanup ShenandoahHeuristics names and properties
>   [backport] 8245825: Shenandoah: Remove diagnostic flag ShenandoahConcurrentScanCodeRoots
>   Shenandoah: move barrier sets to their proper locations
>   Shenandoah: Fix build failure with +JFR -PCH
>   Shenandoah: fix runtime linking failure due to non-compiled shenandoahBarrierSetC1
>   [backport] 8246162: Shenandoah: full GC does not mark code roots when class unloading is off
>   [backport] 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits
>    Merge
> 
> Testing: hotspot_gc_shenandoah {fastdebug,release}; it was also tested in sh/jdk8 with a few nightlies
> 

Is it possible to get the merge changeset itself, exported in git diff
format? What webrev has produced shows moved files as huge diffs of one
file being removed and another being added.

os.hpp change is ugly, but I guess needed.

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


From gnu.andrew at redhat.com  Thu Jun  4 17:06:56 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 4 Jun 2020 18:06:56 +0100
Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b05 Upstream Sync
In-Reply-To: <3c0dc3ea-354f-56fc-da18-6fc6102f4ed8@redhat.com>
References: <0df7cf7b-079a-87f9-34ac-3e6ef1bc7f0c@redhat.com>
 <3c0dc3ea-354f-56fc-da18-6fc6102f4ed8@redhat.com>
Message-ID: <f6217c74-edb4-9424-b538-0cbc60b3cf27@redhat.com>



On 04/06/2020 07:36, Aleksey Shipilev wrote:
> On 6/3/20 11:30 PM, Andrew Hughes wrote:
>> Merge changesets:
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/corba/merge.changeset
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jaxp/merge.changeset
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jaxws/merge.changeset
> 
> Look good.
> 
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset
> 
> Looks good.
> 
> This would temporarily break Windows builds until 8246223 is here, right?

Yes, should be fixed in b06. Not much that can be done about this
because it wasn't caught before b05 was promoted.

> 
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/hotspot/merge.changeset
> 
> Looks good.
> 
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/langtools/merge.changeset
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/nashorn/merge.changeset
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/root/merge.changeset
> 
> Look good.
> 
>> Ok to push?
> 
> Yes.
> 

Pushing now.

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


From shade at redhat.com  Thu Jun  4 17:07:22 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Jun 2020 19:07:22 +0200
Subject: RFR: 2020-06-04, Bulk integration of Shenandoah 8u to
 aarch64-port/jdk8u-shenandoah
In-Reply-To: <06aab6d9-803b-212c-79ec-291467c2951e@redhat.com>
References: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com>
 <06aab6d9-803b-212c-79ec-291467c2951e@redhat.com>
Message-ID: <776b5b9c-f48f-8851-7d9e-e75bd13beb75@redhat.com>

On 6/4/20 7:01 PM, Andrew Hughes wrote:
> Is it possible to get the merge changeset itself, exported in git diff
> format? What webrev has produced shows moved files as huge diffs of one
> file being removed and another being added.

Sure, here it is:
  https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/merge.01.changeset

I would have to redo the merge anyway, but I expect it would be the same. It was fully automatic.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Thu Jun  4 17:52:46 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Jun 2020 19:52:46 +0200
Subject: RFR: 2020-06-04, Bulk integration of Shenandoah 8u to
 aarch64-port/jdk8u-shenandoah
In-Reply-To: <776b5b9c-f48f-8851-7d9e-e75bd13beb75@redhat.com>
References: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com>
 <06aab6d9-803b-212c-79ec-291467c2951e@redhat.com>
 <776b5b9c-f48f-8851-7d9e-e75bd13beb75@redhat.com>
Message-ID: <f3f0063a-84da-bc5b-e4f2-179399a55ba3@redhat.com>

On 6/4/20 7:07 PM, Aleksey Shipilev wrote:
> On 6/4/20 7:01 PM, Andrew Hughes wrote:
>> Is it possible to get the merge changeset itself, exported in git diff
>> format? What webrev has produced shows moved files as huge diffs of one
>> file being removed and another being added.
> 
> Sure, here it is:
>   https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/merge.01.changeset
> 
> I would have to redo the merge anyway, but I expect it would be the same. It was fully automatic.

Redid the merge after recent 8u sync:
  https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/webrev.02/
  https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/merge.02.changeset

AFAIU, it is pretty much the same. Just added the tags:
  aarch64-shenandoah-jdk8u262-b05-shenandoah-merge-2020-06-04

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Thu Jun  4 18:18:30 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 4 Jun 2020 14:18:30 -0400
Subject: [15] 8246612: Shenandoah: add timing tracking to
 ShenandoahStringDedupRoots
Message-ID: <719c5c95-d3fa-7808-4360-588cd1af3b86@redhat.com>

Please review this small patch that adds worker timing for 
ShenandoahStringDedupRoots.


Bug: https://bugs.openjdk.java.net/browse/JDK-8246612
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246612/weberv.00/index.html

Test:
   hotspot_gc_shenandoah

Thanks,

-Zhengyu


From shade at redhat.com  Thu Jun  4 18:20:43 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Jun 2020 20:20:43 +0200
Subject: [15] 8246612: Shenandoah: add timing tracking to
 ShenandoahStringDedupRoots
In-Reply-To: <719c5c95-d3fa-7808-4360-588cd1af3b86@redhat.com>
References: <719c5c95-d3fa-7808-4360-588cd1af3b86@redhat.com>
Message-ID: <87b68609-8405-c88e-cf3a-dc8ab07f5640@redhat.com>

On 6/4/20 8:18 PM, Zhengyu Gu wrote:
> Please review this small patch that adds worker timing for 
> ShenandoahStringDedupRoots.
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246612
> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246612/weberv.00/index.html

*) Please use the argument name here, "phase", to match other uses:
  212   ShenandoahConcurrentStringDedupRoots(ShenandoahPhaseTimings::Phase);

Otherwise looks good!

-- 
Thanks,
-Aleksey


From gnu.andrew at redhat.com  Thu Jun  4 18:24:49 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 4 Jun 2020 19:24:49 +0100
Subject: RFR: 2020-06-04, Bulk integration of Shenandoah 8u to
 aarch64-port/jdk8u-shenandoah
In-Reply-To: <f3f0063a-84da-bc5b-e4f2-179399a55ba3@redhat.com>
References: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com>
 <06aab6d9-803b-212c-79ec-291467c2951e@redhat.com>
 <776b5b9c-f48f-8851-7d9e-e75bd13beb75@redhat.com>
 <f3f0063a-84da-bc5b-e4f2-179399a55ba3@redhat.com>
Message-ID: <4069f49a-d7e6-f079-7b41-d4671e755a68@redhat.com>



On 04/06/2020 18:52, Aleksey Shipilev wrote:
> On 6/4/20 7:07 PM, Aleksey Shipilev wrote:
>> On 6/4/20 7:01 PM, Andrew Hughes wrote:
>>> Is it possible to get the merge changeset itself, exported in git diff
>>> format? What webrev has produced shows moved files as huge diffs of one
>>> file being removed and another being added.
>>
>> Sure, here it is:
>>   https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/merge.01.changeset
>>
>> I would have to redo the merge anyway, but I expect it would be the same. It was fully automatic.
> 
> Redid the merge after recent 8u sync:
>   https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/webrev.02/
>   https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/merge.02.changeset
> 
> AFAIU, it is pretty much the same. Just added the tags:
>   aarch64-shenandoah-jdk8u262-b05-shenandoah-merge-2020-06-04
> 

Thanks! This is a lot shorter and things like:

diff --git a/src/share/vm/gc_implementation/shared/parallelCleaning.cpp
b/src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.cpp
rename from src/share/vm/gc_implementation/shared/parallelCleaning.cpp
rename to
src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.cpp
--- a/src/share/vm/gc_implementation/shared/parallelCleaning.cpp
+++
b/src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.cpp
@@ -23,6 +23,6 @@
  */

 #include "precompiled.hpp"
-#include "gc_implementation/shared/parallelCleaning.hpp"
+#include "gc_implementation/shenandoah/shenandoahParallelCleaning.hpp"

are much easier to read than two long diffs :)

Push it and I'll do builds of the new tags.

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


From shade at redhat.com  Thu Jun  4 18:28:14 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Jun 2020 20:28:14 +0200
Subject: RFR: 2020-06-04, Bulk integration of Shenandoah 8u to
 aarch64-port/jdk8u-shenandoah
In-Reply-To: <4069f49a-d7e6-f079-7b41-d4671e755a68@redhat.com>
References: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com>
 <06aab6d9-803b-212c-79ec-291467c2951e@redhat.com>
 <776b5b9c-f48f-8851-7d9e-e75bd13beb75@redhat.com>
 <f3f0063a-84da-bc5b-e4f2-179399a55ba3@redhat.com>
 <4069f49a-d7e6-f079-7b41-d4671e755a68@redhat.com>
Message-ID: <90ab5c12-3089-ed82-0089-3ee0b75d89e7@redhat.com>

On 6/4/20 8:24 PM, Andrew Hughes wrote:
> Push it and I'll do builds of the new tags.

Pushed. Cheers!

-- 
-Aleksey


From shade at redhat.com  Thu Jun  4 18:35:56 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Jun 2020 20:35:56 +0200
Subject: RFC: Pick up aarch64-shenandoah-jdk8u262-b02 to sh/jdk8
Message-ID: <9a325b0d-e66f-275c-b0d8-54ae59142921@redhat.com>

I have recently pushed the sh/jdk8 merge to integration forest:
  https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-June/009067.html

Let's pick up everything from that merge (and all other directories) to sh/jdk8! There are no merges
at all, because sh/jdk8 is clean downstream.

Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Thu Jun  4 19:02:37 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 4 Jun 2020 15:02:37 -0400
Subject: [15] 8246612: Shenandoah: add timing tracking to
 ShenandoahStringDedupRoots
In-Reply-To: <87b68609-8405-c88e-cf3a-dc8ab07f5640@redhat.com>
References: <719c5c95-d3fa-7808-4360-588cd1af3b86@redhat.com>
 <87b68609-8405-c88e-cf3a-dc8ab07f5640@redhat.com>
Message-ID: <dc5e4c8a-3949-222d-d0ae-33c8f14b630f@redhat.com>



On 6/4/20 2:20 PM, Aleksey Shipilev wrote:
> On 6/4/20 8:18 PM, Zhengyu Gu wrote:
>> Please review this small patch that adds worker timing for
>> ShenandoahStringDedupRoots.
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246612
>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246612/weberv.00/index.html
> 
> *) Please use the argument name here, "phase", to match other uses:
>    212   ShenandoahConcurrentStringDedupRoots(ShenandoahPhaseTimings::Phase);

Fixed and pushed.

Thanks,

-Zhengyu

> 
> Otherwise looks good!
> 


From zgu at redhat.com  Thu Jun  4 19:12:44 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 4 Jun 2020 15:12:44 -0400
Subject: RFC: Pick up aarch64-shenandoah-jdk8u262-b02 to sh/jdk8
In-Reply-To: <9a325b0d-e66f-275c-b0d8-54ae59142921@redhat.com>
References: <9a325b0d-e66f-275c-b0d8-54ae59142921@redhat.com>
Message-ID: <61be7942-1fc6-5769-4858-3ecf3fa990f3@redhat.com>

Okay.

Thanks,

-Zhengyu

On 6/4/20 2:35 PM, Aleksey Shipilev wrote:
> I have recently pushed the sh/jdk8 merge to integration forest:
>    https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-June/009067.html
> 
> Let's pick up everything from that merge (and all other directories) to sh/jdk8! There are no merges
> at all, because sh/jdk8 is clean downstream.
> 
> Testing: hotspot_gc_shenandoah
> 


From shade at redhat.com  Thu Jun  4 19:13:18 2020
From: shade at redhat.com (shade at redhat.com)
Date: Thu, 04 Jun 2020 19:13:18 +0000
Subject: hg: shenandoah/jdk8/corba: 13 new changesets
Message-ID: <202006041913.054JDI2S000854@aojmv0008.oracle.com>

Changeset: 541794915ecb
Author:    serb
Date:      2019-12-02 16:38 -0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/541794915ecb

8230597: Update GIFlib library to the 5.2.1
Reviewed-by: prr, psadhukhan, jdv

! THIRD_PARTY_README

Changeset: 1d0763331a52
Author:    andrew
Date:      2020-05-19 05:11 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/1d0763331a52

Added tag jdk8u262-b03 for changeset 541794915ecb

! .hgtags

Changeset: 62ed2d4cc777
Author:    andrew
Date:      2020-05-20 01:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/62ed2d4cc777

Merge jdk8u262-b03

! .hgtags
! THIRD_PARTY_README

Changeset: 73746b29568e
Author:    andrew
Date:      2020-05-20 01:04 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/73746b29568e

Added tag aarch64-shenandoah-jdk8u262-b03 for changeset 62ed2d4cc777

! .hgtags

Changeset: 760e17e3dd74
Author:    andrew
Date:      2020-05-24 18:50 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/760e17e3dd74

Merge shenandoah-merge-2020-05-20

! .hgtags

Changeset: 2770dbc115a5
Author:    andrew
Date:      2020-05-24 19:02 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/2770dbc115a5

Added tag aarch64-shenandoah-jdk8u262-b03-shenandoah-merge-2020-05-20 for changeset 760e17e3dd74

! .hgtags

Changeset: 61a6c87db285
Author:    andrew
Date:      2020-05-25 07:02 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/61a6c87db285

Added tag jdk8u262-b04 for changeset 1d0763331a52

! .hgtags

Changeset: e74f1c626071
Author:    andrew
Date:      2020-05-26 03:02 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/e74f1c626071

Merge jdk8u262-b04

! .hgtags

Changeset: f77fdacec841
Author:    andrew
Date:      2020-05-26 03:04 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/f77fdacec841

Added tag aarch64-shenandoah-jdk8u262-b04 for changeset e74f1c626071

! .hgtags

Changeset: c4db66b4dcf7
Author:    andrew
Date:      2020-06-01 14:46 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/c4db66b4dcf7

Added tag jdk8u262-b05 for changeset 61a6c87db285

! .hgtags

Changeset: 11cc43f63583
Author:    andrew
Date:      2020-06-02 05:08 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/11cc43f63583

Merge jdk8u262-b05

! .hgtags

Changeset: fd70a68d284a
Author:    andrew
Date:      2020-06-02 05:12 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/fd70a68d284a

Added tag aarch64-shenandoah-jdk8u262-b05 for changeset 11cc43f63583

! .hgtags

Changeset: fe512e4ab160
Author:    shade
Date:      2020-06-04 19:39 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/fe512e4ab160

Added tag aarch64-shenandoah-jdk8u262-b05-shenandoah-merge-2020-06-04 for changeset fd70a68d284a

! .hgtags


From shade at redhat.com  Thu Jun  4 19:13:13 2020
From: shade at redhat.com (shade at redhat.com)
Date: Thu, 04 Jun 2020 19:13:13 +0000
Subject: hg: shenandoah/jdk8/hotspot: 23 new changesets
Message-ID: <202006041913.054JDESF000558@aojmv0008.oracle.com>

Changeset: 97d09139b360
Author:    mdoerr
Date:      2020-03-10 10:46 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/97d09139b360

8146612: C2: Precedence edges specification violated
Reviewed-by: kvn

! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/node.hpp

Changeset: bd77de4e5e2b
Author:    serb
Date:      2019-12-02 16:38 -0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/bd77de4e5e2b

8230597: Update GIFlib library to the 5.2.1
Reviewed-by: prr, psadhukhan, jdv

! THIRD_PARTY_README

Changeset: d99632e69372
Author:    chagedorn
Date:      2020-02-28 15:33 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d99632e69372

8239852: java/util/concurrent tests fail with -XX:+VerifyGraphEdges: assert(!VerifyGraphEdges) failed: verification should have failed
Summary: Remove an assertion which was too strong for some valid IRs when running with -XX:+VerifyGraphEdges
Reviewed-by: neliasso, thartmann

! src/share/vm/opto/gcm.cpp

Changeset: 26ffadc256e1
Author:    sgehwolf
Date:      2020-05-06 21:03 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/26ffadc256e1

8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result
Reviewed-by: aph, andrew

! src/share/vm/prims/jvm.h
! src/share/vm/runtime/java.hpp
! src/share/vm/runtime/vm_version.cpp

Changeset: 545fe7caa2fb
Author:    aeriksso
Date:      2020-05-19 03:11 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/545fe7caa2fb

8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing because expects HPROF JAVA PROFILE 1.0.1 file format
Reviewed-by: dcubed, dsamersoff, andrew

! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java

Changeset: 60ba2af705dc
Author:    andrew
Date:      2020-05-19 05:11 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/60ba2af705dc

Added tag jdk8u262-b03 for changeset 545fe7caa2fb

! .hgtags

Changeset: 504b65cd0a6b
Author:    andrew
Date:      2020-05-20 01:04 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/504b65cd0a6b

Merge jdk8u262-b03

! .hgtags
! THIRD_PARTY_README
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/lcm.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/opto/node.hpp
! src/share/vm/prims/jvm.h
! src/share/vm/runtime/vm_version.cpp

Changeset: c60c19f910e1
Author:    andrew
Date:      2020-05-20 01:04 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c60c19f910e1

Added tag aarch64-shenandoah-jdk8u262-b03 for changeset 504b65cd0a6b

! .hgtags

Changeset: 79d36cdf6a33
Author:    andrew
Date:      2020-05-24 18:51 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/79d36cdf6a33

Merge shenandoah-merge-2020-05-20

! .hgtags

Changeset: 5f9cc2e08814
Author:    andrew
Date:      2020-05-24 19:02 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/5f9cc2e08814

Added tag aarch64-shenandoah-jdk8u262-b03-shenandoah-merge-2020-05-20 for changeset 79d36cdf6a33

! .hgtags

Changeset: 1848821ee85d
Author:    stuefe
Date:      2020-05-14 08:48 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/1848821ee85d

8244777: ClassLoaderStats VM Op uses constant hash value
Reviewed-by: coleenp, jbachorik

! src/share/vm/classfile/classLoaderStats.hpp

Changeset: e8a0af9fc1cb
Author:    sgehwolf
Date:      2019-09-23 20:26 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e8a0af9fc1cb

8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE
Summary: Account for serialized null scopes in NMethod
Reviewed-by: aph, never, andrew

! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java
+ test/serviceability/sa/ClhsdbJstackXcompStress.java
+ test/serviceability/sa/LingeredAppWithRecComputation.java

Changeset: 3a3803a0c789
Author:    aph
Date:      2020-04-03 14:14 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3a3803a0c789

8076475: Misuses of strncpy/strncat
Summary: Various small fixes around strncpy and strncat
Reviewed-by: andrew

! agent/src/os/bsd/libproc_impl.c
! agent/src/os/linux/libproc_impl.c
! src/os/bsd/dtrace/libjvm_db.c
! src/os/bsd/vm/decoder_machO.cpp
! src/os/solaris/dtrace/libjvm_db.c
! src/share/tools/hsdis/hsdis.c
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: 9cbafea410f5
Author:    andrew
Date:      2020-05-25 07:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9cbafea410f5

Added tag jdk8u262-b04 for changeset 3a3803a0c789

! .hgtags

Changeset: 8f8b4e73e488
Author:    andrew
Date:      2020-05-26 03:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8f8b4e73e488

Merge jdk8u262-b04

! .hgtags
! src/share/tools/hsdis/hsdis.c
! src/share/vm/classfile/classLoaderStats.hpp
! src/share/vm/compiler/compileBroker.hpp
! src/share/vm/compiler/disassembler.cpp
! src/share/vm/runtime/arguments.cpp
! src/share/vm/utilities/ostream.cpp
! src/share/vm/utilities/vmError.cpp

Changeset: 1ac56046129c
Author:    andrew
Date:      2020-05-26 03:05 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/1ac56046129c

Added tag aarch64-shenandoah-jdk8u262-b04 for changeset 8f8b4e73e488

! .hgtags

Changeset: f7691a80458c
Author:    fyang
Date:      2020-05-25 14:24 +0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f7691a80458c

8244407: JVM crashes after transformation in C2 IdealLoopTree::split_fall_in
Reviewed-by: thartmann, kvn, andrew
Contributed-by: zhouyong44 at huawei.com

! src/share/vm/opto/loopnode.cpp
+ test/compiler/loopopts/TestBeautifyLoops_2.java

Changeset: de6565b66f94
Author:    andrew
Date:      2020-06-01 14:46 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/de6565b66f94

Added tag jdk8u262-b05 for changeset f7691a80458c

! .hgtags

Changeset: 082fad85c036
Author:    andrew
Date:      2020-06-02 05:10 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/082fad85c036

Merge jdk8u262-b05

! .hgtags
! src/share/vm/opto/loopnode.cpp

Changeset: 1ffe5ca34ef7
Author:    andrew
Date:      2020-06-02 05:12 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/1ffe5ca34ef7

Added tag aarch64-shenandoah-jdk8u262-b05 for changeset 082fad85c036

! .hgtags

Changeset: 963a9097e533
Author:    shade
Date:      2020-06-04 19:24 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/963a9097e533

8246482: Build failures with +JFR -PCH
Reviewed-by: aph

! src/share/vm/jfr/writers/jfrEncoders.hpp

Changeset: ed044fa3f6e3
Author:    shade
Date:      2020-06-04 19:38 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ed044fa3f6e3

Merge

- src/share/vm/gc_implementation/shared/parallelCleaning.cpp
- src/share/vm/gc_implementation/shared/parallelCleaning.hpp
- src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp
- src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.hpp
- src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.cpp
- src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.hpp
- src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp
- src/share/vm/gc_implementation/shenandoah/shenandoahSupport.hpp
! src/share/vm/opto/loopnode.cpp
! src/share/vm/opto/node.cpp
! src/share/vm/runtime/arguments.cpp

Changeset: 86a87ce31ccb
Author:    shade
Date:      2020-06-04 19:39 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/86a87ce31ccb

Added tag aarch64-shenandoah-jdk8u262-b05-shenandoah-merge-2020-06-04 for changeset ed044fa3f6e3

! .hgtags


From shade at redhat.com  Thu Jun  4 19:13:15 2020
From: shade at redhat.com (shade at redhat.com)
Date: Thu, 04 Jun 2020 19:13:15 +0000
Subject: hg: shenandoah/jdk8/jaxws: 13 new changesets
Message-ID: <202006041913.054JDFcg000677@aojmv0008.oracle.com>

Changeset: a708c11c582d
Author:    serb
Date:      2019-12-02 16:38 -0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/a708c11c582d

8230597: Update GIFlib library to the 5.2.1
Reviewed-by: prr, psadhukhan, jdv

! THIRD_PARTY_README

Changeset: caa13cd34f71
Author:    andrew
Date:      2020-05-19 05:11 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/caa13cd34f71

Added tag jdk8u262-b03 for changeset a708c11c582d

! .hgtags

Changeset: b8efdaabe444
Author:    andrew
Date:      2020-05-20 01:04 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/b8efdaabe444

Merge jdk8u262-b03

! .hgtags
! THIRD_PARTY_README

Changeset: d1d3a043b329
Author:    andrew
Date:      2020-05-20 01:04 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/d1d3a043b329

Added tag aarch64-shenandoah-jdk8u262-b03 for changeset b8efdaabe444

! .hgtags

Changeset: 794b416205fe
Author:    andrew
Date:      2020-05-24 18:50 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/794b416205fe

Merge shenandoah-merge-2020-05-20

! .hgtags

Changeset: 654c6d651801
Author:    andrew
Date:      2020-05-24 19:02 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/654c6d651801

Added tag aarch64-shenandoah-jdk8u262-b03-shenandoah-merge-2020-05-20 for changeset 794b416205fe

! .hgtags

Changeset: 96946cef7ead
Author:    andrew
Date:      2020-05-25 07:02 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/96946cef7ead

Added tag jdk8u262-b04 for changeset caa13cd34f71

! .hgtags

Changeset: 4f3049a38b17
Author:    andrew
Date:      2020-05-26 03:02 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/4f3049a38b17

Merge jdk8u262-b04

! .hgtags

Changeset: 504a12b89363
Author:    andrew
Date:      2020-05-26 03:04 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/504a12b89363

Added tag aarch64-shenandoah-jdk8u262-b04 for changeset 4f3049a38b17

! .hgtags

Changeset: 0e54ba3037a2
Author:    andrew
Date:      2020-06-01 14:46 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/0e54ba3037a2

Added tag jdk8u262-b05 for changeset 96946cef7ead

! .hgtags

Changeset: 702483d5017a
Author:    andrew
Date:      2020-06-02 05:09 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/702483d5017a

Merge jdk8u262-b05

! .hgtags

Changeset: 3bf12ab76730
Author:    andrew
Date:      2020-06-02 05:12 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/3bf12ab76730

Added tag aarch64-shenandoah-jdk8u262-b05 for changeset 702483d5017a

! .hgtags

Changeset: fba6ea0cc30d
Author:    shade
Date:      2020-06-04 19:39 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/fba6ea0cc30d

Added tag aarch64-shenandoah-jdk8u262-b05-shenandoah-merge-2020-06-04 for changeset 3bf12ab76730

! .hgtags


From shade at redhat.com  Thu Jun  4 19:13:24 2020
From: shade at redhat.com (shade at redhat.com)
Date: Thu, 04 Jun 2020 19:13:24 +0000
Subject: hg: shenandoah/jdk8/nashorn: 14 new changesets
Message-ID: <202006041913.054JDOFv001022@aojmv0008.oracle.com>

Changeset: 0b39fe441888
Author:    serb
Date:      2019-12-02 16:38 -0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/0b39fe441888

8230597: Update GIFlib library to the 5.2.1
Reviewed-by: prr, psadhukhan, jdv

! THIRD_PARTY_README

Changeset: f5a3d8f60cf5
Author:    andrew
Date:      2020-05-19 05:11 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/f5a3d8f60cf5

Added tag jdk8u262-b03 for changeset 0b39fe441888

! .hgtags

Changeset: 4faa3f022f0c
Author:    andrew
Date:      2020-05-20 01:04 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/4faa3f022f0c

Merge jdk8u262-b03

! .hgtags
! THIRD_PARTY_README

Changeset: a71e6d72fe79
Author:    andrew
Date:      2020-05-20 01:04 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/a71e6d72fe79

Added tag aarch64-shenandoah-jdk8u262-b03 for changeset 4faa3f022f0c

! .hgtags

Changeset: 367a20dd337f
Author:    andrew
Date:      2020-05-24 18:50 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/367a20dd337f

Merge shenandoah-merge-2020-05-20

! .hgtags

Changeset: 51b68bf696a9
Author:    andrew
Date:      2020-05-24 19:02 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/51b68bf696a9

Added tag aarch64-shenandoah-jdk8u262-b03-shenandoah-merge-2020-05-20 for changeset 367a20dd337f

! .hgtags

Changeset: eef87c0da03e
Author:    fyang
Date:      2020-05-24 22:47 +0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/eef87c0da03e

8171934: ObjectSizeCalculator.getEffectiveMemoryLayoutSpecification() does not recognize OpenJDK's HotSpot VM
Reviewed-by: aph, andrew
Contributed-by: hedongbo at huawei.com

! src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java

Changeset: e2a7c53cfa4d
Author:    andrew
Date:      2020-05-25 07:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/e2a7c53cfa4d

Added tag jdk8u262-b04 for changeset eef87c0da03e

! .hgtags

Changeset: 04674a70f346
Author:    andrew
Date:      2020-05-26 03:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/04674a70f346

Merge jdk8u262-b04

! .hgtags

Changeset: 57e806de4194
Author:    andrew
Date:      2020-05-26 03:04 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/57e806de4194

Added tag aarch64-shenandoah-jdk8u262-b04 for changeset 04674a70f346

! .hgtags

Changeset: f6630163b3a2
Author:    andrew
Date:      2020-06-01 14:46 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/f6630163b3a2

Added tag jdk8u262-b05 for changeset e2a7c53cfa4d

! .hgtags

Changeset: 3750c5415bfb
Author:    andrew
Date:      2020-06-02 05:09 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/3750c5415bfb

Merge jdk8u262-b05

! .hgtags

Changeset: 7d79994efe2a
Author:    andrew
Date:      2020-06-02 05:12 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/7d79994efe2a

Added tag aarch64-shenandoah-jdk8u262-b05 for changeset 3750c5415bfb

! .hgtags

Changeset: 8b2025210165
Author:    shade
Date:      2020-06-04 19:39 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/8b2025210165

Added tag aarch64-shenandoah-jdk8u262-b05-shenandoah-merge-2020-06-04 for changeset 7d79994efe2a

! .hgtags


From zgu at redhat.com  Thu Jun  4 20:08:10 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 4 Jun 2020 16:08:10 -0400
Subject: [15] RFR 8246593: Shenandoah: string dedup roots should be processed
 during concurrent weak roots phase
Message-ID: <181dc5ec-64b9-32d3-3c86-3e62e9aa6f02@redhat.com>

String dedup roots are weak roots, they are mistakenly placed as strong 
roots during weak/strong roots split (JDK-8242643).

This patch moves string dedup roots from concurrent strong roots to 
concurrent weak roots.

Bug: https://bugs.openjdk.java.net/browse/JDK-8246593
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246593/webrev.00/

Test:
   hotspot_gc_shenandoah with -XX:+UseStringDeduplication

Thanks,

-Zhengyu


From shade at redhat.com  Thu Jun  4 21:15:44 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Jun 2020 23:15:44 +0200
Subject: [15] RFR 8246593: Shenandoah: string dedup roots should be
 processed during concurrent weak roots phase
In-Reply-To: <181dc5ec-64b9-32d3-3c86-3e62e9aa6f02@redhat.com>
References: <181dc5ec-64b9-32d3-3c86-3e62e9aa6f02@redhat.com>
Message-ID: <ce908f27-1cb2-1654-726d-b6da56de103c@redhat.com>

On 6/4/20 10:08 PM, Zhengyu Gu wrote:
> String dedup roots are weak roots, they are mistakenly placed as strong 
> roots during weak/strong roots split (JDK-8242643).
> 
> This patch moves string dedup roots from concurrent strong roots to 
> concurrent weak roots.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246593
> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246593/webrev.00/

OK, good!

-- 
-Aleksey


From shade at redhat.com  Fri Jun  5 08:14:06 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 5 Jun 2020 10:14:06 +0200
Subject: Shenandoah 8u262+ release candidate
Message-ID: <820dcbbb-320f-e2d8-41cd-ad552980c471@redhat.com>

Hi,

We are pleased to announce that most of the recent bugfixes and improvements have been backported to
Shenandoah 8u tree. That tree is based on upstream OpenJDK 8u262+ project, and Shenandoah-enabled
downstream distributions should be released at the same time with 8u262 release, in mid-April.

Since we do not expect more non-critical backports until that release happens, what we have in
Shenandoah 8u tree is now the Release Candidate. Please test! Next 1..3 weeks are the perfect time
to identify problems with it and put in critical fixes that would land in April release.

As usual, you can try it by:
 a) Building from source yourself: https://hg.openjdk.java.net/shenandoah/jdk8/
 b) Taking our nightly builds: https://builds.shipilev.net/openjdk-shenandoah-jdk8/
 c) Using the Docker containers with nightly builds: shipilev/openjdk-shenandoah:8

Enjoy!

-- 
Thanks,
-Aleksey



From zgu at redhat.com  Tue Jun  9 12:14:35 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 9 Jun 2020 08:14:35 -0400
Subject: [15] RFR 8246591: Shenandoah: move string dedup roots scanning to
 concurrent phase
Message-ID: <bd24ff8d-320f-af6a-7c85-898f444501b8@redhat.com>

Please review this patch that moves string deduplication roots scanning 
to concurrent phase.

Bug: https://bugs.openjdk.java.net/browse/JDK-8246591
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246591/webrev.00/

Test:
   hotspot_gc_shenandoah
   tier1 with "-XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions 
-XX:+ShenandoahVerify -XX:+UseStringDeduplication"

Thanks,

-Zhengyu


From shade at redhat.com  Wed Jun 10 06:53:17 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 10 Jun 2020 08:53:17 +0200
Subject: [15] RFR 8246591: Shenandoah: move string dedup roots scanning to
 concurrent phase
In-Reply-To: <bd24ff8d-320f-af6a-7c85-898f444501b8@redhat.com>
References: <bd24ff8d-320f-af6a-7c85-898f444501b8@redhat.com>
Message-ID: <7bad54a4-d6f0-15bd-cd84-bad71ad3e9bd@redhat.com>

On 6/9/20 2:14 PM, Zhengyu Gu wrote:
> Please review this patch that moves string deduplication roots scanning 
> to concurrent phase.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246591
> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246591/webrev.00/

Looks fine.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Jun 10 08:56:16 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 10 Jun 2020 10:56:16 +0200
Subject: RFR (S) 8247310: Shenandoah: pacer should not affect interrupt status
Message-ID: <686314f1-d202-025a-bd88-3951d10dbf53@redhat.com>

Bug:
  https://bugs.openjdk.java.net/browse/JDK-8247310

This was originally found by Aditya Mandaleeka when running sh/jdk11 tests, kudos goes to him for
analysing it. See the details in the bug report.

Fix:
  https://cr.openjdk.java.net/~shade/8247310/webrev.01/

Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Wed Jun 10 12:41:01 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 10 Jun 2020 08:41:01 -0400
Subject: RFR (S) 8247310: Shenandoah: pacer should not affect interrupt
 status
In-Reply-To: <686314f1-d202-025a-bd88-3951d10dbf53@redhat.com>
References: <686314f1-d202-025a-bd88-3951d10dbf53@redhat.com>
Message-ID: <708b11b1-b9ea-1b87-fc54-e134394a8514@redhat.com>

Looks fine.

-Zhengyu

On 6/10/20 4:56 AM, Aleksey Shipilev wrote:
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8247310
> 
> This was originally found by Aditya Mandaleeka when running sh/jdk11 tests, kudos goes to him for
> analysing it. See the details in the bug report.
> 
> Fix:
>    https://cr.openjdk.java.net/~shade/8247310/webrev.01/
> 
> Testing: hotspot_gc_shenandoah
> 


From shade at redhat.com  Wed Jun 10 14:06:17 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 10 Jun 2020 16:06:17 +0200
Subject: RFR (S) 8247310: Shenandoah: pacer should not affect interrupt
 status
In-Reply-To: <708b11b1-b9ea-1b87-fc54-e134394a8514@redhat.com>
References: <686314f1-d202-025a-bd88-3951d10dbf53@redhat.com>
 <708b11b1-b9ea-1b87-fc54-e134394a8514@redhat.com>
Message-ID: <bd7aff4f-6613-8987-a70b-9509fdbe18bc@redhat.com>

On 6/10/20 2:41 PM, Zhengyu Gu wrote:
> Looks fine.

Cheers, pushed.

-- 
-Aleksey


From zgu at redhat.com  Wed Jun 10 14:09:13 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 10 Jun 2020 10:09:13 -0400
Subject: [sh/jdk8u] RFR Shenandoah: missing SystemDictionary roots in
 ShenandoahHeapIterationRootScanner
Message-ID: <3987a791-71e8-31e9-0079-07a39fca1dd7@redhat.com>

Please review this patch that adds SystemDictionaryRoots to 
ShenandoahHeapIterationRootScanner. It appears to be the cause of recent 
TCK 8 test failures.

Webrev: 
http://cr.openjdk.java.net/~zgu/shenandoah/heap_itr_scanner/webrev.00/index.html

Test:
   hotspot_gc_shenandoah

   Imported Xin Liu's vmTestbase 8u backport, ran vmTestbase/nsk/jdi
   test. Reproducible before the patch and passed afterward.

Thanks,

-Zhengyu


From shade at redhat.com  Wed Jun 10 14:12:39 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 10 Jun 2020 16:12:39 +0200
Subject: [sh/jdk8u] RFR Shenandoah: missing SystemDictionary roots in
 ShenandoahHeapIterationRootScanner
In-Reply-To: <3987a791-71e8-31e9-0079-07a39fca1dd7@redhat.com>
References: <3987a791-71e8-31e9-0079-07a39fca1dd7@redhat.com>
Message-ID: <c0b93f46-9c45-26b7-5302-fb44c3c321ef@redhat.com>

On 6/10/20 4:09 PM, Zhengyu Gu wrote:
> Please review this patch that adds SystemDictionaryRoots to 
> ShenandoahHeapIterationRootScanner. It appears to be the cause of recent 
> TCK 8 test failures.
> 
> Webrev: 
> http://cr.openjdk.java.net/~zgu/shenandoah/heap_itr_scanner/webrev.00/index.html

*) Indenting nit at L190 here:

 189   ShenandoahSerialRoots                                    _serial_roots;
 190   ShenandoahSystemDictionaryRoots _dict_roots;
 191   ShenandoahThreadRoots                                    _thread_roots;

This is 8u specific, right?

If so, looks good!

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Wed Jun 10 14:46:07 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 10 Jun 2020 10:46:07 -0400
Subject: [sh/jdk8u] RFR Shenandoah: missing SystemDictionary roots in
 ShenandoahHeapIterationRootScanner
In-Reply-To: <c0b93f46-9c45-26b7-5302-fb44c3c321ef@redhat.com>
References: <3987a791-71e8-31e9-0079-07a39fca1dd7@redhat.com>
 <c0b93f46-9c45-26b7-5302-fb44c3c321ef@redhat.com>
Message-ID: <003c1345-8b4f-2044-acc3-efd8d89b0f7c@redhat.com>



On 6/10/20 10:12 AM, Aleksey Shipilev wrote:
> On 6/10/20 4:09 PM, Zhengyu Gu wrote:
>> Please review this patch that adds SystemDictionaryRoots to
>> ShenandoahHeapIterationRootScanner. It appears to be the cause of recent
>> TCK 8 test failures.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~zgu/shenandoah/heap_itr_scanner/webrev.00/index.html
> 
> *) Indenting nit at L190 here:
> 
>   189   ShenandoahSerialRoots                                    _serial_roots;
>   190   ShenandoahSystemDictionaryRoots _dict_roots;
>   191   ShenandoahThreadRoots                                    _thread_roots

Fixed.

> 
> This is 8u specific, right?

Yes. It is 8u specific.

Thanks for the quick review. Pushed.

-Zhengyu

> 
> If so, looks good!
> 


From zgu at redhat.com  Wed Jun 10 14:45:12 2020
From: zgu at redhat.com (zgu at redhat.com)
Date: Wed, 10 Jun 2020 14:45:12 +0000
Subject: hg: shenandoah/jdk8/hotspot: Shenandoah: missing SystemDictionary
 roots in ShenandoahHeapIterationRootScanner
Message-ID: <202006101445.05AEjCFV022955@aojmv0008.oracle.com>

Changeset: 4526d0272113
Author:    zgu
Date:      2020-06-10 10:43 -0400
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/4526d0272113

Shenandoah: missing SystemDictionary roots in ShenandoahHeapIterationRootScanner
Reviewed-by: shade

! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp
! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp


From zgu at redhat.com  Wed Jun 10 15:39:56 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 10 Jun 2020 11:39:56 -0400
Subject: [sh/jdk8u] RFR Shenandoah: add JFR roots to root processor after JFR
 integration
Message-ID: <52f88c7a-f537-ff4e-ab5c-2e27cb9f2912@redhat.com>

There was no JFR when Shenandoah root processing was backported, 
therefore, JFR root is missing.


Webrev: 
http://cr.openjdk.java.net/~zgu/shenandoah/jfr_root_processing/webrev.00/index.html

Test:
   hotspot_gc_shenandoah (+/- JFR)

Thanks,

-Zhengyu


From shade at redhat.com  Wed Jun 10 16:35:18 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 10 Jun 2020 18:35:18 +0200
Subject: [sh/jdk8u] RFR Shenandoah: add JFR roots to root processor after
 JFR integration
In-Reply-To: <52f88c7a-f537-ff4e-ab5c-2e27cb9f2912@redhat.com>
References: <52f88c7a-f537-ff4e-ab5c-2e27cb9f2912@redhat.com>
Message-ID: <c3fc02f5-1f61-5317-c976-5ad820ee59bc@redhat.com>

On 6/10/20 5:39 PM, Zhengyu Gu wrote:
> Webrev: 
> http://cr.openjdk.java.net/~zgu/shenandoah/jfr_root_processing/webrev.00/index.html

Looks fine, nits below:

*) Any reason not to use JFR_ONLY here?

 141 ShenandoahWeakRoots::ShenandoahWeakRoots(ShenandoahPhaseTimings::Phase phase) :
 142 #if INCLUDE_JFR
 143   _jfr_weak_roots(phase, ShenandoahPhaseTimings::JFRWeakRoots, &LeakProfiler::oops_do),
 144 #endif // INCLUDE_JFR
 145   _jni_weak_roots(phase, ShenandoahPhaseTimings::JNIWeakRoots, &JNIHandles::weak_oops_do) {
 146 }


*) I was under impression that when you use #if for some global macro, you need to #include
"utilities/macros.hpp".

So...

> Test:
>    hotspot_gc_shenandoah (+/- JFR)

...try with -PCH?


-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Jun 10 17:03:18 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 10 Jun 2020 19:03:18 +0200
Subject: RFC: Pick up 11.0.8+7 to sh/jdk11
Message-ID: <3ddd698b-aa2e-4831-536f-58cbd7572795@redhat.com>

Upstream had published 11.0.8+7, let's pick it up to sh/jdk11.

Merge is trivial. I would tag it shenandoah-jdk-11.0.8+7 right away.

Testing: hotspot_gc_shenandoah {fastdebug, release}

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Wed Jun 10 17:48:56 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 10 Jun 2020 13:48:56 -0400
Subject: RFC: Pick up 11.0.8+7 to sh/jdk11
In-Reply-To: <3ddd698b-aa2e-4831-536f-58cbd7572795@redhat.com>
References: <3ddd698b-aa2e-4831-536f-58cbd7572795@redhat.com>
Message-ID: <629673bb-0843-dcce-79d4-8a093612a1c4@redhat.com>

Okay.

-Zhengyu

On 6/10/20 1:03 PM, Aleksey Shipilev wrote:
> Upstream had published 11.0.8+7, let's pick it up to sh/jdk11.
> 
> Merge is trivial. I would tag it shenandoah-jdk-11.0.8+7 right away.
> 
> Testing: hotspot_gc_shenandoah {fastdebug, release}
> 


From zgu at redhat.com  Wed Jun 10 17:55:15 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 10 Jun 2020 13:55:15 -0400
Subject: [sh/jdk8u] RFR Shenandoah: add JFR roots to root processor after
 JFR integration
In-Reply-To: <c3fc02f5-1f61-5317-c976-5ad820ee59bc@redhat.com>
References: <52f88c7a-f537-ff4e-ab5c-2e27cb9f2912@redhat.com>
 <c3fc02f5-1f61-5317-c976-5ad820ee59bc@redhat.com>
Message-ID: <d450df1a-d263-a99c-edd4-3b1181ab58bd@redhat.com>

Hi Aleksey,

On 6/10/20 12:35 PM, Aleksey Shipilev wrote:
> On 6/10/20 5:39 PM, Zhengyu Gu wrote:
>> Webrev:
>> http://cr.openjdk.java.net/~zgu/shenandoah/jfr_root_processing/webrev.00/index.html
> 
> Looks fine, nits below:
> 
> *) Any reason not to use JFR_ONLY here?
> 
>   141 ShenandoahWeakRoots::ShenandoahWeakRoots(ShenandoahPhaseTimings::Phase phase) :
>   142 #if INCLUDE_JFR
>   143   _jfr_weak_roots(phase, ShenandoahPhaseTimings::JFRWeakRoots, &LeakProfiler::oops_do),
>   144 #endif // INCLUDE_JFR
>   145   _jni_weak_roots(phase, ShenandoahPhaseTimings::JNIWeakRoots, &JNIHandles::weak_oops_do) {
>   146 }

Compiler does not like, it thinks JFR_ONLY is a member variable.

> 
> 
> *) I was under impression that when you use #if for some global macro, you need to #include
> "utilities/macros.hpp".

PCH and non-PCH builds are happy without it, but add the header anyway.

Pushed.

Thanks,

-Zhengyu

> 
> So...
> 
>> Test:
>>     hotspot_gc_shenandoah (+/- JFR)
> 
> ...try with -PCH?
> 
> 


From shade at redhat.com  Wed Jun 10 17:59:51 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 10 Jun 2020 19:59:51 +0200
Subject: [sh/jdk8u] RFR Shenandoah: add JFR roots to root processor after
 JFR integration
In-Reply-To: <d450df1a-d263-a99c-edd4-3b1181ab58bd@redhat.com>
References: <52f88c7a-f537-ff4e-ab5c-2e27cb9f2912@redhat.com>
 <c3fc02f5-1f61-5317-c976-5ad820ee59bc@redhat.com>
 <d450df1a-d263-a99c-edd4-3b1181ab58bd@redhat.com>
Message-ID: <349cd313-1fe3-67e8-764b-3be62f757d6f@redhat.com>

On 6/10/20 7:55 PM, Zhengyu Gu wrote:
> On 6/10/20 12:35 PM, Aleksey Shipilev wrote:
>> On 6/10/20 5:39 PM, Zhengyu Gu wrote:
>>> Webrev:
>>> http://cr.openjdk.java.net/~zgu/shenandoah/jfr_root_processing/webrev.00/index.html
>>
>> Looks fine, nits below:
>>
>> *) Any reason not to use JFR_ONLY here?
>>
>>   141 ShenandoahWeakRoots::ShenandoahWeakRoots(ShenandoahPhaseTimings::Phase phase) :
>>   142 #if INCLUDE_JFR
>>   143   _jfr_weak_roots(phase, ShenandoahPhaseTimings::JFRWeakRoots, &LeakProfiler::oops_do),
>>   144 #endif // INCLUDE_JFR
>>   145   _jni_weak_roots(phase, ShenandoahPhaseTimings::JNIWeakRoots, &JNIHandles::weak_oops_do) {
>>   146 }
> 
> Compiler does not like, it thinks JFR_ONLY is a member variable.

Whoa. But that is a smoking gun that macro is undefined (due to missing #include), right?

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Wed Jun 10 17:54:59 2020
From: zgu at redhat.com (zgu at redhat.com)
Date: Wed, 10 Jun 2020 17:54:59 +0000
Subject: hg: shenandoah/jdk8/hotspot: Shenandoah: add JFR roots to root
 processor after JFR integration
Message-ID: <202006101755.05AHt0Ix005896@aojmv0008.oracle.com>

Changeset: ca85aabcaa4c
Author:    zgu
Date:      2020-06-10 13:54 -0400
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ca85aabcaa4c

Shenandoah: add JFR roots to root processor after JFR integration
Reviewed-by: shade

! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp
! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp


From shade at redhat.com  Wed Jun 10 17:55:12 2020
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 10 Jun 2020 17:55:12 +0000
Subject: hg: shenandoah/jdk11: 6 new changesets
Message-ID: <202006101755.05AHtDaa006074@aojmv0008.oracle.com>

Changeset: a3de868a8849
Author:    xuelei
Date:      2020-04-22 10:51 -0700
URL:       https://hg.openjdk.java.net/shenandoah/jdk11/rev/a3de868a8849

8242141: New System Properties to configure the TLS signature schemes
Reviewed-by: ascarpino, jnimeh, mullan

! src/java.base/share/classes/sun/security/ssl/CertSignAlgsExtension.java
! src/java.base/share/classes/sun/security/ssl/CertificateRequest.java
! src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java
! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
! src/java.base/share/classes/sun/security/ssl/SSLServerSocketImpl.java
! src/java.base/share/classes/sun/security/ssl/ServerHello.java
! src/java.base/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java
! src/java.base/share/classes/sun/security/ssl/SignatureScheme.java
! src/java.base/share/classes/sun/security/ssl/TransportContext.java
+ test/jdk/sun/security/ssl/SignatureScheme/CustomizedClientSchemes.java
+ test/jdk/sun/security/ssl/SignatureScheme/CustomizedServerSchemes.java

Changeset: 0c063ac4c41a
Author:    robm
Date:      2019-01-10 07:54 -0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk11/rev/0c063ac4c41a

8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate"
Reviewed-by: vtewari, xuelei

! src/java.naming/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java

Changeset: 46d4984bb3c6
Author:    rhalade
Date:      2020-05-01 11:09 -0700
URL:       https://hg.openjdk.java.net/shenandoah/jdk11/rev/46d4984bb3c6

8225069: Remove Comodo root certificate that is expiring in May 2020
Reviewed-by: mullan

- make/data/cacerts/addtrustclass1ca
! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: 6aa55a45ff6f
Author:    goetz
Date:      2020-06-10 09:37 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk11/rev/6aa55a45ff6f

Added tag jdk-11.0.8+7 for changeset 46d4984bb3c6

! .hgtags

Changeset: f8a2f1432198
Author:    shade
Date:      2020-06-10 18:23 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk11/rev/f8a2f1432198

Merge

! .hgtags
- make/data/cacerts/addtrustclass1ca

Changeset: 6f061b5c6755
Author:    shade
Date:      2020-06-10 18:24 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk11/rev/6f061b5c6755

Added tag shenandoah-jdk-11.0.8+7 for changeset f8a2f1432198

! .hgtags


From shade at redhat.com  Wed Jun 10 18:06:42 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 10 Jun 2020 20:06:42 +0200
Subject: RFC: Pick up 11.0.8+7 to sh/jdk11
In-Reply-To: <629673bb-0843-dcce-79d4-8a093612a1c4@redhat.com>
References: <3ddd698b-aa2e-4831-536f-58cbd7572795@redhat.com>
 <629673bb-0843-dcce-79d4-8a093612a1c4@redhat.com>
Message-ID: <1969a359-3b06-110e-da78-14ebf5c8d29b@redhat.com>

On 6/10/20 7:48 PM, Zhengyu Gu wrote:
> Okay.

Pushed.

-- 
-Aleksey


From gnu.andrew at redhat.com  Wed Jun 10 20:29:49 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 10 Jun 2020 21:29:49 +0100
Subject: [RFR] [8u] 8u262-b06 Upstream Sync
Message-ID: <8c66b7c0-113f-2996-14fd-4135a74d8442@redhat.com>

Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/

Merge changesets:
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/corba/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/jaxp/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/jaxws/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/hotspot/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/langtools/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/nashorn/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/root/merge.changeset

Changes in aarch64-shenandoah-jdk8u262-b06:
  - JDK-8246223: Windows build fails after JDK-8227269

Main issues of note:
None, clean merge. Things should be quieter now, as we're in rampdown
for 8u262.

diffstat for root
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

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/src/share/back/classTrack.c |   20 +++++++++++---------
 2 files changed, 12 insertions(+), 9 deletions(-)

diffstat for hotspot
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

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


From shade at redhat.com  Thu Jun 11 08:47:53 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 11 Jun 2020 10:47:53 +0200
Subject: RFR (XS) 8247358: Shenandoah: reconsider free budget slice for marking
Message-ID: <c86d33d0-0820-6cf9-7aca-98f18eb3ce4b@redhat.com>

RFE:
  https://bugs.openjdk.java.net/browse/JDK-8247358

See the details in JIRA.

Fix:
  https://cr.openjdk.java.net/~shade/8247358/webrev.01/

Testing: hotspot_gc_shenandoah, benchmarks

-- 
Thanks,
-Aleksey


From shade at redhat.com  Thu Jun 11 08:49:43 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 11 Jun 2020 10:49:43 +0200
Subject: RFR (S) 8247367: Shenandoah: pacer should wait on lock instead of
 exponential backoff
Message-ID: <7e2fa715-211a-4459-f20d-1075afeec180@redhat.com>

RFE:
  https://bugs.openjdk.java.net/browse/JDK-8247367

After JDK-8247310, we can just use the wait/notify on the newly introduced lock to coordinate
wakeups of paced threads. This avoids doing exponential backoff that introduces additional latency.

Fix:
  https://cr.openjdk.java.net/~shade/8247367/webrev.01/

Testing: hotspot_gc_shenandoah; benchmarks

-- 
Thanks,
-Aleksey


From shade at redhat.com  Thu Jun 11 08:55:46 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 11 Jun 2020 10:55:46 +0200
Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b06 Upstream Sync
In-Reply-To: <8c66b7c0-113f-2996-14fd-4135a74d8442@redhat.com>
References: <8c66b7c0-113f-2996-14fd-4135a74d8442@redhat.com>
Message-ID: <d895a19d-5f0b-a7dd-984d-e2c05c3f28e6@redhat.com>

On 6/10/20 10:29 PM, Andrew Hughes wrote:
> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/
> 
> Merge changesets:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/jaxws/merge.changeset

Look trivially good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset

Looks good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/hotspot/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/langtools/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/nashorn/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/root/merge.changeset

Look trivially good.

> Ok to push?

Yes!

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Thu Jun 11 12:38:27 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 11 Jun 2020 08:38:27 -0400
Subject: RFR (XS) 8247358: Shenandoah: reconsider free budget slice for
 marking
In-Reply-To: <c86d33d0-0820-6cf9-7aca-98f18eb3ce4b@redhat.com>
References: <c86d33d0-0820-6cf9-7aca-98f18eb3ce4b@redhat.com>
Message-ID: <ef1e5b2c-e0d8-fa5f-70dc-d7c9441be440@redhat.com>

Okay.

-Zhengyu

On 6/11/20 4:47 AM, Aleksey Shipilev wrote:
> RFE:
>    https://bugs.openjdk.java.net/browse/JDK-8247358
> 
> See the details in JIRA.
> 
> Fix:
>    https://cr.openjdk.java.net/~shade/8247358/webrev.01/
> 
> Testing: hotspot_gc_shenandoah, benchmarks
> 


From zgu at redhat.com  Thu Jun 11 13:12:02 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 11 Jun 2020 09:12:02 -0400
Subject: RFR (S) 8247367: Shenandoah: pacer should wait on lock instead of
 exponential backoff
In-Reply-To: <7e2fa715-211a-4459-f20d-1075afeec180@redhat.com>
References: <7e2fa715-211a-4459-f20d-1075afeec180@redhat.com>
Message-ID: <8d1b7ef4-427b-9460-0ec7-70a05b7738fc@redhat.com>

Looks good.

-Zhengyu

On 6/11/20 4:49 AM, Aleksey Shipilev wrote:
> RFE:
>    https://bugs.openjdk.java.net/browse/JDK-8247367
> 
> After JDK-8247310, we can just use the wait/notify on the newly introduced lock to coordinate
> wakeups of paced threads. This avoids doing exponential backoff that introduces additional latency.
> 
> Fix:
>    https://cr.openjdk.java.net/~shade/8247367/webrev.01/
> 
> Testing: hotspot_gc_shenandoah; benchmarks
> 


From aleksey.shipilev at gmail.com  Fri Jun 12 10:52:29 2020
From: aleksey.shipilev at gmail.com (Aleksey Shipilev)
Date: Fri, 12 Jun 2020 12:52:29 +0200
Subject: [15] RFR (XS) 8247474: Shenandoah: Windows build warning after
 JDK-8247310
Message-ID: <bd506130-568d-8052-55de-28090d06ab61@gmail.com>

Bug:
  https://bugs.openjdk.java.net/browse/JDK-8247474

Since the underlying cause is the changeset in 15, I am planning to push it to jdk/jdk15.

Fix:

diff -r a39eb5a4f1c1 src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp       Thu Jun 11 18:16:32 2020 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp       Fri Jun 12 12:38:30 2020 +0200
@@ -279,10 +279,11 @@
 }

-void ShenandoahPacer::wait(long time_ms) {
+void ShenandoahPacer::wait(size_t time_ms) {
   // Perform timed wait. It works like like sleep(), except without modifying
   // the thread interruptible status. MonitorLocker also checks for safepoints.
   assert(time_ms > 0, "Should not call this with zero argument, as it would stall until notify");
+  assert(time_ms <= LONG_MAX, "Sanity");
   MonitorLocker locker(_wait_monitor);
-  _wait_monitor->wait(time_ms);
+  _wait_monitor->wait((long)time_ms);
 }

diff -r a39eb5a4f1c1 src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp       Thu Jun 11 18:16:32 2020 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp       Fri Jun 12 12:38:30 2020 +0200
@@ -102,5 +102,5 @@
   size_t update_and_get_progress_history();

-  void wait(long time_ms);
+  void wait(size_t time_ms);
   void notify_waiters();
 };


Testing: Linux, Windows builds; hotspot_gc_shenandoah

Thanks,
-Aleksey


From shade at redhat.com  Fri Jun 12 10:56:18 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 12 Jun 2020 12:56:18 +0200
Subject: [15] RFR (XS) 8247474: Shenandoah: Windows build warning after
 JDK-8247310
Message-ID: <378c703d-3e8c-4550-241b-e44adb111638@redhat.com>

(resending from proper email)

Bug:
  https://bugs.openjdk.java.net/browse/JDK-8247474

Since the underlying cause is the changeset in 15, I am planning to push it to jdk/jdk15.

Fix:

diff -r a39eb5a4f1c1 src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp       Thu Jun 11 18:16:32 2020 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp       Fri Jun 12 12:38:30 2020 +0200
@@ -279,10 +279,11 @@
 }

-void ShenandoahPacer::wait(long time_ms) {
+void ShenandoahPacer::wait(size_t time_ms) {
   // Perform timed wait. It works like like sleep(), except without modifying
   // the thread interruptible status. MonitorLocker also checks for safepoints.
   assert(time_ms > 0, "Should not call this with zero argument, as it would stall until notify");
+  assert(time_ms <= LONG_MAX, "Sanity");
   MonitorLocker locker(_wait_monitor);
-  _wait_monitor->wait(time_ms);
+  _wait_monitor->wait((long)time_ms);
 }

diff -r a39eb5a4f1c1 src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp       Thu Jun 11 18:16:32 2020 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp       Fri Jun 12 12:38:30 2020 +0200
@@ -102,5 +102,5 @@
   size_t update_and_get_progress_history();

-  void wait(long time_ms);
+  void wait(size_t time_ms);
   void notify_waiters();
 };


Testing: Linux, Windows builds; hotspot_gc_shenandoah

Thanks,
-Aleksey


From aleksey.shipilev at gmail.com  Fri Jun 12 11:01:07 2020
From: aleksey.shipilev at gmail.com (Aleksey Shipilev)
Date: Fri, 12 Jun 2020 13:01:07 +0200
Subject: [15] RFR (XS) 8247474: Shenandoah: Windows build warning after
 JDK-8247310
In-Reply-To: <bd506130-568d-8052-55de-28090d06ab61@gmail.com>
References: <bd506130-568d-8052-55de-28090d06ab61@gmail.com>
Message-ID: <aab09f14-32b8-1975-b701-cd2c262d21e3@gmail.com>

On 6/12/20 12:52 PM, Aleksey Shipilev wrote:
> 

(please disregard this copy, sent from wrong email; reply to the other one)

-Aleksey



From rkennke at redhat.com  Sun Jun 14 09:13:16 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Sun, 14 Jun 2020 11:13:16 +0200
Subject: [15] RFR (XS) 8247474: Shenandoah: Windows build warning after
 JDK-8247310
In-Reply-To: <378c703d-3e8c-4550-241b-e44adb111638@redhat.com>
References: <378c703d-3e8c-4550-241b-e44adb111638@redhat.com>
Message-ID: <1c96cdc1f7c6b73bb919c0d5cbb2da8fa41867d1.camel@redhat.com>

Looks good!

Thank you!

Roman


(resending from proper email)
> 
> Bug:
>   https://bugs.openjdk.java.net/browse/JDK-8247474
> 
> Since the underlying cause is the changeset in 15, I am planning to
> push it to jdk/jdk15.
> 
> Fix:
> 
> diff -r a39eb5a4f1c1
> src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp
> --- a/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp       Thu
> Jun 11 18:16:32 2020 +0200
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahPacer.cpp       Fri
> Jun 12 12:38:30 2020 +0200
> @@ -279,10 +279,11 @@
>  }
> 
> -void ShenandoahPacer::wait(long time_ms) {
> +void ShenandoahPacer::wait(size_t time_ms) {
>    // Perform timed wait. It works like like sleep(), except without
> modifying
>    // the thread interruptible status. MonitorLocker also checks for
> safepoints.
>    assert(time_ms > 0, "Should not call this with zero argument, as
> it would stall until notify");
> +  assert(time_ms <= LONG_MAX, "Sanity");
>    MonitorLocker locker(_wait_monitor);
> -  _wait_monitor->wait(time_ms);
> +  _wait_monitor->wait((long)time_ms);
>  }
> 
> diff -r a39eb5a4f1c1
> src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp
> --- a/src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp       Thu
> Jun 11 18:16:32 2020 +0200
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahPacer.hpp       Fri
> Jun 12 12:38:30 2020 +0200
> @@ -102,5 +102,5 @@
>    size_t update_and_get_progress_history();
> 
> -  void wait(long time_ms);
> +  void wait(size_t time_ms);
>    void notify_waiters();
>  };
> 
> 
> Testing: Linux, Windows builds; hotspot_gc_shenandoah
> 
> Thanks,
> -Aleksey
> 


From shade at redhat.com  Mon Jun 15 07:38:37 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Jun 2020 09:38:37 +0200
Subject: [15] RFR (XS) 8247560: Shenandoah: heap iteration holds root locks
 all the time
Message-ID: <a6abdd82-c8ef-3e76-c7c4-31be181c95f5@redhat.com>

Bug:
  https://bugs.openjdk.java.net/browse/JDK-8247560

Newly added compressed hprof test exposes a trouble with Shenandoah heap iteration: "Attempting to
wait on monitor HProf Compression Backend/11 while holding lock CodeCache_lock/6 -- possible deadlock".

ShenandoahHeapIterationRootScanner holds the CodeCache_lock for code roots iteration, and it lingers
for the entirety of heap iteration. The fix is to scope it properly:

diff -r a39eb5a4f1c1 src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp        Thu Jun 11 18:16:32 2020 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp        Mon Jun 15 09:19:21 2020 +0200
@@ -1298,9 +1298,14 @@
   Stack<oop,mtGC> oop_stack;

-  // First, we process GC roots according to current GC cycle. This populates the work stack with
initial objects.
-  ShenandoahHeapIterationRootScanner rp;
   ObjectIterateScanRootClosure oops(&_aux_bit_map, &oop_stack);

-  rp.roots_do(&oops);
+  {
+    // First, we process GC roots according to current GC cycle.
+    // This populates the work stack with initial objects.
+    // It is important to relinquish the associated locks before diving
+    // into heap dumper.
+    ShenandoahHeapIterationRootScanner rp;
+    rp.roots_do(&oops);
+  }

   // Work through the oop stack to traverse heap.

Testing: hotspot_gc_shenandoah, affected tests (many times)

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Mon Jun 15 12:09:57 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 15 Jun 2020 08:09:57 -0400
Subject: [15] RFR (XS) 8247560: Shenandoah: heap iteration holds root
 locks all the time
In-Reply-To: <a6abdd82-c8ef-3e76-c7c4-31be181c95f5@redhat.com>
References: <a6abdd82-c8ef-3e76-c7c4-31be181c95f5@redhat.com>
Message-ID: <ab59b7a0-ec28-7591-bffc-8159e34cc256@redhat.com>

Yes.

Thanks,

-Zhengyu

On 6/15/20 3:38 AM, Aleksey Shipilev wrote:
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8247560
> 
> Newly added compressed hprof test exposes a trouble with Shenandoah heap iteration: "Attempting to
> wait on monitor HProf Compression Backend/11 while holding lock CodeCache_lock/6 -- possible deadlock".
> 
> ShenandoahHeapIterationRootScanner holds the CodeCache_lock for code roots iteration, and it lingers
> for the entirety of heap iteration. The fix is to scope it properly:
> 
> diff -r a39eb5a4f1c1 src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
> --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp        Thu Jun 11 18:16:32 2020 +0200
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp        Mon Jun 15 09:19:21 2020 +0200
> @@ -1298,9 +1298,14 @@
>     Stack<oop,mtGC> oop_stack;
> 
> -  // First, we process GC roots according to current GC cycle. This populates the work stack with
> initial objects.
> -  ShenandoahHeapIterationRootScanner rp;
>     ObjectIterateScanRootClosure oops(&_aux_bit_map, &oop_stack);
> 
> -  rp.roots_do(&oops);
> +  {
> +    // First, we process GC roots according to current GC cycle.
> +    // This populates the work stack with initial objects.
> +    // It is important to relinquish the associated locks before diving
> +    // into heap dumper.
> +    ShenandoahHeapIterationRootScanner rp;
> +    rp.roots_do(&oops);
> +  }
> 
>     // Work through the oop stack to traverse heap.
> 
> Testing: hotspot_gc_shenandoah, affected tests (many times)
> 


From shade at redhat.com  Mon Jun 15 12:12:25 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Jun 2020 14:12:25 +0200
Subject: [15] RFR (XS) 8247560: Shenandoah: heap iteration holds root
 locks all the time
In-Reply-To: <ab59b7a0-ec28-7591-bffc-8159e34cc256@redhat.com>
References: <a6abdd82-c8ef-3e76-c7c4-31be181c95f5@redhat.com>
 <ab59b7a0-ec28-7591-bffc-8159e34cc256@redhat.com>
Message-ID: <47e10dfd-9414-5374-dd62-f95f65161940@redhat.com>

On 6/15/20 2:09 PM, Zhengyu Gu wrote:
> Yes.

Thanks, pushed.

-- 
-Aleksey


From shade at redhat.com  Mon Jun 15 14:38:24 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Jun 2020 16:38:24 +0200
Subject: RFR (S) 8247593: Shenandoah: should not block pacing reporters
Message-ID: <e23faf77-8973-a4fc-88d1-7a976bba862e@redhat.com>

Bug:
  https://bugs.openjdk.java.net/browse/JDK-8247593

After JDK-8247358, we are acquiring the _wait_monitor in ShenandoahPacer::report_internal. That runs
into potential deadlocks with threads that are waiting on the same lock *and* safepointing at the
same time, against the concurrent workers that want to report the progress before returning for
subsequent safepoint.

Fix:
  https://cr.openjdk.java.net/~shade/8247593/webrev.01/

Testing: hotspot_gc_shenandoah (some tests timed out before); ad-hoc benchmarks

-- 
Thanks,
-Aleksey


From gnu.andrew at redhat.com  Mon Jun 15 19:23:39 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 15 Jun 2020 20:23:39 +0100
Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b06 Upstream Sync
In-Reply-To: <d895a19d-5f0b-a7dd-984d-e2c05c3f28e6@redhat.com>
References: <8c66b7c0-113f-2996-14fd-4135a74d8442@redhat.com>
 <d895a19d-5f0b-a7dd-984d-e2c05c3f28e6@redhat.com>
Message-ID: <64951325-50bd-511c-e077-6351003d08d2@redhat.com>



On 11/06/2020 09:55, Aleksey Shipilev wrote:
> On 6/10/20 10:29 PM, Andrew Hughes wrote:
>> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/
>>
>> Merge changesets:
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/corba/merge.changeset
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/jaxp/merge.changeset
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/jaxws/merge.changeset
> 
> Look trivially good.
> 
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset
> 
> Looks good.
> 
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/hotspot/merge.changeset
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/langtools/merge.changeset
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/nashorn/merge.changeset
>> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/root/merge.changeset
> 
> Look trivially good.
> 
>> Ok to push?
> 
> Yes!
> 

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


From rkennke at redhat.com  Tue Jun 16 09:31:31 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 16 Jun 2020 11:31:31 +0200
Subject: RFR (S) 8247593: Shenandoah: should not block pacing reporters
In-Reply-To: <e23faf77-8973-a4fc-88d1-7a976bba862e@redhat.com>
References: <e23faf77-8973-a4fc-88d1-7a976bba862e@redhat.com>
Message-ID: <98b8c42a2f420197a4dcc8cedd80d70bb6179728.camel@redhat.com>

Ok looks good.

Roman

On Mon, 2020-06-15 at 16:38 +0200, Aleksey Shipilev wrote:
> Bug:
>   https://bugs.openjdk.java.net/browse/JDK-8247593
> 
> After JDK-8247358, we are acquiring the _wait_monitor in
> ShenandoahPacer::report_internal. That runs
> into potential deadlocks with threads that are waiting on the same
> lock *and* safepointing at the
> same time, against the concurrent workers that want to report the
> progress before returning for
> subsequent safepoint.
> 
> Fix:
>   https://cr.openjdk.java.net/~shade/8247593/webrev.01/
> 
> Testing: hotspot_gc_shenandoah (some tests timed out before); ad-hoc
> benchmarks
> 


From shade at redhat.com  Tue Jun 16 17:55:47 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Jun 2020 19:55:47 +0200
Subject: [11] RFR 2020-06-16: Critical backports to sh/jdk11
Message-ID: <b956f475-eeb9-2ac0-7226-42ea851d6942@redhat.com>

https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200616/webrev.01/

This is a bunch of critical backports to stabilizing sh/jdk11:
  [backport] 8247310: Shenandoah: pacer should not affect interrupt status
  [backport] 8247474: Shenandoah: Windows build warning after JDK-8247310
  [backport] 8247358: Shenandoah: reconsider free budget slice for marking
  [backport] 8247560: Shenandoah: heap iteration holds root locks all the time

Testing: hotspot_gc_shenandoah; tier{1,2,3} with Shenandoah enabled

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Jun 16 18:51:15 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Jun 2020 20:51:15 +0200
Subject: [8] RFR 2020-06-16: Critical backports to sh/jdk8
Message-ID: <e2388904-d0e0-bbaa-f25a-044572aca220@redhat.com>

https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200616/webrev.01/

This is a bunch of critical backports to stabilizing sh/jdk8:
  [backport] 8247310: Shenandoah: pacer should not affect interrupt status
  [backport] 8247474: Shenandoah: Windows build warning after JDK-8247310
  [backport] 8247358: Shenandoah: reconsider free budget slice for marking
  [backport] 8247560: Shenandoah: heap iteration holds root locks all the time

Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Tue Jun 16 19:48:18 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 16 Jun 2020 15:48:18 -0400
Subject: RFR 8247670: Shenandoah: deadlock during class unloading OOME
Message-ID: <a8f81fb6-718e-41c2-50eb-d04bab521df8@redhat.com>

The deadlock is caused by one thread holding per-nmethod lock, then 
encountering evac-oom. At the same time, another thread entering 
evac-oom scope, then acquiring the same per-nmethod lock.

The first thread expects the second thread to see evac-oom and exit the 
scope, but the second thread is blocked on acquiring per-nmethod lock.

The solution is to introduce an abortable locker on per-nmethod lock. If 
the second thread can not acquire the lock, but see evac-oom, it simply 
aborts, so it can exit evac-oom scope.

The solution does come with penalties:

If the second thread is a Java thread (via nmethod entry barrier), the 
nmethod will be deopt.

If the second thread is worker, it causes current code root processing 
to abort, then restart.


Bug: https://bugs.openjdk.java.net/browse/JDK-8247670
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8247670/webrev.00/

Test:
   hotspot_gc_shenandoah (x86_64 and aarch64)

Thanks,

-Zhengyu


From gnu.andrew at redhat.com  Tue Jun 16 23:12:14 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 17 Jun 2020 00:12:14 +0100
Subject: [RFR] [8u] 8u262-b07 Upstream Sync
Message-ID: <ed897554-c988-6e3b-1509-25a2f6d16979@redhat.com>

Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/

Merge changesets:
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/corba/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/jaxp/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/jaxws/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/hotspot/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/langtools/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/nashorn/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/root/merge.changeset

Changes in aarch64-shenandoah-jdk8u262-b07:
  - JDK-8233197: Invert JvmtiExport::post_vm_initialized() and
Jfr:on_vm_start() start-up order for correct option parsing
  - JDK-8243541: (tz) Upgrade time-zone data to tzdata2020a
  - JDK-8245167: Top package in method profiling shows null in JMC
  - JDK-8246703: [TESTBUG] Add test for JDK-8233197

Main issues of note:
None, clean merge.

diffstat for root
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

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/tzdata/VERSION                                         |    2
 b/make/data/tzdata/africa                                          |   52 -
 b/make/data/tzdata/asia                                            |
212 +++-
 b/make/data/tzdata/backward                                        |    1
 b/make/data/tzdata/europe                                          |   16
 b/make/data/tzdata/leapseconds                                     |   12
 b/make/data/tzdata/northamerica                                    |   48 -
 b/make/data/tzdata/zone.tab                                        |   12
 b/src/share/classes/sun/util/resources/TimeZoneNames.java          |   14
 b/src/share/classes/sun/util/resources/de/TimeZoneNames_de.java    |   14
 b/src/share/classes/sun/util/resources/es/TimeZoneNames_es.java    |   14
 b/src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java    |   14
 b/src/share/classes/sun/util/resources/it/TimeZoneNames_it.java    |   14
 b/src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java    |   14
 b/src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java    |   14
 b/src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java |   14
 b/src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java    |   14
 b/src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java |   14
 b/src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java |   14
 b/test/java/time/test/java/time/format/ZoneName.java               |    1
 b/test/jdk/jfr/event/runtime/TestClassLoadEvent.java               |    4
 b/test/sun/util/calendar/zi/tzdata/VERSION                         |    2
 b/test/sun/util/calendar/zi/tzdata/africa                          |
190 +++-
 b/test/sun/util/calendar/zi/tzdata/antarctica                      |   14
 b/test/sun/util/calendar/zi/tzdata/asia                            |
455 ++++++----
 b/test/sun/util/calendar/zi/tzdata/australasia                     |
154 ++-
 b/test/sun/util/calendar/zi/tzdata/backward                        |    1
 b/test/sun/util/calendar/zi/tzdata/europe                          |
314 ++++--
 b/test/sun/util/calendar/zi/tzdata/factory                         |    2
 b/test/sun/util/calendar/zi/tzdata/leapseconds                     |   47 -
 b/test/sun/util/calendar/zi/tzdata/northamerica                    |
339 ++++---
 b/test/sun/util/calendar/zi/tzdata/pacificnew                      |    2
 b/test/sun/util/calendar/zi/tzdata/southamerica                    |   79 -
 b/test/sun/util/calendar/zi/tzdata/systemv                         |    2
 b/test/sun/util/calendar/zi/tzdata/zone.tab                        |   15
 36 files changed, 1421 insertions(+), 710 deletions(-)

diffstat for hotspot
 b/.hgtags                                                        |    1
 b/src/share/vm/classfile/classLoader.cpp                         |   58 +++
 b/src/share/vm/classfile/classLoader.hpp                         |    5
 b/src/share/vm/jfr/instrumentation/jfrJvmtiAgent.cpp             |  127
++++---
 b/src/share/vm/jfr/jfr.cpp                                       |   19 -
 b/src/share/vm/jfr/jfr.hpp                                       |    5
 b/src/share/vm/jfr/jni/jfrJavaSupport.cpp                        |    4
 b/src/share/vm/jfr/jni/jfrJavaSupport.hpp                        |    1
 b/src/share/vm/jfr/jni/jfrJniMethod.cpp                          |    4
 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.cpp      |  163
++--------
 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.hpp      |    2
 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetUtils.cpp |   19 +
 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetUtils.hpp |   16
 b/src/share/vm/jfr/recorder/jfrRecorder.cpp                      |   28 +
 b/src/share/vm/jfr/recorder/jfrRecorder.hpp                      |    5
 b/src/share/vm/jfr/recorder/service/jfrOptionSet.cpp             |   26 -
 b/src/share/vm/jfr/recorder/service/jfrOptionSet.hpp             |    4
 b/src/share/vm/runtime/thread.cpp                                |   21 +
 b/test/runtime/8233197/T.java                                    |   11
 b/test/runtime/8233197/Test8233197.sh                            |  153
+++++++++
 b/test/runtime/8233197/libJvmtiAgent.c                           |  124
+++++++
 21 files changed, 581 insertions(+), 215 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


From shade at redhat.com  Wed Jun 17 07:54:18 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Jun 2020 09:54:18 +0200
Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b07 Upstream Sync
In-Reply-To: <ed897554-c988-6e3b-1509-25a2f6d16979@redhat.com>
References: <ed897554-c988-6e3b-1509-25a2f6d16979@redhat.com>
Message-ID: <c99170b1-5c6a-504f-4656-3e0ab09e08c8@redhat.com>

On 6/17/20 1:12 AM, Andrew Hughes wrote:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/jaxws/merge.changeset

Look trivially good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset

This must be:
  http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/jdk/merge.changeset

Looks fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/hotspot/merge.changeset

Looks good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/langtools/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/nashorn/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/root/merge.changeset

Look trivially good.

> Ok to push?

Yes.

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Wed Jun 17 09:20:18 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 17 Jun 2020 11:20:18 +0200
Subject: [11] RFR 2020-06-16: Critical backports to sh/jdk11
In-Reply-To: <b956f475-eeb9-2ac0-7226-42ea851d6942@redhat.com>
References: <b956f475-eeb9-2ac0-7226-42ea851d6942@redhat.com>
Message-ID: <e91e6c49ac953073a588910d4e4d3818effa05cb.camel@redhat.com>

Looks good, thank you!

Roman

On Tue, 2020-06-16 at 19:55 +0200, Aleksey Shipilev wrote:
> https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200616/webrev.01/
> 
> This is a bunch of critical backports to stabilizing sh/jdk11:
>   [backport] 8247310: Shenandoah: pacer should not affect interrupt
> status
>   [backport] 8247474: Shenandoah: Windows build warning after JDK-
> 8247310
>   [backport] 8247358: Shenandoah: reconsider free budget slice for
> marking
>   [backport] 8247560: Shenandoah: heap iteration holds root locks all
> the time
> 
> Testing: hotspot_gc_shenandoah; tier{1,2,3} with Shenandoah enabled
> 


From rkennke at redhat.com  Wed Jun 17 09:23:38 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 17 Jun 2020 11:23:38 +0200
Subject: [8] RFR 2020-06-16: Critical backports to sh/jdk8
In-Reply-To: <e2388904-d0e0-bbaa-f25a-044572aca220@redhat.com>
References: <e2388904-d0e0-bbaa-f25a-044572aca220@redhat.com>
Message-ID: <30b58d83668d9c621a1c37caf09085fe58773b91.camel@redhat.com>

Looks good, thank you!

Roman

On Tue, 2020-06-16 at 20:51 +0200, Aleksey Shipilev wrote:
> https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200616/webrev.01/
> 
> This is a bunch of critical backports to stabilizing sh/jdk8:
>   [backport] 8247310: Shenandoah: pacer should not affect interrupt
> status
>   [backport] 8247474: Shenandoah: Windows build warning after JDK-
> 8247310
>   [backport] 8247358: Shenandoah: reconsider free budget slice for
> marking
>   [backport] 8247560: Shenandoah: heap iteration holds root locks all
> the time
> 
> Testing: hotspot_gc_shenandoah
> 


From shade at redhat.com  Wed Jun 17 11:44:35 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Jun 2020 13:44:35 +0200
Subject: RFR (S) 8247751: Shenandoah: options tests should run with smaller
 heaps
Message-ID: <3935aa0d-0a10-efd0-4aba-e47eacf0f24a@redhat.com>

RFE:
  https://bugs.openjdk.java.net/browse/JDK-8247751

On huge machines, the default heap sizes are quite large, and memory zapping takes quite some time
to startup in fastdebug mode. We should be running at least "options" tests with smaller default heaps.

Fix:
  https://cr.openjdk.java.net/~shade/8247751/webrev.01/

Testing: hotspot_gc_shenandoah (faster now)

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Jun 17 12:06:15 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Jun 2020 14:06:15 +0200
Subject: RFR (XS) 8247754: Shenandoah: mxbeans tests can be shorter
Message-ID: <8e3fcd9c-0c28-9102-2eab-9f149ad09379@redhat.com>

RFE:
  https://bugs.openjdk.java.net/browse/JDK-8247754

Fix:

diff -r 826804f83f85 test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java
--- a/test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java      Wed Jun 17 13:37:46
2020 +0200
+++ b/test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java      Wed Jun 17 14:05:48
2020 +0200
@@ -92,5 +92,5 @@

     static final long HEAP_MB = 128;                           // adjust for test configuration above
-    static final long TARGET_MB = Long.getLong("target", 8_000); // 8 Gb allocation
+    static final long TARGET_MB = Long.getLong("target", 2_000); // 2 Gb allocation

     // Should we track the churn precisely?
diff -r 826804f83f85 test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.java
--- a/test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.java      Wed Jun 17 13:37:46
2020 +0200
+++ b/test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.java      Wed Jun 17 14:05:48
2020 +0200
@@ -86,5 +86,5 @@

     static final long HEAP_MB = 128;                           // adjust for test configuration above
-    static final long TARGET_MB = Long.getLong("target", 8_000); // 8 Gb allocation
+    static final long TARGET_MB = Long.getLong("target", 2_000); // 2 Gb allocation

     static volatile Object sink;

Testing: hotspot_gc_shenandoah (faster now)

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Jun 17 12:26:22 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Jun 2020 14:26:22 +0200
Subject: RFR (S) 8247757: Shenandoah: split heavy tests by heuristics to
 improve parallelism
Message-ID: <3580fadc-335e-17a8-9d1c-43779df0d1d3@redhat.com>

RFE:
  https://bugs.openjdk.java.net/browse/JDK-8247757

There are plenty of tests that take a while and test multiple modes and heuristics. Their
configurations are split by mode. Splitting them further by heuristics improve their parallelism
even more.

Fix:
  https://cr.openjdk.java.net/~shade/8247757/webrev.01/

Testing: hotspot_gc_shenandoah (even faster now)

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Wed Jun 17 12:33:37 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 17 Jun 2020 08:33:37 -0400
Subject: RFR (S) 8247751: Shenandoah: options tests should run with
 smaller heaps
In-Reply-To: <3935aa0d-0a10-efd0-4aba-e47eacf0f24a@redhat.com>
References: <3935aa0d-0a10-efd0-4aba-e47eacf0f24a@redhat.com>
Message-ID: <ebe8f928-1ce6-a279-4469-968c4d918173@redhat.com>

Looks good.

-Zhengyu

On 6/17/20 7:44 AM, Aleksey Shipilev wrote:
> RFE:
>    https://bugs.openjdk.java.net/browse/JDK-8247751
> 
> On huge machines, the default heap sizes are quite large, and memory zapping takes quite some time
> to startup in fastdebug mode. We should be running at least "options" tests with smaller default heaps.
> 
> Fix:
>    https://cr.openjdk.java.net/~shade/8247751/webrev.01/
> 
> Testing: hotspot_gc_shenandoah (faster now)
> 


From rkennke at redhat.com  Wed Jun 17 15:18:31 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 17 Jun 2020 17:18:31 +0200
Subject: RFR (S) 8247751: Shenandoah: options tests should run with
 smaller heaps
In-Reply-To: <3935aa0d-0a10-efd0-4aba-e47eacf0f24a@redhat.com>
References: <3935aa0d-0a10-efd0-4aba-e47eacf0f24a@redhat.com>
Message-ID: <c1b1c0a4299754c8f73712af973c38b65ccaa35a.camel@redhat.com>

Yeah, that is generally a good idea to run tests with specified
smallish heap size. Patch looks good!

Thanks,
Roman

On Wed, 2020-06-17 at 13:44 +0200, Aleksey Shipilev wrote:
> RFE:
>   https://bugs.openjdk.java.net/browse/JDK-8247751
> 
> On huge machines, the default heap sizes are quite large, and memory
> zapping takes quite some time
> to startup in fastdebug mode. We should be running at least "options"
> tests with smaller default heaps.
> 
> Fix:
>   https://cr.openjdk.java.net/~shade/8247751/webrev.01/
> 
> Testing: hotspot_gc_shenandoah (faster now)
> 


From rkennke at redhat.com  Wed Jun 17 15:19:09 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 17 Jun 2020 17:19:09 +0200
Subject: RFR (XS) 8247754: Shenandoah: mxbeans tests can be shorter
In-Reply-To: <8e3fcd9c-0c28-9102-2eab-9f149ad09379@redhat.com>
References: <8e3fcd9c-0c28-9102-2eab-9f149ad09379@redhat.com>
Message-ID: <28b8c1398a1ca1078e99f9f0bd9d0dc6c72126b9.camel@redhat.com>

Ok, good.

Thanks,
Roman

On Wed, 2020-06-17 at 14:06 +0200, Aleksey Shipilev wrote:
> RFE:
>   https://bugs.openjdk.java.net/browse/JDK-8247754
> 
> Fix:
> 
> diff -r 826804f83f85
> test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java
> ---
> a/test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.jav
> a      Wed Jun 17 13:37:46
> 2020 +0200
> +++
> b/test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.jav
> a      Wed Jun 17 14:05:48
> 2020 +0200
> @@ -92,5 +92,5 @@
> 
>      static final long HEAP_MB = 128;                           //
> adjust for test configuration above
> -    static final long TARGET_MB = Long.getLong("target", 8_000); //
> 8 Gb allocation
> +    static final long TARGET_MB = Long.getLong("target", 2_000); //
> 2 Gb allocation
> 
>      // Should we track the churn precisely?
> diff -r 826804f83f85
> test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.java
> ---
> a/test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.jav
> a      Wed Jun 17 13:37:46
> 2020 +0200
> +++
> b/test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.jav
> a      Wed Jun 17 14:05:48
> 2020 +0200
> @@ -86,5 +86,5 @@
> 
>      static final long HEAP_MB = 128;                           //
> adjust for test configuration above
> -    static final long TARGET_MB = Long.getLong("target", 8_000); //
> 8 Gb allocation
> +    static final long TARGET_MB = Long.getLong("target", 2_000); //
> 2 Gb allocation
> 
>      static volatile Object sink;
> 
> Testing: hotspot_gc_shenandoah (faster now)
> 


From rkennke at redhat.com  Wed Jun 17 15:20:06 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 17 Jun 2020 17:20:06 +0200
Subject: RFR (S) 8247757: Shenandoah: split heavy tests by heuristics to
 improve parallelism
In-Reply-To: <3580fadc-335e-17a8-9d1c-43779df0d1d3@redhat.com>
References: <3580fadc-335e-17a8-9d1c-43779df0d1d3@redhat.com>
Message-ID: <33da45984d91f36298b10dd7a6ffc48b51e38195.camel@redhat.com>

Ok looks good.

Thanks,
Roman


On Wed, 2020-06-17 at 14:26 +0200, Aleksey Shipilev wrote:
> RFE:
>   https://bugs.openjdk.java.net/browse/JDK-8247757
> 
> There are plenty of tests that take a while and test multiple modes
> and heuristics. Their
> configurations are split by mode. Splitting them further by
> heuristics improve their parallelism
> even more.
> 
> Fix:
>   https://cr.openjdk.java.net/~shade/8247757/webrev.01/
> 
> Testing: hotspot_gc_shenandoah (even faster now)
> 


From shade at redhat.com  Thu Jun 18 12:56:43 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Jun 2020 14:56:43 +0200
Subject: RFR: 2020-06-18, Bulk integration of Shenandoah 8u to
 aarch64-port/jdk8u-shenandoah
Message-ID: <a48c5d65-52da-976f-abec-32d1c911a9e2@redhat.com>

https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200618/webrev.01/

This is another integration of Shenandoah 8u from our shenandoah/jdk8 staging repository. It was
generated by plain pull from shenandoah/jdk8/hotspot repository and automatic merge.

It fixes a few critical issues discovered during 8u stabilization.

Changes:
  Shenandoah: missing SystemDictionary roots in ShenandoahHeapIterationRootScanner
  Shenandoah: add JFR roots to root processor after JFR integration
  [backport] 8247310: Shenandoah: pacer should not affect interrupt status
  [backport] 8247474: Shenandoah: Windows build warning after JDK-8247310
  [backport] 8247358: Shenandoah: reconsider free budget slice for marking
  [backport] 8247560: Shenandoah: heap iteration holds root locks all the time
  Added tag aarch64-shenandoah-jdk8u262-b06-shenandoah-merge-2020-06-18 for changeset e49e42485e22

Testing: hotspot_gc_shenandoah {fastdebug,release}; it was also tested in sh/jdk8 with a few nightlies

-- 
Thanks,
-Aleksey


From shade at redhat.com  Thu Jun 18 16:23:47 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Jun 2020 18:23:47 +0200
Subject: RFR (XS) 8247860: Shenandoah: add update watermark line in rich
 assert failure message
Message-ID: <5a07f10c-f105-8a5d-c27b-730cdcea54a0@redhat.com>

RFE:
  https://bugs.openjdk.java.net/browse/JDK-8247860

Patch:

diff -r dbd95dd97289 src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp     Tue Jun 16 15:18:58 2020 -0400
+++ b/src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp     Thu Jun 18 18:23:27 2020 +0200
@@ -68,4 +68,5 @@
   msg.append("  " PTR_FORMAT " - klass " PTR_FORMAT " %s\n", p2i(obj), p2i(obj->klass()),
obj->klass()->external_name());
   msg.append("    %3s allocated after mark start\n", ctx->allocated_after_mark_start(obj) ? "" :
"not");
+  msg.append("    %3s after update watermark\n",     cast_from_oop<HeapWord*>(obj) >=
r->get_update_watermark() ? "" : "not");
   msg.append("    %3s marked \n",                    ctx->is_marked(obj) ? "" : "not");
   msg.append("    %3s in collection set\n",          heap->in_collection_set(obj) ? "" : "not");

Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Thu Jun 18 16:28:41 2020
From: rkennke at redhat.com (rkennke at redhat.com)
Date: Thu, 18 Jun 2020 18:28:41 +0200
Subject: RFR(sh/11): Cleanup traversal leftover
Message-ID: <fd040ec77d4b9c9d9c8d41d5d7d9961528db6ee8.camel@redhat.com>

I am going over sh/jdk11 vs upstream diff and found this.

Testing: build sh/jdk11 fine

diff -r 2726a4c6b8a8 make/hotspot/lib/JvmOverrideFiles.gmk
--- a/make/hotspot/lib/JvmOverrideFiles.gmk     Mon Jun 15 14:11:43
2020 +0200
+++ b/make/hotspot/lib/JvmOverrideFiles.gmk     Thu Jun 18 18:28:21
2020 +0200
@@ -39,7 +39,6 @@
   ifeq ($(DEBUG_LEVEL), release)
     # Need extra inlining to collapse all marking code into the hot
marking loop
     BUILD_LIBJVM_shenandoahConcurrentMark.cpp_CXXFLAGS := --param
inline-unit-growth=1000
-    BUILD_LIBJVM_shenandoahTraversalGC.cpp_CXXFLAGS := --param inline-
unit-growth=1000
   endif
 endif
 



From shade at redhat.com  Thu Jun 18 16:30:05 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Jun 2020 18:30:05 +0200
Subject: RFR (S) 8247845: Shenandoah: refactor TLAB/GCLAB retirement code
Message-ID: <a14f55bf-854f-6ab0-66ce-afbcdec1d9ee@redhat.com>

RFE:
  https://bugs.openjdk.java.net/browse/JDK-8247845

Fix;
  http://cr.openjdk.java.net/~shade/8247845/webrev.01/

Current TLAB/GCLAB retirement code is all over the place. Sometimes we retire GCLABs twice.
Sometimes we resize TLABs twice. This hopefully makes the things more clear by lifting things out of
CollectedHeap::ensure_parsability and specializing it for Shenandoah use cases.

Testing: hotspot_gc_shenandoah {fastdebug,release}; tier{1,2} with Shenandoah; benchmarks (running)

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Thu Jun 18 16:30:27 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 18 Jun 2020 18:30:27 +0200
Subject: RFR (XS) 8247860: Shenandoah: add update watermark line in rich
 assert failure message
In-Reply-To: <5a07f10c-f105-8a5d-c27b-730cdcea54a0@redhat.com>
References: <5a07f10c-f105-8a5d-c27b-730cdcea54a0@redhat.com>
Message-ID: <59ecab1ac8b54bd96aa91c7df3078c9b39a9b697.camel@redhat.com>

Looks good!

Roman

On Thu, 2020-06-18 at 18:23 +0200, Aleksey Shipilev wrote:
> RFE:
>   https://bugs.openjdk.java.net/browse/JDK-8247860
> 
> Patch:
> 
> diff -r dbd95dd97289
> src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp
> --- a/src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp     Tue
> Jun 16 15:18:58 2020 -0400
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp     Thu
> Jun 18 18:23:27 2020 +0200
> @@ -68,4 +68,5 @@
>    msg.append("  " PTR_FORMAT " - klass " PTR_FORMAT " %s\n",
> p2i(obj), p2i(obj->klass()),
> obj->klass()->external_name());
>    msg.append("    %3s allocated after mark start\n", ctx-
> >allocated_after_mark_start(obj) ? "" :
> "not");
> +  msg.append("    %3s after update
> watermark\n",     cast_from_oop<HeapWord*>(obj) >=
> r->get_update_watermark() ? "" : "not");
>    msg.append("    %3s marked \n",                    ctx-
> >is_marked(obj) ? "" : "not");
>    msg.append("    %3s in collection set\n",          heap-
> >in_collection_set(obj) ? "" : "not");
> 
> Testing: hotspot_gc_shenandoah
> 


From shade at redhat.com  Thu Jun 18 17:11:37 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Jun 2020 19:11:37 +0200
Subject: RFR(sh/11): Cleanup traversal leftover
In-Reply-To: <fd040ec77d4b9c9d9c8d41d5d7d9961528db6ee8.camel@redhat.com>
References: <fd040ec77d4b9c9d9c8d41d5d7d9961528db6ee8.camel@redhat.com>
Message-ID: <60cb2b03-557d-0ee0-020f-45181eee18c7@redhat.com>

On 6/18/20 6:28 PM, rkennke at redhat.com wrote:
> I am going over sh/jdk11 vs upstream diff and found this.
> 
> Testing: build sh/jdk11 fine
> 
> diff -r 2726a4c6b8a8 make/hotspot/lib/JvmOverrideFiles.gmk
> --- a/make/hotspot/lib/JvmOverrideFiles.gmk     Mon Jun 15 14:11:43
> 2020 +0200
> +++ b/make/hotspot/lib/JvmOverrideFiles.gmk     Thu Jun 18 18:28:21
> 2020 +0200
> @@ -39,7 +39,6 @@
>    ifeq ($(DEBUG_LEVEL), release)
>      # Need extra inlining to collapse all marking code into the hot
> marking loop
>      BUILD_LIBJVM_shenandoahConcurrentMark.cpp_CXXFLAGS := --param
> inline-unit-growth=1000
> -    BUILD_LIBJVM_shenandoahTraversalGC.cpp_CXXFLAGS := --param inline-
> unit-growth=1000
>    endif
>  endif

Looks good. It looks safe enough in current stabilizing sh/jdk11.

-- 
Thanks,
-Aleksey


From gnu.andrew at redhat.com  Thu Jun 18 17:35:19 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 18 Jun 2020 18:35:19 +0100
Subject: RFR: 2020-06-18, Bulk integration of Shenandoah 8u to
 aarch64-port/jdk8u-shenandoah
In-Reply-To: <a48c5d65-52da-976f-abec-32d1c911a9e2@redhat.com>
References: <a48c5d65-52da-976f-abec-32d1c911a9e2@redhat.com>
Message-ID: <839052e1-322b-2843-95f7-1496328c01b4@redhat.com>



On 18/06/2020 13:56, Aleksey Shipilev wrote:
> https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200618/webrev.01/
> 
> This is another integration of Shenandoah 8u from our shenandoah/jdk8 staging repository. It was
> generated by plain pull from shenandoah/jdk8/hotspot repository and automatic merge.
> 
> It fixes a few critical issues discovered during 8u stabilization.
> 
> Changes:
>   Shenandoah: missing SystemDictionary roots in ShenandoahHeapIterationRootScanner
>   Shenandoah: add JFR roots to root processor after JFR integration
>   [backport] 8247310: Shenandoah: pacer should not affect interrupt status
>   [backport] 8247474: Shenandoah: Windows build warning after JDK-8247310
>   [backport] 8247358: Shenandoah: reconsider free budget slice for marking
>   [backport] 8247560: Shenandoah: heap iteration holds root locks all the time
>   Added tag aarch64-shenandoah-jdk8u262-b06-shenandoah-merge-2020-06-18 for changeset e49e42485e22
> 
> Testing: hotspot_gc_shenandoah {fastdebug,release}; it was also tested in sh/jdk8 with a few nightlies
> 

Looks fine to me.

If you push this, I'll merge with b07 and re-tag based on that (sorry
for not getting around to pushing that earlier)

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


From shade at redhat.com  Thu Jun 18 18:09:05 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Jun 2020 20:09:05 +0200
Subject: RFR: 2020-06-18, Bulk integration of Shenandoah 8u to
 aarch64-port/jdk8u-shenandoah
In-Reply-To: <839052e1-322b-2843-95f7-1496328c01b4@redhat.com>
References: <a48c5d65-52da-976f-abec-32d1c911a9e2@redhat.com>
 <839052e1-322b-2843-95f7-1496328c01b4@redhat.com>
Message-ID: <0156853d-3c63-0363-9d20-946c0f60f6e7@redhat.com>

On 6/18/20 7:35 PM, Andrew Hughes wrote:
> If you push this, I'll merge with b07 and re-tag based on that (sorry
> for not getting around to pushing that earlier)

Thanks, rebased/retagged to newly pushed b07:
  https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200618/webrev.02/

-- 
-Aleksey


From gnu.andrew at redhat.com  Thu Jun 18 18:11:39 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 18 Jun 2020 19:11:39 +0100
Subject: RFR: 2020-06-18, Bulk integration of Shenandoah 8u to
 aarch64-port/jdk8u-shenandoah
In-Reply-To: <0156853d-3c63-0363-9d20-946c0f60f6e7@redhat.com>
References: <a48c5d65-52da-976f-abec-32d1c911a9e2@redhat.com>
 <839052e1-322b-2843-95f7-1496328c01b4@redhat.com>
 <0156853d-3c63-0363-9d20-946c0f60f6e7@redhat.com>
Message-ID: <dfdf2bb8-d60b-7651-9942-70338ad98717@redhat.com>



On 18/06/2020 19:09, Aleksey Shipilev wrote:
> On 6/18/20 7:35 PM, Andrew Hughes wrote:
>> If you push this, I'll merge with b07 and re-tag based on that (sorry
>> for not getting around to pushing that earlier)
> 
> Thanks, rebased/retagged to newly pushed b07:
>   https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200618/webrev.02/
> 

Thanks. Push as soon as you're ready.
-- 
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


From shade at redhat.com  Thu Jun 18 18:24:28 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Jun 2020 20:24:28 +0200
Subject: RFC: Pick up aarch64-shenandoah-jdk8u262-b07 to sh/jdk8
Message-ID: <96f92ded-3cca-dc62-f520-c8705cb36574@redhat.com>

I have recently pushed the sh/jdk8 merge to integration forest:
  https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-June/012520.html

Let's pick up everything from that merge (and all other directories) to sh/jdk8! There are no merges
at all, because sh/jdk8 is clean downstream.

Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From shade at redhat.com  Thu Jun 18 18:39:55 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 18 Jun 2020 20:39:55 +0200
Subject: RFC: Bring sh/jdk up to date with jdk/jdk
Message-ID: <34bcdc11-9fab-881d-575c-534ac4fca014@redhat.com>

$subject, just to give a heads up.

I merged the fresh jdk/jdk over it, plus reverted a few changes.

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Thu Jun 18 18:51:16 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 18 Jun 2020 20:51:16 +0200
Subject: RFC: Pick up aarch64-shenandoah-jdk8u262-b07 to sh/jdk8
In-Reply-To: <96f92ded-3cca-dc62-f520-c8705cb36574@redhat.com>
References: <96f92ded-3cca-dc62-f520-c8705cb36574@redhat.com>
Message-ID: <0283fb1e913ec576f8dc00e6f6418809b04b3b8c.camel@redhat.com>

Yes, please go!

Roman

On Thu, 2020-06-18 at 20:24 +0200, Aleksey Shipilev wrote:
> I have recently pushed the sh/jdk8 merge to integration forest:
>   
> https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-June/012520.html
> 
> Let's pick up everything from that merge (and all other directories)
> to sh/jdk8! There are no merges
> at all, because sh/jdk8 is clean downstream.
> 
> Testing: hotspot_gc_shenandoah
> 


From rkennke at redhat.com  Thu Jun 18 18:51:57 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 18 Jun 2020 20:51:57 +0200
Subject: RFC: Bring sh/jdk up to date with jdk/jdk
In-Reply-To: <34bcdc11-9fab-881d-575c-534ac4fca014@redhat.com>
References: <34bcdc11-9fab-881d-575c-534ac4fca014@redhat.com>
Message-ID: <ce65c354710a800996fc5a11304ebf26e891c59e.camel@redhat.com>

Yes! Thanks!

Roman

On Thu, 2020-06-18 at 20:39 +0200, Aleksey Shipilev wrote:
> $subject, just to give a heads up.
> 
> I merged the fresh jdk/jdk over it, plus reverted a few changes.
> 


From shade at redhat.com  Thu Jun 18 18:53:23 2020
From: shade at redhat.com (shade at redhat.com)
Date: Thu, 18 Jun 2020 18:53:23 +0000
Subject: hg: shenandoah/jdk8/langtools: 7 new changesets
Message-ID: <202006181853.05IIrNiA029548@aojmv0008.oracle.com>

Changeset: 774e6c9b9296
Author:    andrew
Date:      2020-06-07 18:57 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/774e6c9b9296

Added tag jdk8u262-b06 for changeset 26690d83c12e

! .hgtags

Changeset: 29515258c7c8
Author:    andrew
Date:      2020-06-08 12:14 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/29515258c7c8

Merge jdk8u262-b06

! .hgtags

Changeset: a7a7e9089e31
Author:    andrew
Date:      2020-06-08 12:15 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/a7a7e9089e31

Added tag aarch64-shenandoah-jdk8u262-b06 for changeset 29515258c7c8

! .hgtags

Changeset: ac5fce891621
Author:    andrew
Date:      2020-06-15 20:21 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/ac5fce891621

Added tag jdk8u262-b07 for changeset 774e6c9b9296

! .hgtags

Changeset: 55ba08a960ee
Author:    andrew
Date:      2020-06-16 02:07 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/55ba08a960ee

Merge jdk8u262-b07

! .hgtags

Changeset: 1ffa984bb69a
Author:    andrew
Date:      2020-06-16 02:39 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/1ffa984bb69a

Added tag aarch64-shenandoah-jdk8u262-b07 for changeset 55ba08a960ee

! .hgtags

Changeset: c3237ab976f1
Author:    shade
Date:      2020-06-18 20:06 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/c3237ab976f1

Added tag aarch64-shenandoah-jdk8u262-b07-shenandoah-merge-2020-06-18 for changeset 1ffa984bb69a

! .hgtags


From shade at redhat.com  Thu Jun 18 18:53:31 2020
From: shade at redhat.com (shade at redhat.com)
Date: Thu, 18 Jun 2020 18:53:31 +0000
Subject: hg: shenandoah/jdk8/jdk: 10 new changesets
Message-ID: <202006181853.05IIrWse029807@aojmv0008.oracle.com>

Changeset: 097f47e7fe97
Author:    andrew
Date:      2020-06-07 18:54 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/097f47e7fe97

8246223: Windows build fails after JDK-8227269
Summary: MSVC 2013 uses a modified variant of C90 and requires all declarations before statements
Reviewed-by: andrew
Contributed-by: Alex Kashchenko <akashche at redhat.com>

! src/share/back/classTrack.c

Changeset: a8d895846054
Author:    andrew
Date:      2020-06-07 18:57 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a8d895846054

Added tag jdk8u262-b06 for changeset 097f47e7fe97

! .hgtags

Changeset: 1cf70821a22b
Author:    andrew
Date:      2020-06-08 12:14 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/1cf70821a22b

Merge jdk8u262-b06

! .hgtags

Changeset: b5c4cff71824
Author:    andrew
Date:      2020-06-08 12:15 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b5c4cff71824

Added tag aarch64-shenandoah-jdk8u262-b06 for changeset 1cf70821a22b

! .hgtags

Changeset: 219276e7623e
Author:    andrew
Date:      2020-06-10 21:03 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/219276e7623e

8243541: (tz) Upgrade time-zone data to tzdata2020a
Reviewed-by: martin

! make/data/tzdata/VERSION
! make/data/tzdata/africa
! make/data/tzdata/asia
! make/data/tzdata/backward
! make/data/tzdata/europe
! make/data/tzdata/leapseconds
! make/data/tzdata/northamerica
! make/data/tzdata/zone.tab
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java
! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java
! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java
! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java
! test/java/time/test/java/time/format/ZoneName.java
! test/sun/util/calendar/zi/tzdata/VERSION
! test/sun/util/calendar/zi/tzdata/africa
! test/sun/util/calendar/zi/tzdata/antarctica
! test/sun/util/calendar/zi/tzdata/asia
! test/sun/util/calendar/zi/tzdata/australasia
! test/sun/util/calendar/zi/tzdata/backward
! test/sun/util/calendar/zi/tzdata/europe
! test/sun/util/calendar/zi/tzdata/factory
! test/sun/util/calendar/zi/tzdata/leapseconds
! test/sun/util/calendar/zi/tzdata/northamerica
! test/sun/util/calendar/zi/tzdata/pacificnew
! test/sun/util/calendar/zi/tzdata/southamerica
! test/sun/util/calendar/zi/tzdata/systemv
! test/sun/util/calendar/zi/tzdata/zone.tab

Changeset: 745caf348aee
Author:    apetushkov
Date:      2020-06-15 14:08 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/745caf348aee

8245167: Top package in method profiling shows null in JMC
Reviewed-by: neugens
Contributed-by: asemenov at azul.com

! test/jdk/jfr/event/runtime/TestClassLoadEvent.java

Changeset: d70c3e992833
Author:    andrew
Date:      2020-06-15 20:21 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d70c3e992833

Added tag jdk8u262-b07 for changeset 745caf348aee

! .hgtags

Changeset: 1e6d8a09233f
Author:    andrew
Date:      2020-06-16 02:07 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/1e6d8a09233f

Merge jdk8u262-b07

! .hgtags
! make/data/tzdata/VERSION
! make/data/tzdata/africa
! make/data/tzdata/asia
! make/data/tzdata/backward
! make/data/tzdata/europe
! make/data/tzdata/leapseconds
! make/data/tzdata/northamerica
! make/data/tzdata/zone.tab
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java
! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java
! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java
! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java
! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java
! test/sun/util/calendar/zi/tzdata/VERSION
! test/sun/util/calendar/zi/tzdata/africa
! test/sun/util/calendar/zi/tzdata/antarctica
! test/sun/util/calendar/zi/tzdata/asia
! test/sun/util/calendar/zi/tzdata/australasia
! test/sun/util/calendar/zi/tzdata/backward
! test/sun/util/calendar/zi/tzdata/europe
! test/sun/util/calendar/zi/tzdata/leapseconds
! test/sun/util/calendar/zi/tzdata/northamerica
! test/sun/util/calendar/zi/tzdata/southamerica
! test/sun/util/calendar/zi/tzdata/zone.tab

Changeset: b27f15c5e48a
Author:    andrew
Date:      2020-06-16 02:40 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b27f15c5e48a

Added tag aarch64-shenandoah-jdk8u262-b07 for changeset 1e6d8a09233f

! .hgtags

Changeset: 0d61467843b8
Author:    shade
Date:      2020-06-18 20:06 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/0d61467843b8

Added tag aarch64-shenandoah-jdk8u262-b07-shenandoah-merge-2020-06-18 for changeset b27f15c5e48a

! .hgtags


From rkennke at redhat.com  Thu Jun 18 20:38:44 2020
From: rkennke at redhat.com (rkennke at redhat.com)
Date: Thu, 18 Jun 2020 20:38:44 +0000
Subject: hg: shenandoah/jdk11: Cleanup traversal leftover
Message-ID: <202006182038.05IKcjtE016220@aojmv0008.oracle.com>

Changeset: 47383d1a545e
Author:    rkennke
Date:      2020-06-18 22:38 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk11/rev/47383d1a545e

Cleanup traversal leftover

! make/hotspot/lib/JvmOverrideFiles.gmk


From rkennke at redhat.com  Fri Jun 19 09:18:47 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 19 Jun 2020 11:18:47 +0200
Subject: RFR(sh/11): Cleanup Shenandoah leftovers in C2 code
Message-ID: <55cf15a17af15800cf9fca2a5b851d6593e4b541.camel@redhat.com>

Found some more leftover includes and whitespace changes:

http://cr.openjdk.java.net/~rkennke/shjdk11-cleanup-c2/webrev.00/

Testing: hotspot_gc_shenandoah

Ok?

Roman


From rwestrel at redhat.com  Fri Jun 19 09:35:10 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 19 Jun 2020 11:35:10 +0200
Subject: RFR(sh/11): Cleanup Shenandoah leftovers in C2 code
In-Reply-To: <55cf15a17af15800cf9fca2a5b851d6593e4b541.camel@redhat.com>
References: <55cf15a17af15800cf9fca2a5b851d6593e4b541.camel@redhat.com>
Message-ID: <87mu4zwg8h.fsf@redhat.com>


> http://cr.openjdk.java.net/~rkennke/shjdk11-cleanup-c2/webrev.00/

Looks good.

Roland.


From rkennke at redhat.com  Fri Jun 19 10:01:33 2020
From: rkennke at redhat.com (rkennke at redhat.com)
Date: Fri, 19 Jun 2020 10:01:33 +0000
Subject: hg: shenandoah/jdk11: Cleanup Shenandoah leftovers in C2 code
Message-ID: <202006191001.05JA1X5t001375@aojmv0008.oracle.com>

Changeset: 0f3e4c4dca1b
Author:    rkennke
Date:      2020-06-19 10:58 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk11/rev/0f3e4c4dca1b

Cleanup Shenandoah leftovers in C2 code

! src/hotspot/share/opto/cfgnode.cpp
! src/hotspot/share/opto/type.cpp


From zgu at redhat.com  Mon Jun 22 14:12:25 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 22 Jun 2020 10:12:25 -0400
Subject: [16] 8247736: Shenandoah: assert(_nm->is_alive()) failed: only alive
 nmethods here
Message-ID: <51c85d82-6bc1-56b9-9d5d-408bfcdbe87a@redhat.com>

The assertion is unreliable, as a nmethod can become a zombie before it 
is unregistered, and nmethod's state change can race against concurrent 
nmethod iteration, since they are under two different locks.

We did not see this assertion before JDK-8245961, because we used 
CodeCache::blobs_do() to scan code cache and did not have the assertion 
on its code path.

Ideally, I would prefer to keep nmethod list hygienic: unregister the 
nmethod before making state transition. However, offline discussion with 
Erik, he convinced me that could have unexpected consequences and risky. 
Mark through and evacuate/disarm zombie nmethods, while undesirable, but 
harmless.

So, let's just filter out dead nmethod (still racy) and remove the 
assertion.

Bug: https://bugs.openjdk.java.net/browse/JDK-8247736
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8247736/webrev.00/index.html

Test:
   hotspot_gc_shenandoah

Thanks,

-Zhengyu


From rkennke at redhat.com  Mon Jun 22 15:00:34 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 22 Jun 2020 17:00:34 +0200
Subject: [16] 8247736: Shenandoah: assert(_nm->is_alive()) failed: only
 alive nmethods here
In-Reply-To: <51c85d82-6bc1-56b9-9d5d-408bfcdbe87a@redhat.com>
References: <51c85d82-6bc1-56b9-9d5d-408bfcdbe87a@redhat.com>
Message-ID: <b0480170e62cd439efaa970e05dd86c8bfe37052.camel@redhat.com>

The patch looks ok to me.

Thank you,
Roman

On Mon, 2020-06-22 at 10:12 -0400, Zhengyu Gu wrote:
> The assertion is unreliable, as a nmethod can become a zombie before
> it 
> is unregistered, and nmethod's state change can race against
> concurrent 
> nmethod iteration, since they are under two different locks.
> 
> We did not see this assertion before JDK-8245961, because we used 
> CodeCache::blobs_do() to scan code cache and did not have the
> assertion 
> on its code path.
> 
> Ideally, I would prefer to keep nmethod list hygienic: unregister
> the 
> nmethod before making state transition. However, offline discussion
> with 
> Erik, he convinced me that could have unexpected consequences and
> risky. 
> Mark through and evacuate/disarm zombie nmethods, while undesirable,
> but 
> harmless.
> 
> So, let's just filter out dead nmethod (still racy) and remove the 
> assertion.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8247736
> Webrev: 
> http://cr.openjdk.java.net/~zgu/JDK-8247736/webrev.00/index.html
> 
> Test:
>    hotspot_gc_shenandoah
> 
> Thanks,
> 
> -Zhengyu
> 


From shade at redhat.com  Mon Jun 22 15:34:00 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 22 Jun 2020 17:34:00 +0200
Subject: [16] 8247736: Shenandoah: assert(_nm->is_alive()) failed: only
 alive nmethods here
In-Reply-To: <51c85d82-6bc1-56b9-9d5d-408bfcdbe87a@redhat.com>
References: <51c85d82-6bc1-56b9-9d5d-408bfcdbe87a@redhat.com>
Message-ID: <250520d7-04c3-db0a-78da-922d616de5a6@redhat.com>

On 6/22/20 4:12 PM, Zhengyu Gu wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8247736
> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8247736/webrev.00/index.html

Looks fine.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Jun 22 17:39:48 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 22 Jun 2020 19:39:48 +0200
Subject: [8] RFR: Shenandoah: JNI weak roots are always cleared before Full GC
 mark
Message-ID: <63cc4c75-929d-dccf-f5ed-cc69c19455be@redhat.com>

Amir found the crash with Cassandra that started to happen recently with Shenandoah 8u. It
reproduces more or less reliably with starting Cassandra 3.11.4 with fastdebug build and
-XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC.

This is a symptom of a larger problem (see JDK-8248041), but 8u it is catastrophic due to clearing
of the weak roots.

Fix:
  https://cr.openjdk.java.net/~shade/shenandoah/8u-fullgc-jni-weak/webrev.01/

Testing: hotspot_gc_shenandoah; Cassandra tests

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Mon Jun 22 17:52:59 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 22 Jun 2020 13:52:59 -0400
Subject: [sh/jdk8u] RFR Shenandoah: properly deallocates class loader metadata
Message-ID: <88687836-37e9-6b05-9877-e173f0eff27a@redhat.com>

The problem was discovered when running vmTestbase tests, where 
Shenandoah fails following tests:

vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java
vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java 
 
vmTestbase/vm/runtime/defmeth/scenarios/Stress_redefine/TestDescription.java

It appears to be 8u specific problem, where it handles class loader 
metadata differently. Let's mirror G1 on how metadata is handled.


Webrev: 
http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-metadata-clean/webrev.00/index.html

Test:
   hotspot_gc_shenandoah
   vmTestbase tests that no longer fail after patch.

Thanks,

-Zhengyu


From rkennke at redhat.com  Mon Jun 22 17:53:26 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 22 Jun 2020 19:53:26 +0200
Subject: [8] RFR: Shenandoah: JNI weak roots are always cleared before
 Full GC mark
In-Reply-To: <63cc4c75-929d-dccf-f5ed-cc69c19455be@redhat.com>
References: <63cc4c75-929d-dccf-f5ed-cc69c19455be@redhat.com>
Message-ID: <71fcd54ee8eccd5c1982c2caedef2f05e08d55bf.camel@redhat.com>

Looks good.

Minor nit: "Work that around" -> "Work around that" I believe sounds
better.

Roman


On Mon, 2020-06-22 at 19:39 +0200, Aleksey Shipilev wrote:
> Amir found the crash with Cassandra that started to happen recently
> with Shenandoah 8u. It
> reproduces more or less reliably with starting Cassandra 3.11.4 with
> fastdebug build and
> -XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC.
> 
> This is a symptom of a larger problem (see JDK-8248041), but 8u it is
> catastrophic due to clearing
> of the weak roots.
> 
> Fix:
>   
> https://cr.openjdk.java.net/~shade/shenandoah/8u-fullgc-jni-weak/webrev.01/
> 
> Testing: hotspot_gc_shenandoah; Cassandra tests
> 


From shade at redhat.com  Mon Jun 22 17:56:14 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 22 Jun 2020 19:56:14 +0200
Subject: [sh/jdk8u] RFR Shenandoah: properly deallocates class loader
 metadata
In-Reply-To: <88687836-37e9-6b05-9877-e173f0eff27a@redhat.com>
References: <88687836-37e9-6b05-9877-e173f0eff27a@redhat.com>
Message-ID: <bd014608-9b53-9046-124e-30181a93a560@redhat.com>

On 6/22/20 7:52 PM, Zhengyu Gu wrote:
> The problem was discovered when running vmTestbase tests, where 
> Shenandoah fails following tests:
> 
> vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java
> vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java 
>  
> vmTestbase/vm/runtime/defmeth/scenarios/Stress_redefine/TestDescription.java
> 
> It appears to be 8u specific problem, where it handles class loader 
> metadata differently. Let's mirror G1 on how metadata is handled.
> 
> 
> Webrev: 
> http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-metadata-clean/webrev.00/index.html

Looks fine.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Jun 22 17:58:54 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 22 Jun 2020 19:58:54 +0200
Subject: [8] RFR: Shenandoah: JNI weak roots are always cleared before
 Full GC mark
In-Reply-To: <71fcd54ee8eccd5c1982c2caedef2f05e08d55bf.camel@redhat.com>
References: <63cc4c75-929d-dccf-f5ed-cc69c19455be@redhat.com>
 <71fcd54ee8eccd5c1982c2caedef2f05e08d55bf.camel@redhat.com>
Message-ID: <1745448f-407e-6692-25ef-bd2f089dfa1e@redhat.com>

On 6/22/20 7:53 PM, Roman Kennke wrote:
> Minor nit: "Work that around" -> "Work around that" I believe sounds
> better.

"Work that around" seems legit:
  https://www.google.com/search?q=%22Work+that+around%22

"Work around that" implies the object right after? "Work around that *problem*".

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Mon Jun 22 17:59:46 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 22 Jun 2020 13:59:46 -0400
Subject: [8] RFR: Shenandoah: JNI weak roots are always cleared before
 Full GC mark
In-Reply-To: <63cc4c75-929d-dccf-f5ed-cc69c19455be@redhat.com>
References: <63cc4c75-929d-dccf-f5ed-cc69c19455be@redhat.com>
Message-ID: <05a20ac8-6d0c-7aa5-53e3-90b42a585af3@redhat.com>

Looks good.

-Zhengyu

On 6/22/20 1:39 PM, Aleksey Shipilev wrote:
> Amir found the crash with Cassandra that started to happen recently with Shenandoah 8u. It
> reproduces more or less reliably with starting Cassandra 3.11.4 with fastdebug build and
> -XX:ShenandoahGCMode=passive -XX:-ShenandoahDegeneratedGC.
> 
> This is a symptom of a larger problem (see JDK-8248041), but 8u it is catastrophic due to clearing
> of the weak roots.
> 
> Fix:
>    https://cr.openjdk.java.net/~shade/shenandoah/8u-fullgc-jni-weak/webrev.01/
> 
> Testing: hotspot_gc_shenandoah; Cassandra tests
> 


From shade at redhat.com  Mon Jun 22 18:01:11 2020
From: shade at redhat.com (shade at redhat.com)
Date: Mon, 22 Jun 2020 18:01:11 +0000
Subject: hg: shenandoah/jdk8/hotspot: Shenandoah: JNI weak roots are always
 cleared before Full GC mark
Message-ID: <202006221801.05MI1BbD000729@aojmv0008.oracle.com>

Changeset: 86f432f4008b
Author:    shade
Date:      2020-06-22 20:01 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/86f432f4008b

Shenandoah: JNI weak roots are always cleared before Full GC mark
Reviewed-by: rkennke, zgu

! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp


From zgu at redhat.com  Mon Jun 22 18:02:34 2020
From: zgu at redhat.com (zgu at redhat.com)
Date: Mon, 22 Jun 2020 18:02:34 +0000
Subject: hg: shenandoah/jdk8/hotspot: Shenandoah: properly deallocates class
 loader metadata
Message-ID: <202006221802.05MI2YNq001290@aojmv0008.oracle.com>

Changeset: 505af841b923
Author:    zgu
Date:      2020-06-22 14:02 -0400
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/505af841b923

Shenandoah: properly deallocates class loader metadata
Reviewed-by: shade

! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp
! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp


From rkennke at redhat.com  Tue Jun 23 09:40:37 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 23 Jun 2020 11:40:37 +0200
Subject: RFR: New evacuation-locking protocol
Message-ID: <70cd80a9a8cc11e1e150ae79c38cbc9ce841ade4.camel@redhat.com>

I am proposing a new evacuation protocol. Until now we let concurrent
evacuating threads both make a copy and then compete to install the
forwarding pointer using a CAS on the fwdptr field. This worked well,
except for one problem: how to handle OOM during evacuation? We only
came up with the extra protocol in shenandoahEvacOOMHandler* that is
effectively a readers-writer-lock. This has proven to be a major PITA
in the past, has caused several deadlocks, bugs, etc etc.

I am proposing to use a kind of locking-protocol for the whole of
evacuation instead. The proposed patch uses a separate bitmap where
each bit corresponds to a heap-word (or more, see below). Before
evacuating an object, a thread must acquire the corresponding bit, and
when it's done, release it again.

OOM during evac is then handled by a global flag: when we are inside
the per-object-flag, we would raise this flag, and next time we visit
the object we observe the flag and don't attempt any more evacuations.

It also turns out that we can trim the bitmap by making it coarser, by
making each bit correspond to 2, 4, 8 or 2^N heap-words. This can be
achieved by setting the flag ShenandoahEvacLockGranularity to higher
values N. Setting it to 1 means each bit covers 2 words, 2 -> 4 words,
etc. It seems that we can *at least* make it 1 by default, because each
object is at least 2 heap words. Some initial experiments by Aleksey
have shown that we can probably increase it even more without
performance loss, but this warrants more experimentation.

I'm proposing to push it to shenandoah/jdk first, and let it bake there
before going to JDK mainline.

I'm splitting the review into two patches because it seems easier to
review separately. I'd push them as one changeset (unless you prefer it
separately) because the build would be broken between the two.

1. Prune the 'old' evac-handler:
http://cr.openjdk.java.net/~rkennke/evac-locking/webrev-prune-oom-handler.00/

2. Implementation of the new evac-locking:
http://cr.openjdk.java.net/~rkennke/evac-locking/webrev-evac-locking.00/

Testing: hotspot_gc_shenandoah, specjvm2008 doesn't show regressions

Can I please get a review?

Thanks,
Roman


From shade at redhat.com  Tue Jun 23 10:55:10 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 23 Jun 2020 12:55:10 +0200
Subject: RFR: New evacuation-locking protocol
In-Reply-To: <70cd80a9a8cc11e1e150ae79c38cbc9ce841ade4.camel@redhat.com>
References: <70cd80a9a8cc11e1e150ae79c38cbc9ce841ade4.camel@redhat.com>
Message-ID: <2bfac2cb-6d1b-49e0-bac5-850c796e0df6@redhat.com>

On 6/23/20 11:40 AM, Roman Kennke wrote:
> 1. Prune the 'old' evac-handler:
> http://cr.openjdk.java.net/~rkennke/evac-locking/webrev-prune-oom-handler.00/

*) Indenting change here:

shenandoahThreadLocalData.hpp:
-    _satb_mark_queue(&ShenandoahBarrierSet::satb_mark_queue_set()),
+   _satb_mark_queue(&ShenandoahBarrierSet::satb_mark_queue_set()),

> 2. Implementation of the new evac-locking:
> http://cr.openjdk.java.net/~rkennke/evac-locking/webrev-evac-locking.00/

*) We should probably transplant the protocol rationale comments to new files...

*) This docs are now invalid:

shenandoahForwarding.hpp:
  55   /* Tries to atomically update forwardee in $holder object to $update.
  56    * Assumes $holder points at itself.
  57    * Asserts $holder is in from-space.
  58    * Asserts $update is in to-space.
  59    *
  60    * Returns the new object 'update' upon success, or
  61    * the new forwardee that a competing thread installed.
  62    */
  63   static inline void update_forwardee(oop obj, oop update);

*) Removed newline:

shenandoahHeap.cpp:
@@ -2013,7 +2018,6 @@

           collection_set()->clear_current_index();
         }
-
         op_stw_evac();
         if (cancelled_gc()) {
           op_degenerated_fail();

*) I don't think explicit initialization of _evac_failed is needed here:

shenandoahHeap.cpp:

@@ -495,7 +498,9 @@
   _bitmap_region_special(false),
   _aux_bitmap_region_special(false),
   _liveness_cache(NULL),
-  _collection_set(NULL)
+  _collection_set(NULL),
+  _evac_locking_bitmap(NULL),
+  _evac_failed()
 {
   _heap = this;


*) Indenting is a bit off:

+  experimental(uintx, ShenandoahEvacLockGranularity, 0,                     \
+          "How coarse to make evac-locking. Default 0 means "               \
+	  "per-HeapWord-locking, higher value make locking coarser "        \
+          "in 2-exponent steps, e.g. one lock per 2^N heap words.")         \
+                                                                            \

*) This is just (1 + ShenandoahEvacLockGranularity) * LogHeapWordSize?

_shifter(LogHeapWordSize + ShenandoahEvacLockGranularity * LogHeapWordSize)

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Tue Jun 23 14:56:56 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 23 Jun 2020 10:56:56 -0400
Subject: [16] 8248041: Shenandoah: pre-Full GC root updates may miss some roots
Message-ID: <cc77a0da-3dee-7623-ac61-a0c2195d7c19@redhat.com>

Updating roots before full GC, should really belong to prepare phase.
The roots may contain forwarded pointers, only when this full GC is 
triggered by evacuation OOM, that leaves forwarded objects in roots.

Moving to prepare phase, while has_forwarded_objects flag still valid, 
also allows us to bypass this phase, if no forwarded objects in heap.


Bug: https://bugs.openjdk.java.net/browse/JDK-8248041
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8248041/webrev.00/

Test:
   hotspot_gc_shenandoah

Thanks,

-Zhengyu


From rkennke at redhat.com  Tue Jun 23 15:09:54 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 23 Jun 2020 17:09:54 +0200
Subject: RFR: New evacuation-locking protocol
In-Reply-To: <2bfac2cb-6d1b-49e0-bac5-850c796e0df6@redhat.com>
References: <70cd80a9a8cc11e1e150ae79c38cbc9ce841ade4.camel@redhat.com>
 <2bfac2cb-6d1b-49e0-bac5-850c796e0df6@redhat.com>
Message-ID: <ec09ddb25379020fcdf6a78970e4268903508410.camel@redhat.com>

Hi Aleksey,


> On 6/23/20 11:40 AM, Roman Kennke wrote:
> > 1. Prune the 'old' evac-handler:
> > http://cr.openjdk.java.net/~rkennke/evac-locking/webrev-prune-oom-handler.00/
> 
> *) Indenting change here:
> 
> shenandoahThreadLocalData.hpp:
> -    _satb_mark_queue(&ShenandoahBarrierSet::satb_mark_queue_set()),
> +   _satb_mark_queue(&ShenandoahBarrierSet::satb_mark_queue_set()),
> 

Ok, fixed.

> > 2. Implementation of the new evac-locking:
> > http://cr.openjdk.java.net/~rkennke/evac-locking/webrev-evac-locking.00/
> 
> *) We should probably transplant the protocol rationale comments to
> new files...
> 

I added some comments. Please check it.

> *) This docs are now invalid:
> 
> shenandoahForwarding.hpp:
>   55   /* Tries to atomically update forwardee in $holder object to
> $update.
>   56    * Assumes $holder points at itself.
>   57    * Asserts $holder is in from-space.
>   58    * Asserts $update is in to-space.
>   59    *
>   60    * Returns the new object 'update' upon success, or
>   61    * the new forwardee that a competing thread installed.
>   62    */
>   63   static inline void update_forwardee(oop obj, oop update);
> 

Ok, I fixed/removed the wrong parts.

> *) Removed newline:
> 
> shenandoahHeap.cpp:
> @@ -2013,7 +2018,6 @@
> 
>            collection_set()->clear_current_index();
>          }
> -
>          op_stw_evac();
>          if (cancelled_gc()) {
>            op_degenerated_fail();
> 

Fixed.

> *) I don't think explicit initialization of _evac_failed is needed
> here:
> 
> shenandoahHeap.cpp:
> 
> @@ -495,7 +498,9 @@
>    _bitmap_region_special(false),
>    _aux_bitmap_region_special(false),
>    _liveness_cache(NULL),
> -  _collection_set(NULL)
> +  _collection_set(NULL),
> +  _evac_locking_bitmap(NULL),
> +  _evac_failed()
>  {
>    _heap = this;
> 
> 

Right, fixed.

> *) Indenting is a bit off:
> 
> +  experimental(uintx, ShenandoahEvacLockGranularity,
> 0,                     \
> +          "How coarse to make evac-locking. Default 0 means
> "               \
> +	  "per-HeapWord-locking, higher value make locking coarser
> "        \
> +          "in 2-exponent steps, e.g. one lock per 2^N heap
> words.")         \
> +                                                                    
>         \
> 

Fixed.

> *) This is just (1 + ShenandoahEvacLockGranularity) *
> LogHeapWordSize?
> 
> _shifter(LogHeapWordSize + ShenandoahEvacLockGranularity *
> LogHeapWordSize)
> 

Indeed. Fixed.

http://cr.openjdk.java.net/~rkennke/evac-locking/webrev-prune-oom-handler.01/

and

http://cr.openjdk.java.net/~rkennke/evac-locking/webrev-evac-locking.01/

Better?

Roman



From shade at redhat.com  Tue Jun 23 15:44:57 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 23 Jun 2020 17:44:57 +0200
Subject: RFR: New evacuation-locking protocol
In-Reply-To: <ec09ddb25379020fcdf6a78970e4268903508410.camel@redhat.com>
References: <70cd80a9a8cc11e1e150ae79c38cbc9ce841ade4.camel@redhat.com>
 <2bfac2cb-6d1b-49e0-bac5-850c796e0df6@redhat.com>
 <ec09ddb25379020fcdf6a78970e4268903508410.camel@redhat.com>
Message-ID: <1b25acdc-a157-86c7-436e-895057ec1055@redhat.com>

On 6/23/20 5:09 PM, Roman Kennke wrote:
> http://cr.openjdk.java.net/~rkennke/evac-locking/webrev-prune-oom-handler.01/
> 
> and
> 
> http://cr.openjdk.java.net/~rkennke/evac-locking/webrev-evac-locking.01/
> 
> Better?

Looks good, let's stage it in sh/jdk.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Jun 23 15:46:50 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 23 Jun 2020 17:46:50 +0200
Subject: [16] 8248041: Shenandoah: pre-Full GC root updates may miss some
 roots
In-Reply-To: <cc77a0da-3dee-7623-ac61-a0c2195d7c19@redhat.com>
References: <cc77a0da-3dee-7623-ac61-a0c2195d7c19@redhat.com>
Message-ID: <988e6de1-411b-c289-96b4-690c9f83ff02@redhat.com>

On 6/23/20 4:56 PM, Zhengyu Gu wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8248041
> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8248041/webrev.00/

Nice trick, looks good.

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Tue Jun 23 16:08:24 2020
From: rkennke at redhat.com (rkennke at redhat.com)
Date: Tue, 23 Jun 2020 16:08:24 +0000
Subject: hg: shenandoah/jdk: New evacuation-locking protocol
Message-ID: <202006231608.05NG8PYO016746@aojmv0008.oracle.com>

Changeset: aeb9d445884d
Author:    rkennke
Date:      2020-06-23 18:07 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk/rev/aeb9d445884d

New evacuation-locking protocol
Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
+ src/hotspot/share/gc/shenandoah/shenandoahEvacLockingBitmap.hpp
+ src/hotspot/share/gc/shenandoah/shenandoahEvacLockingBitmap.inline.hpp
- src/hotspot/share/gc/shenandoah/shenandoahEvacOOMHandler.cpp
- src/hotspot/share/gc/shenandoah/shenandoahEvacOOMHandler.hpp
- src/hotspot/share/gc/shenandoah/shenandoahEvacOOMHandler.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahForwarding.hpp
! src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp
! 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/shenandoahNMethod.cpp
! src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.cpp
! src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp


From shade at redhat.com  Wed Jun 24 07:28:03 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 24 Jun 2020 09:28:03 +0200
Subject: RFC: Pick up 11.0.8+8 to sh/jdk11
Message-ID: <d7281279-a9ac-3a84-818b-6fe890a2ec21@redhat.com>

Upstream published 11.0.8+8, let's pick it up to sh/jdk11.

Merge is trivial. I would tag the result shenandoah-jdk-11.0.8+8 immediately.

Testing: hotspot_gc_shenandoah {fastdebug,release}

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Wed Jun 24 07:39:06 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 24 Jun 2020 09:39:06 +0200
Subject: RFC: Pick up 11.0.8+8 to sh/jdk11
In-Reply-To: <d7281279-a9ac-3a84-818b-6fe890a2ec21@redhat.com>
References: <d7281279-a9ac-3a84-818b-6fe890a2ec21@redhat.com>
Message-ID: <f6b850f42b7577aaf0781fc49fc01b3e7af3ca68.camel@redhat.com>

Yup, go!

Roman

On Wed, 2020-06-24 at 09:28 +0200, Aleksey Shipilev wrote:
> 	Error verifying signature: Cannot verify message signature:
> Incorrect message format
> Upstream published 11.0.8+8, let's pick it up to sh/jdk11.
> 
> Merge is trivial. I would tag the result shenandoah-jdk-11.0.8+8
> immediately.
> 
> Testing: hotspot_gc_shenandoah {fastdebug,release}
> 


From zgu at redhat.com  Wed Jun 24 12:18:57 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 24 Jun 2020 08:18:57 -0400
Subject: [16] RFR 8248227: Shenandoah: Refactor Shenandoah::heap() to match
 other GCs
Message-ID: <d82940ba-d34c-ec3d-3103-b0c44b195183@redhat.com>

Please review this small patch that refactors Shenandoah::heap() to 
match other GCs.

Bug: https://bugs.openjdk.java.net/browse/JDK-8248227
Webrev: http://cr.openjdk.java.net/~zgu/JDK-8248227/webev.00/index.html


Test:
   hotspot_gc_shenandoah

Thanks,

-Zhengyu


From kdnilsen at amazon.com  Wed Jun 24 13:54:13 2020
From: kdnilsen at amazon.com (Nilsen, Kelvin)
Date: Wed, 24 Jun 2020 13:54:13 +0000
Subject: RFR: 8232782: Shenandoah: streamline post-LRB CAS barrier (aarch64)
Message-ID: <EBBC4610-3589-413C-B7B3-019610FFDD94@amazon.com>

See http://cr.openjdk.java.net/~kdnilsen/JDK-8232782/webrev.00/

This patch addresses the problem described in https://bugs.openjdk.java.net/browse/JDK-8232782

The implementation mimics the behavior of the recently revised x86 implementation of cmpxchg_oop with slight refinements:

X86 version:
Step 1: Try CAS
Step 2: if CAS fails, check if original memory holds equivalent from-space pointer
Step 3: Use CAS to overwrite memory with equivalent to-space pointer
Step 4: Try CAS again
Step 5: Return boolean result to indicate success or failure

AARCH64 version:
Step 1: Try CAS
Step 2: if CAS fails, check if original memory holds equivalent from-space pointer
Step 3 (differs): Do not overwrite memory with equivalent to-space pointer,  Instead, run the original CAS request with from-space pointer as the "expected" value. If this succeeds, we're done.  If this fails, go back to step 1 and try that again.

Step 5: Return boolean result to indicate success or failure

This patch satisfies tier1, tier2, and hotspot_gc_shenandoah regression tests on Ubuntu 18.04.4 LTS (GNU/Linux 5.3.0-1023-aws aarch64).  I have also run an "extreme" garbage collection workload for 20 minutes without problem.

Is this ok to merge?

(This is a repost of a message that was posted and bounced yesterday.)



From aph at redhat.com  Wed Jun 24 14:29:04 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 24 Jun 2020 15:29:04 +0100
Subject: RFR: 8232782: Shenandoah: streamline post-LRB CAS barrier
 (aarch64)
In-Reply-To: <EBBC4610-3589-413C-B7B3-019610FFDD94@amazon.com>
References: <EBBC4610-3589-413C-B7B3-019610FFDD94@amazon.com>
Message-ID: <34978650-be69-1e01-e11e-608f205338ff@redhat.com>

On 24/06/2020 14:54, Nilsen, Kelvin wrote:
> Is this ok to merge?

One thing:

Some CPUs, in particular those based on Neoverse N1, can perform very
badly when using ldxr/stxr. For that reason, all code doing CAS

I can't see any reason why your code needs to use ldxr/stxr. Is there
any?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From rkennke at redhat.com  Wed Jun 24 14:48:33 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 24 Jun 2020 16:48:33 +0200
Subject: RFR: 8232782: Shenandoah: streamline post-LRB CAS barrier
 (aarch64)
In-Reply-To: <34978650-be69-1e01-e11e-608f205338ff@redhat.com>
References: <EBBC4610-3589-413C-B7B3-019610FFDD94@amazon.com>
 <34978650-be69-1e01-e11e-608f205338ff@redhat.com>
Message-ID: <43f1a7648b5861d9a7ff16622ccea4a5e6164c3c.camel@redhat.com>

On Wed, 2020-06-24 at 15:29 +0100, Andrew Haley wrote:
> On 24/06/2020 14:54, Nilsen, Kelvin wrote:
> > Is this ok to merge?
> 
> One thing:
> 
> Some CPUs, in particular those based on Neoverse N1, can perform very
> badly when using ldxr/stxr. For that reason, all code doing CAS
> 
> I can't see any reason why your code needs to use ldxr/stxr. Is there
> any?

As far as I know, Shenandoah's AArch64-CAS-implementation always did it
that way (don't remember why). If regular CAS is generally better, then
we should go for it.

Roman



From fweimer at redhat.com  Wed Jun 24 14:55:03 2020
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 24 Jun 2020 16:55:03 +0200
Subject: RFR: 8232782: Shenandoah: streamline post-LRB CAS barrier
 (aarch64)
In-Reply-To: <43f1a7648b5861d9a7ff16622ccea4a5e6164c3c.camel@redhat.com>
 (Roman Kennke's message of "Wed, 24 Jun 2020 16:48:33 +0200")
References: <EBBC4610-3589-413C-B7B3-019610FFDD94@amazon.com>
 <34978650-be69-1e01-e11e-608f205338ff@redhat.com>
 <43f1a7648b5861d9a7ff16622ccea4a5e6164c3c.camel@redhat.com>
Message-ID: <87sgeka4zc.fsf@oldenburg2.str.redhat.com>

* Roman Kennke:

> On Wed, 2020-06-24 at 15:29 +0100, Andrew Haley wrote:
>> On 24/06/2020 14:54, Nilsen, Kelvin wrote:
>> > Is this ok to merge?
>> 
>> One thing:
>> 
>> Some CPUs, in particular those based on Neoverse N1, can perform very
>> badly when using ldxr/stxr. For that reason, all code doing CAS
>> 
>> I can't see any reason why your code needs to use ldxr/stxr. Is there
>> any?
>
> As far as I know, Shenandoah's AArch64-CAS-implementation always did it
> that way (don't remember why). If regular CAS is generally better, then
> we should go for it.

It's only better on CPUs that support it. 8-)  CAS is only available if
the CPU supports ARMv8.1 LSE (HWCAP_ATOMICS is set in AT_HWCAP).

Thanks,
Florian


From rkennke at redhat.com  Wed Jun 24 15:10:35 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 24 Jun 2020 17:10:35 +0200
Subject: RFR (S) 8247845: Shenandoah: refactor TLAB/GCLAB retirement code
In-Reply-To: <a14f55bf-854f-6ab0-66ce-afbcdec1d9ee@redhat.com>
References: <a14f55bf-854f-6ab0-66ce-afbcdec1d9ee@redhat.com>
Message-ID: <d14dbec78345ca9f2541422d11d9929c522d65a4.camel@redhat.com>

I forgot to review it, sorry for the late reply.

The patch looks good to me.

Thank you,
Roman

On Thu, 2020-06-18 at 18:30 +0200, Aleksey Shipilev wrote:
> RFE:
>   https://bugs.openjdk.java.net/browse/JDK-8247845
> 
> Fix;
>   http://cr.openjdk.java.net/~shade/8247845/webrev.01/
> 
> Current TLAB/GCLAB retirement code is all over the place. Sometimes
> we retire GCLABs twice.
> Sometimes we resize TLABs twice. This hopefully makes the things more
> clear by lifting things out of
> CollectedHeap::ensure_parsability and specializing it for Shenandoah
> use cases.
> 
> Testing: hotspot_gc_shenandoah {fastdebug,release}; tier{1,2} with
> Shenandoah; benchmarks (running)
> 


From aph at redhat.com  Wed Jun 24 15:22:39 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 24 Jun 2020 16:22:39 +0100
Subject: RFR: 8232782: Shenandoah: streamline post-LRB CAS barrier
 (aarch64)
In-Reply-To: <43f1a7648b5861d9a7ff16622ccea4a5e6164c3c.camel@redhat.com>
References: <EBBC4610-3589-413C-B7B3-019610FFDD94@amazon.com>
 <34978650-be69-1e01-e11e-608f205338ff@redhat.com>
 <43f1a7648b5861d9a7ff16622ccea4a5e6164c3c.camel@redhat.com>
Message-ID: <e5692fd1-c127-bf12-704b-ebe1853b5d36@redhat.com>

On 24/06/2020 15:48, Roman Kennke wrote:
> On Wed, 2020-06-24 at 15:29 +0100, Andrew Haley wrote:
>> On 24/06/2020 14:54, Nilsen, Kelvin wrote:
>>> Is this ok to merge?
>>
>> One thing:
>>
>> Some CPUs, in particular those based on Neoverse N1, can perform very
>> badly when using ldxr/stxr. For that reason, all code doing CAS
>>
>> I can't see any reason why your code needs to use ldxr/stxr. Is there
>> any?
> 
> As far as I know, Shenandoah's AArch64-CAS-implementation always did it
> that way (don't remember why). If regular CAS is generally better, then
> we should go for it.

Does this algorithm need a full barrier even when CAS fails?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From aph at redhat.com  Wed Jun 24 15:22:40 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 24 Jun 2020 16:22:40 +0100
Subject: RFR: 8232782: Shenandoah: streamline post-LRB CAS barrier
 (aarch64)
In-Reply-To: <34978650-be69-1e01-e11e-608f205338ff@redhat.com>
References: <EBBC4610-3589-413C-B7B3-019610FFDD94@amazon.com>
 <34978650-be69-1e01-e11e-608f205338ff@redhat.com>
Message-ID: <c8c5e393-188c-ef17-e2e8-b651c81d7cf9@redhat.com>

On 24/06/2020 15:29, Andrew Haley wrote:
> On 24/06/2020 14:54, Nilsen, Kelvin wrote:
>> Is this ok to merge?
> 
> One thing:
> 
> Some CPUs, in particular those based on Neoverse N1, can perform very
> badly when using ldxr/stxr. For that reason, all code doing CAS
> 
> I can't see any reason why your code needs to use ldxr/stxr. Is there
> any?

I should have said, but didn't: please use MacroAssembler::cmpxchg()

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From rkennke at redhat.com  Wed Jun 24 15:28:06 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 24 Jun 2020 17:28:06 +0200
Subject: RFR: 8232782: Shenandoah: streamline post-LRB CAS barrier
 (aarch64)
In-Reply-To: <e5692fd1-c127-bf12-704b-ebe1853b5d36@redhat.com>
References: <EBBC4610-3589-413C-B7B3-019610FFDD94@amazon.com>
 <34978650-be69-1e01-e11e-608f205338ff@redhat.com>
 <43f1a7648b5861d9a7ff16622ccea4a5e6164c3c.camel@redhat.com>
 <e5692fd1-c127-bf12-704b-ebe1853b5d36@redhat.com>
Message-ID: <f555bdde6e573fe98b00ee5469921cfabd276aab.camel@redhat.com>

On Wed, 2020-06-24 at 16:22 +0100, Andrew Haley wrote:
> On 24/06/2020 15:48, Roman Kennke wrote:
> > On Wed, 2020-06-24 at 15:29 +0100, Andrew Haley wrote:
> > > On 24/06/2020 14:54, Nilsen, Kelvin wrote:
> > > > Is this ok to merge?
> > > 
> > > One thing:
> > > 
> > > Some CPUs, in particular those based on Neoverse N1, can perform
> > > very
> > > badly when using ldxr/stxr. For that reason, all code doing CAS
> > > 
> > > I can't see any reason why your code needs to use ldxr/stxr. Is
> > > there
> > > any?
> > 
> > As far as I know, Shenandoah's AArch64-CAS-implementation always
> > did it
> > that way (don't remember why). If regular CAS is generally better,
> > then
> > we should go for it.
> 
> Does this algorithm need a full barrier even when CAS fails?

We need to do extra work *only* when CAS fails. We need to catch false
negatives -- when the compare-value is to-space (that's guaranteed) and
the value in memory is from-space copy of the same object.

Roman


From kdnilsen at amazon.com  Fri Jun 26 20:21:10 2020
From: kdnilsen at amazon.com (Nilsen, Kelvin)
Date: Fri, 26 Jun 2020 20:21:10 +0000
Subject: RFR: 8232782: Shenandoah: streamline post-LRB CAS barrier
 (aarch64)
In-Reply-To: <f555bdde6e573fe98b00ee5469921cfabd276aab.camel@redhat.com>
References: <EBBC4610-3589-413C-B7B3-019610FFDD94@amazon.com>
 <34978650-be69-1e01-e11e-608f205338ff@redhat.com>
 <43f1a7648b5861d9a7ff16622ccea4a5e6164c3c.camel@redhat.com>
 <e5692fd1-c127-bf12-704b-ebe1853b5d36@redhat.com>
 <f555bdde6e573fe98b00ee5469921cfabd276aab.camel@redhat.com>
Message-ID: <A59F6903-FBFF-40E1-92BD-243537256FEB@amazon.com>

Is there consensus that we should use CAS instruction instead of ldxr/stxr?

Presumably, there are some platforms where ldxr/stxr performs better than CAS, or at least there is the potential that such would exist.

Perhaps the JIT and run-time should adjust their behavior depending on the host platform.

Perhaps the whole issue of which synchronization primitives to use should be addressed in a different ticket.

I am willing to rework this patch.  Just need some clear guidance as to which direction to move it.

Thanks.


?On 6/24/20, 8:28 AM, "Roman Kennke" <rkennke at redhat.com> wrote:

      On Wed, 2020-06-24 at 16:22 +0100, Andrew Haley wrote:
    > On 24/06/2020 15:48, Roman Kennke wrote:
    > > On Wed, 2020-06-24 at 15:29 +0100, Andrew Haley wrote:
    > > > On 24/06/2020 14:54, Nilsen, Kelvin wrote:
    > > > > Is this ok to merge?
    > > >
    > > > One thing:
    > > >
    > > > Some CPUs, in particular those based on Neoverse N1, can perform
    > > > very
    > > > badly when using ldxr/stxr. For that reason, all code doing CAS
    > > >
    > > > I can't see any reason why your code needs to use ldxr/stxr. Is
    > > > there
    > > > any?
    > >
    > > As far as I know, Shenandoah's AArch64-CAS-implementation always
    > > did it
    > > that way (don't remember why). If regular CAS is generally better,
    > > then
    > > we should go for it.
    >
    > Does this algorithm need a full barrier even when CAS fails?

    We need to do extra work *only* when CAS fails. We need to catch false
    negatives -- when the compare-value is to-space (that's guaranteed) and
    the value in memory is from-space copy of the same object.

    Roman



From rkennke at redhat.com  Fri Jun 26 21:00:34 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 26 Jun 2020 23:00:34 +0200
Subject: RFR: 8232782: Shenandoah: streamline post-LRB CAS barrier
 (aarch64)
In-Reply-To: <A59F6903-FBFF-40E1-92BD-243537256FEB@amazon.com>
References: <EBBC4610-3589-413C-B7B3-019610FFDD94@amazon.com>
 <34978650-be69-1e01-e11e-608f205338ff@redhat.com>
 <43f1a7648b5861d9a7ff16622ccea4a5e6164c3c.camel@redhat.com>
 <e5692fd1-c127-bf12-704b-ebe1853b5d36@redhat.com>
 <f555bdde6e573fe98b00ee5469921cfabd276aab.camel@redhat.com>
 <A59F6903-FBFF-40E1-92BD-243537256FEB@amazon.com>
Message-ID: <e2e6d87caf1e1793387262036288d7ccc32b9281.camel@redhat.com>

I believe if you do what Andrew Haley suggested an use
MacroAssembler::cmpxchg() it will do a CAS if supported by the
platform, or ldxr/stxr if not. So either we simply use that, or maybe
come up with two different implementations and select one or the other
like MacroAssembler::cmpxchg() does? Not sure if there would be any
advantage in the latter.

Roman

On Fri, 2020-06-26 at 20:21 +0000, Nilsen, Kelvin wrote:
> Is there consensus that we should use CAS instruction instead of
> ldxr/stxr?
> 
> Presumably, there are some platforms where ldxr/stxr performs better
> than CAS, or at least there is the potential that such would exist.
> 
> Perhaps the JIT and run-time should adjust their behavior depending
> on the host platform.
> 
> Perhaps the whole issue of which synchronization primitives to use
> should be addressed in a different ticket.
> 
> I am willing to rework this patch.  Just need some clear guidance as
> to which direction to move it.
> 
> Thanks.
> 
> 
> ?On 6/24/20, 8:28 AM, "Roman Kennke" <rkennke at redhat.com> wrote:
> 
>       On Wed, 2020-06-24 at 16:22 +0100, Andrew Haley wrote:
>     > On 24/06/2020 15:48, Roman Kennke wrote:
>     > > On Wed, 2020-06-24 at 15:29 +0100, Andrew Haley wrote:
>     > > > On 24/06/2020 14:54, Nilsen, Kelvin wrote:
>     > > > > Is this ok to merge?
>     > > >
>     > > > One thing:
>     > > >
>     > > > Some CPUs, in particular those based on Neoverse N1, can
> perform
>     > > > very
>     > > > badly when using ldxr/stxr. For that reason, all code doing
> CAS
>     > > >
>     > > > I can't see any reason why your code needs to use
> ldxr/stxr. Is
>     > > > there
>     > > > any?
>     > >
>     > > As far as I know, Shenandoah's AArch64-CAS-implementation
> always
>     > > did it
>     > > that way (don't remember why). If regular CAS is generally
> better,
>     > > then
>     > > we should go for it.
>     >
>     > Does this algorithm need a full barrier even when CAS fails?
> 
>     We need to do extra work *only* when CAS fails. We need to catch
> false
>     negatives -- when the compare-value is to-space (that's
> guaranteed) and
>     the value in memory is from-space copy of the same object.
> 
>     Roman
> 
> 


From aph at redhat.com  Sat Jun 27 08:02:39 2020
From: aph at redhat.com (Andrew Haley)
Date: Sat, 27 Jun 2020 09:02:39 +0100
Subject: RFR: 8232782: Shenandoah: streamline post-LRB CAS barrier
 (aarch64)
In-Reply-To: <A59F6903-FBFF-40E1-92BD-243537256FEB@amazon.com>
References: <EBBC4610-3589-413C-B7B3-019610FFDD94@amazon.com>
 <34978650-be69-1e01-e11e-608f205338ff@redhat.com>
 <43f1a7648b5861d9a7ff16622ccea4a5e6164c3c.camel@redhat.com>
 <e5692fd1-c127-bf12-704b-ebe1853b5d36@redhat.com>
 <f555bdde6e573fe98b00ee5469921cfabd276aab.camel@redhat.com>
 <A59F6903-FBFF-40E1-92BD-243537256FEB@amazon.com>
Message-ID: <46e2400d-0613-f9e0-cb06-a89180ca6f5f@redhat.com>

On 26/06/2020 21:21, Nilsen, Kelvin wrote:
> Is there consensus that we should use CAS instruction instead of ldxr/stxr?
> 
> Presumably, there are some platforms where ldxr/stxr performs better than CAS, or at least there is the potential that such would exist.
> 
> Perhaps the JIT and run-time should adjust their behavior depending on the host platform.

That's exactly what it does.

> Perhaps the whole issue of which synchronization primitives to use should be addressed in a different ticket.
> 
> I am willing to rework this patch.  Just need some clear guidance as to which direction to move it.

Simple: don't use ldxr/stxr, call MacroAssembler::cmpxchg() . It will do
the right thing on whatever platform it runs on.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From aph at redhat.com  Sat Jun 27 08:35:04 2020
From: aph at redhat.com (Andrew Haley)
Date: Sat, 27 Jun 2020 09:35:04 +0100
Subject: RFR: 8232782: Shenandoah: streamline post-LRB CAS barrier
 (aarch64)
In-Reply-To: <e2e6d87caf1e1793387262036288d7ccc32b9281.camel@redhat.com>
References: <EBBC4610-3589-413C-B7B3-019610FFDD94@amazon.com>
 <34978650-be69-1e01-e11e-608f205338ff@redhat.com>
 <43f1a7648b5861d9a7ff16622ccea4a5e6164c3c.camel@redhat.com>
 <e5692fd1-c127-bf12-704b-ebe1853b5d36@redhat.com>
 <f555bdde6e573fe98b00ee5469921cfabd276aab.camel@redhat.com>
 <A59F6903-FBFF-40E1-92BD-243537256FEB@amazon.com>
 <e2e6d87caf1e1793387262036288d7ccc32b9281.camel@redhat.com>
Message-ID: <842546fa-93b0-3d0f-e6f7-1c4dfc5b9931@redhat.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On 26/06/2020 22:00, Roman Kennke wrote:
> I believe if you do what Andrew Haley suggested an use
> MacroAssembler::cmpxchg() it will do a CAS if supported by the
> platform, or ldxr/stxr if not. So either we simply use that, or maybe
> come up with two different implementations and select one or the other
> like MacroAssembler::cmpxchg() does? Not sure if there would be any
> advantage in the latter.

Please don't.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From shade at redhat.com  Mon Jun 29 07:04:09 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 29 Jun 2020 09:04:09 +0200
Subject: [16] RFR 8248227: Shenandoah: Refactor Shenandoah::heap() to
 match other GCs
In-Reply-To: <d82940ba-d34c-ec3d-3103-b0c44b195183@redhat.com>
References: <d82940ba-d34c-ec3d-3103-b0c44b195183@redhat.com>
Message-ID: <ce323dea-2425-eae3-8ea1-91768684e036@redhat.com>

On 6/24/20 2:18 PM, Zhengyu Gu wrote:
> Please review this small patch that refactors Shenandoah::heap() to 
> match other GCs.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8248227
> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8248227/webev.00/index.html

Wait. We do the same thing as ZHeap::heap(). This patch clashes with the intent of JDK-8241743. At
very least we have to prove it compiles down to the same.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Jun 29 09:23:26 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 29 Jun 2020 11:23:26 +0200
Subject: RFR: Fix evac-locking math
Message-ID: <35aa50b6-224f-e200-345c-f8a3bcd04fe7@redhat.com>

This is destined to sh/jdk sandbox.

I believe current sizing math mismatches the intent. We already compute bitmap index from the *word
size*, which means shifting that to LogHeapWordSize is incorrect. What we have now in the sandbox is
actually 2^3 = 8 heap words per lock bit.

This reflects it better:

--- a/src/hotspot/share/gc/shenandoah/shenandoahEvacLockingBitmap.hpp   Tue Jun 23 18:07:20 2020 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoahEvacLockingBitmap.hpp   Mon Jun 29 11:12:00 2020 +0200
@@ -44,19 +44,19 @@
  */
 class ShenandoahEvacLockingBitmap : public CHeapObj<mtGC> {
 private:
   MemRegion _covered;    // The heap area covered by this bitmap.
   const int _shifter;    // Shift amount from heap index to bit index in the bitmap.
-  CHeapBitMap _bm;        // The actual bitmap.
+  CHeapBitMap _bm;       // The actual bitmap.

   // Convert from address to bit offset.
   inline size_t addr_to_offset(const HeapWord* addr) const;

 public:
   ShenandoahEvacLockingBitmap(MemRegion heap) :
   _covered(heap),
-  _shifter((1 + ShenandoahEvacLockGranularity) * LogHeapWordSize),
+  _shifter(ShenandoahEvacLockGranularity),
   _bm(_covered.word_size() >> _shifter, mtGC) {
 }

   inline void acquire(oop obj);
   inline void release(oop obj);
diff -r aeb9d445884d src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
--- a/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp    Tue Jun 23 18:07:20 2020 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp    Mon Jun 29 11:12:00 2020 +0200
@@ -320,14 +320,16 @@
                                                                             \
   experimental(uintx, ShenandoahSATBBufferFlushInterval, 100,               \
           "Forcefully flush non-empty SATB buffers at this interval. "      \
           "Time is in milliseconds.")                                       \
                                                                             \
-  experimental(uintx, ShenandoahEvacLockGranularity, 0,                     \
-          "How coarse to make evac-locking. Default 0 means "               \
-          "per-HeapWord-locking, higher value make locking coarser "        \
-          "in 2-exponent steps, e.g. one lock per 2^N heap words.")         \
+  experimental(uintx, ShenandoahEvacLockGranularity, 3,                     \
+          "Defines the coarseness of evac-locking bitmap. Measured in "     \
+          "power-of-two steps. Zero means per-HeapWord-locking, default 3 " \
+          "means one lock per 2^3 = 8 heap words. Larger values improve "   \
+          "native footprint at expense of more potential contention during "\
+          "evacuation.")                                                    \
                                                                             \
   diagnostic(bool, ShenandoahPreclean, true,                                \
           "Do concurrent preclean phase before final mark: process "        \
           "definitely alive references to avoid dealing with them during "  \
           "pause.")                                                         \

Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Mon Jun 29 12:05:54 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 29 Jun 2020 14:05:54 +0200
Subject: RFR (sh/jdk): Fix evac-lock shift
Message-ID: <b5bddb3599fe9647b8dee57f7686d1efa2b8191e.camel@redhat.com>

I made a mistake in computing the evac-lock-shift. I wrongly assumed
that pointer_delta(a, b) gives me the byte-difference between b and a,
but it really gives the pointer different in units of the type of a and
b. (Why is it not ok to use C++ pointer math there?!) This makes
calculation of the _shifter wrong. Fix:

http://cr.openjdk.java.net/~rkennke/fix-evac-lock-shift/webrev.00/



@@ -52,11 +52,11 @@
   inline size_t addr_to_offset(const HeapWord* addr) const;
 
 public:
   ShenandoahEvacLockingBitmap(MemRegion heap) :
   _covered(heap),
-  _shifter((1 + ShenandoahEvacLockGranularity) * LogHeapWordSize),
+  _shifter(ShenandoahEvacLockGranularity),
   _bm(_covered.word_size() >> _shifter, mtGC) {
 }
 
   inline void acquire(oop obj);
   inline void release(oop obj);


Testing: hotspot_gc_shenandoah, specjvm with higher-than-10 values of
ShenandoahEvacLockGranularity (which crashed before).

Good?

Roman


From shade at redhat.com  Mon Jun 29 12:15:55 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 29 Jun 2020 14:15:55 +0200
Subject: RFR (sh/jdk): Fix evac-lock shift
In-Reply-To: <b5bddb3599fe9647b8dee57f7686d1efa2b8191e.camel@redhat.com>
References: <b5bddb3599fe9647b8dee57f7686d1efa2b8191e.camel@redhat.com>
Message-ID: <f165bc59-8955-98f7-3935-e1c09dc9a793@redhat.com>

On 6/29/20 2:05 PM, Roman Kennke wrote:
> I made a mistake in computing the evac-lock-shift. I wrongly assumed
> that pointer_delta(a, b) gives me the byte-difference between b and a,
> but it really gives the pointer different in units of the type of a and
> b. (Why is it not ok to use C++ pointer math there?!) This makes
> calculation of the _shifter wrong. Fix:
> 
> http://cr.openjdk.java.net/~rkennke/fix-evac-lock-shift/webrev.00/

Did the same thing a few hours ago:
 https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-June/012573.html

...but also put the new default so it matches the current behavior (which seems already good), and
updated the flags.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Jun 29 12:28:02 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 29 Jun 2020 14:28:02 +0200
Subject: RFR: Fix evac-locking math
In-Reply-To: <35aa50b6-224f-e200-345c-f8a3bcd04fe7@redhat.com>
References: <35aa50b6-224f-e200-345c-f8a3bcd04fe7@redhat.com>
Message-ID: <37cd7e10-90fb-0cc1-c116-945b9ef39f65@redhat.com>

Resending for Roman's convenience.

-Aleksey

On 6/29/20 11:23 AM, Aleksey Shipilev wrote:
> This is destined to sh/jdk sandbox.
> 
> I believe current sizing math mismatches the intent. We already compute bitmap index from the *word
> size*, which means shifting that to LogHeapWordSize is incorrect. What we have now in the sandbox is
> actually 2^3 = 8 heap words per lock bit.
> 
> This reflects it better:
> 
> --- a/src/hotspot/share/gc/shenandoah/shenandoahEvacLockingBitmap.hpp   Tue Jun 23 18:07:20 2020 +0200
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahEvacLockingBitmap.hpp   Mon Jun 29 11:12:00 2020 +0200
> @@ -44,19 +44,19 @@
>   */
>  class ShenandoahEvacLockingBitmap : public CHeapObj<mtGC> {
>  private:
>    MemRegion _covered;    // The heap area covered by this bitmap.
>    const int _shifter;    // Shift amount from heap index to bit index in the bitmap.
> -  CHeapBitMap _bm;        // The actual bitmap.
> +  CHeapBitMap _bm;       // The actual bitmap.
> 
>    // Convert from address to bit offset.
>    inline size_t addr_to_offset(const HeapWord* addr) const;
> 
>  public:
>    ShenandoahEvacLockingBitmap(MemRegion heap) :
>    _covered(heap),
> -  _shifter((1 + ShenandoahEvacLockGranularity) * LogHeapWordSize),
> +  _shifter(ShenandoahEvacLockGranularity),
>    _bm(_covered.word_size() >> _shifter, mtGC) {
>  }
> 
>    inline void acquire(oop obj);
>    inline void release(oop obj);
> diff -r aeb9d445884d src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
> --- a/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp    Tue Jun 23 18:07:20 2020 +0200
> +++ b/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp    Mon Jun 29 11:12:00 2020 +0200
> @@ -320,14 +320,16 @@
>                                                                              \
>    experimental(uintx, ShenandoahSATBBufferFlushInterval, 100,               \
>            "Forcefully flush non-empty SATB buffers at this interval. "      \
>            "Time is in milliseconds.")                                       \
>                                                                              \
> -  experimental(uintx, ShenandoahEvacLockGranularity, 0,                     \
> -          "How coarse to make evac-locking. Default 0 means "               \
> -          "per-HeapWord-locking, higher value make locking coarser "        \
> -          "in 2-exponent steps, e.g. one lock per 2^N heap words.")         \
> +  experimental(uintx, ShenandoahEvacLockGranularity, 3,                     \
> +          "Defines the coarseness of evac-locking bitmap. Measured in "     \
> +          "power-of-two steps. Zero means per-HeapWord-locking, default 3 " \
> +          "means one lock per 2^3 = 8 heap words. Larger values improve "   \
> +          "native footprint at expense of more potential contention during "\
> +          "evacuation.")                                                    \
>                                                                              \
>    diagnostic(bool, ShenandoahPreclean, true,                                \
>            "Do concurrent preclean phase before final mark: process "        \
>            "definitely alive references to avoid dealing with them during "  \
>            "pause.")                                                         \
> 
> Testing: hotspot_gc_shenandoah
> 


-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Mon Jun 29 12:35:42 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 29 Jun 2020 14:35:42 +0200
Subject: RFR: Fix evac-locking math
In-Reply-To: <37cd7e10-90fb-0cc1-c116-945b9ef39f65@redhat.com>
References: <35aa50b6-224f-e200-345c-f8a3bcd04fe7@redhat.com>
 <37cd7e10-90fb-0cc1-c116-945b9ef39f65@redhat.com>
Message-ID: <36abcdb716f5989a725be9b1783e2aae9cf79fcd.camel@redhat.com>

Looks good to me, thank you!

Roman

> 	Error verifying signature: Cannot verify message signature:
> Incorrect message format
> Resending for Roman's convenience.
> 
> -Aleksey
> 
> On 6/29/20 11:23 AM, Aleksey Shipilev wrote:
> > This is destined to sh/jdk sandbox.
> > 
> > I believe current sizing math mismatches the intent. We already
> > compute bitmap index from the *word
> > size*, which means shifting that to LogHeapWordSize is incorrect.
> > What we have now in the sandbox is
> > actually 2^3 = 8 heap words per lock bit.
> > 
> > This reflects it better:
> > 
> > ---
> > a/src/hotspot/share/gc/shenandoah/shenandoahEvacLockingBitmap.hpp  
> >  Tue Jun 23 18:07:20 2020 +0200
> > +++
> > b/src/hotspot/share/gc/shenandoah/shenandoahEvacLockingBitmap.hpp  
> >  Mon Jun 29 11:12:00 2020 +0200
> > @@ -44,19 +44,19 @@
> >   */
> >  class ShenandoahEvacLockingBitmap : public CHeapObj<mtGC> {
> >  private:
> >    MemRegion _covered;    // The heap area covered by this bitmap.
> >    const int _shifter;    // Shift amount from heap index to bit
> > index in the bitmap.
> > -  CHeapBitMap _bm;        // The actual bitmap.
> > +  CHeapBitMap _bm;       // The actual bitmap.
> > 
> >    // Convert from address to bit offset.
> >    inline size_t addr_to_offset(const HeapWord* addr) const;
> > 
> >  public:
> >    ShenandoahEvacLockingBitmap(MemRegion heap) :
> >    _covered(heap),
> > -  _shifter((1 + ShenandoahEvacLockGranularity) * LogHeapWordSize),
> > +  _shifter(ShenandoahEvacLockGranularity),
> >    _bm(_covered.word_size() >> _shifter, mtGC) {
> >  }
> > 
> >    inline void acquire(oop obj);
> >    inline void release(oop obj);
> > diff -r aeb9d445884d
> > src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
> > --- a/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp    Tue
> > Jun 23 18:07:20 2020 +0200
> > +++ b/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp    Mon
> > Jun 29 11:12:00 2020 +0200
> > @@ -320,14 +320,16 @@
> >                                                                    
> >           \
> >    experimental(uintx, ShenandoahSATBBufferFlushInterval,
> > 100,               \
> >            "Forcefully flush non-empty SATB buffers at this
> > interval. "      \
> >            "Time is in
> > milliseconds.")                                       \
> >                                                                    
> >           \
> > -  experimental(uintx, ShenandoahEvacLockGranularity,
> > 0,                     \
> > -          "How coarse to make evac-locking. Default 0 means
> > "               \
> > -          "per-HeapWord-locking, higher value make locking coarser
> > "        \
> > -          "in 2-exponent steps, e.g. one lock per 2^N heap
> > words.")         \
> > +  experimental(uintx, ShenandoahEvacLockGranularity,
> > 3,                     \
> > +          "Defines the coarseness of evac-locking bitmap. Measured
> > in "     \
> > +          "power-of-two steps. Zero means per-HeapWord-locking,
> > default 3 " \
> > +          "means one lock per 2^3 = 8 heap words. Larger values
> > improve "   \
> > +          "native footprint at expense of more potential
> > contention during "\
> > +          "evacuation.")                                          
> >           \
> >                                                                    
> >           \
> >    diagnostic(bool, ShenandoahPreclean,
> > true,                                \
> >            "Do concurrent preclean phase before final mark: process
> > "        \
> >            "definitely alive references to avoid dealing with them
> > during "  \
> >            "pause.")                                               
> >           \
> > 
> > Testing: hotspot_gc_shenandoah
> > 
> 
> 


From shade at redhat.com  Mon Jun 29 12:36:26 2020
From: shade at redhat.com (shade at redhat.com)
Date: Mon, 29 Jun 2020 12:36:26 +0000
Subject: hg: shenandoah/jdk: Fix evac-locking math
Message-ID: <202006291236.05TCaQ6d018885@aojmv0008.oracle.com>

Changeset: b2d812adc96a
Author:    shade
Date:      2020-06-29 14:36 +0200
URL:       https://hg.openjdk.java.net/shenandoah/jdk/rev/b2d812adc96a

Fix evac-locking math

! src/hotspot/share/gc/shenandoah/shenandoahEvacLockingBitmap.hpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp


From shade at redhat.com  Mon Jun 29 13:31:50 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 29 Jun 2020 15:31:50 +0200
Subject: [16] RFR 8248227: Shenandoah: Refactor Shenandoah::heap() to
 match other GCs
In-Reply-To: <a224b312-0de8-def3-8cbd-611a3f965d42@redhat.com>
References: <d82940ba-d34c-ec3d-3103-b0c44b195183@redhat.com>
 <ce323dea-2425-eae3-8ea1-91768684e036@redhat.com>
 <a224b312-0de8-def3-8cbd-611a3f965d42@redhat.com>
Message-ID: <ce776c2e-340f-3627-b957-c9195456f4e0@redhat.com>

On 6/29/20 3:29 PM, Zhengyu Gu wrote:
> Hi Aleksey,
> 
> On 6/29/20 3:04 AM, Aleksey Shipilev wrote:
>> On 6/24/20 2:18 PM, Zhengyu Gu wrote:
>>> Please review this small patch that refactors Shenandoah::heap() to
>>> match other GCs.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248227
>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8248227/webev.00/index.html
>>
>> Wait. We do the same thing as ZHeap::heap(). This patch clashes with the intent of JDK-8241743. At
>> very least we have to prove it compiles down to the same.
>>
> 
> Based on comments of JDK-8247740, it intends to make the call inline-able.
> 
> ZGC is different story, it is not derived from CollectedHeap.
> 
> I checked a few places, it does seem to inline ShenandoahHeap::heap() 
> calls, e.g.
> 
>     0x00007ffff780c29c <+28>:	push   %rbx
>     0x00007ffff780c29d <+29>:	sub    $0x48,%rsp
>     0x00007ffff780c2a1 <+33>:	lea    0x54e8c8(%rip),%rax        # 
> 0x7ffff7d5ab70 <_ZN14ShenandoahHeap5_heapE>
>     0x00007ffff780c2a8 <+40>:	mov    (%rax),%rbx

OK then! Looks good.

-- 
Thanks,
-Aleksey


From zgu at redhat.com  Mon Jun 29 13:29:38 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 29 Jun 2020 09:29:38 -0400
Subject: [16] RFR 8248227: Shenandoah: Refactor Shenandoah::heap() to
 match other GCs
In-Reply-To: <ce323dea-2425-eae3-8ea1-91768684e036@redhat.com>
References: <d82940ba-d34c-ec3d-3103-b0c44b195183@redhat.com>
 <ce323dea-2425-eae3-8ea1-91768684e036@redhat.com>
Message-ID: <a224b312-0de8-def3-8cbd-611a3f965d42@redhat.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
Hi Aleksey,

On 6/29/20 3:04 AM, Aleksey Shipilev wrote:
> On 6/24/20 2:18 PM, Zhengyu Gu wrote:
>> Please review this small patch that refactors Shenandoah::heap() to
>> match other GCs.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8248227
>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8248227/webev.00/index.html
> 
> Wait. We do the same thing as ZHeap::heap(). This patch clashes with the intent of JDK-8241743. At
> very least we have to prove it compiles down to the same.
> 

Based on comments of JDK-8247740, it intends to make the call inline-able.

ZGC is different story, it is not derived from CollectedHeap.

I checked a few places, it does seem to inline ShenandoahHeap::heap() 
calls, e.g.

    0x00007ffff780c29c <+28>:	push   %rbx
    0x00007ffff780c29d <+29>:	sub    $0x48,%rsp
    0x00007ffff780c2a1 <+33>:	lea    0x54e8c8(%rip),%rax        # 
0x7ffff7d5ab70 <_ZN14ShenandoahHeap5_heapE>
    0x00007ffff780c2a8 <+40>:	mov    (%rax),%rbx


Please feel free to reject the patch, if you otherwise.

Thanks,

-Zhengyu


From gnu.andrew at redhat.com  Tue Jun 30 17:38:16 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 30 Jun 2020 18:38:16 +0100
Subject: [aarch64-port-dev ] RFR: Shenandoah integration 2020-06-25
In-Reply-To: <d26d289c71c34c75234a3f7abfd8c7065b5f1730.camel@redhat.com>
References: <d26d289c71c34c75234a3f7abfd8c7065b5f1730.camel@redhat.com>
Message-ID: <bde30e87-cd1f-8baf-de4b-994b1bea5670@redhat.com>

On 25/06/2020 14:13, Roman Kennke wrote:
> I'd like to integrate 2 important backports from shenandoah/jdk8 to
> aarch64-port/jdk8u-shenandoah:
> 
> http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2020-06-25/webrev.00/
> 
> It only touches Shenandoah code.
> 
> Testing: several nightly runs of our CI, including
> hotspot_gc_shenandoah, specjvm, CTW tests and jcstress.
> 
> Can I please get a review?
> 
> Thanks,
> Roman
> 

I don't see a problem with the changes, but it is very late for 8u262
now (it froze upstream at the end of last week).

Let me push the b08 & b09 merges first and then I'm ok with this being
pushed on top and tagged. That has to be the last for 8u262 though, as
I'll be moving to work on the repos in private over the next few days.

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


From rkennke at redhat.com  Tue Jun 30 18:07:31 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 30 Jun 2020 20:07:31 +0200
Subject: [aarch64-port-dev ] RFR: Shenandoah integration 2020-06-25
In-Reply-To: <bde30e87-cd1f-8baf-de4b-994b1bea5670@redhat.com>
References: <d26d289c71c34c75234a3f7abfd8c7065b5f1730.camel@redhat.com>
 <bde30e87-cd1f-8baf-de4b-994b1bea5670@redhat.com>
Message-ID: <1b5c7f92372eb9f93b73b049682cb8982a6ddb67.camel@redhat.com>

Ping me when it's ready to accept the changes, ok?

Thanks,
Roman

On Tue, 2020-06-30 at 18:38 +0100, Andrew Hughes wrote:
> On 25/06/2020 14:13, Roman Kennke wrote:
> > I'd like to integrate 2 important backports from shenandoah/jdk8 to
> > aarch64-port/jdk8u-shenandoah:
> > 
> > http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2020-06-25/webrev.00/
> > 
> > It only touches Shenandoah code.
> > 
> > Testing: several nightly runs of our CI, including
> > hotspot_gc_shenandoah, specjvm, CTW tests and jcstress.
> > 
> > Can I please get a review?
> > 
> > Thanks,
> > Roman
> > 
> 
> I don't see a problem with the changes, but it is very late for 8u262
> now (it froze upstream at the end of last week).
> 
> Let me push the b08 & b09 merges first and then I'm ok with this
> being
> pushed on top and tagged. That has to be the last for 8u262 though,
> as
> I'll be moving to work on the repos in private over the next few
> days.
> 
> Thanks,


From kdnilsen at amazon.com  Tue Jun 30 22:39:40 2020
From: kdnilsen at amazon.com (Nilsen, Kelvin)
Date: Tue, 30 Jun 2020 22:39:40 +0000
Subject: RFR: 8232782: Shenandoah: streamline post-LRB CAS barrier (aarch64)
 (version 2)
Message-ID: <F883DBF4-4C5E-4EB3-AF58-7AC9620870C7@amazon.com>

Thank you for feedback from previously distributed draft patch.  This new patch is similar to the patch distributed on June 24.  However, this version uses MacroAssembler::cmpxchng() instead of hard-coding the use of ldxr/stxr instructions.

See http://cr.openjdk.java.net/~kdnilsen/JDK-8232782/webrev.02/

This patch addresses the problem described in https://bugs.openjdk.java.net/browse/JDK-8232782

The implementation mimics the behavior of the recently revised x86 implementation of cmpxchg_oop with slight refinements:

X86 version:
Step 1: Try CAS
Step 2: if CAS fails, check if original memory holds equivalent from-space pointer
Step 3: Use CAS to overwrite memory with equivalent to-space pointer
Step 4: Try CAS again
Step 5: Return boolean result to indicate success or failure

AARCH64 version:
Step 1: Try CAS
Step 2: if CAS fails, check if original memory holds equivalent from-space pointer
Step 3 (differs): Do not overwrite memory with equivalent to-space pointer,  Instead, run the original CAS request with from-space pointer as the "expected" value. If this succeeds, we're done.  If this fails, go back to step 1 and try that again.

Step 5: Return boolean result to indicate success or failure

This patch satisfies tier1, tier2, and hotspot_gc_shenandoah regression tests on Ubuntu 18.04.4 LTS (GNU/Linux 5.3.0-1023-aws aarch64).  I have also run an "extreme" garbage collection workload for 20 minutes without problem.

Is this ok to merge?